Я уже использую соленое хеширование для хранения паролей в моей базе данных, что означает, что я должен быть невосприимчив к rainbow table.
У меня была мысль, хотя: что, если кто-то овладеет моей базой данных? Он содержит адреса электронной почты пользователей. Я не могу это сделать, потому что я буду использовать их для отправки уведомлений по электронной почте и т.д.
Должен ли я их зашифровать?
Брюс Шнайер хорошо реагирует на эту проблему.
Криптография не является решением ваших проблем безопасности. Это может быть частью решения, или это может быть частью проблемы. Во многих ситуациях криптография начинается с ухудшения проблемы, и совсем не ясно, что использование криптографии является улучшением.
По сути, шифрование ваших писем в базе данных "на всякий случай" на самом деле не делает базу данных более безопасной. Где хранятся ключи для базы данных? Какие права доступа к файлам используются для этих ключей? Доступна ли база данных общедоступно? Зачем? Какие существуют ограничения учетной записи для этих учетных записей? Где хранится машина, у кого есть физический доступ к этому ящику? Что касается удаленного входа/выхода ssh и т.д. И т.д. И т.д.
Итак, я думаю, вы можете зашифровать электронные письма, если хотите, но если это степень безопасности системы, то это действительно мало что делает, и на самом деле упростит работу с базой данных.
Конечно, это может быть частью обширной политики безопасности для вашей системы - если это так здорово!
Я не говорю, что это плохая идея. Но почему есть замок на двери от Deadlocks'R'us, который стоит 5000 долларов, когда они могут прорезать фанеру возле двери? Или зайти через окно, которое вы оставили открытым? Или еще хуже они находят ключ, который остался под ковриком. Безопасность системы не хуже, чем самое слабое звено. Если у них есть root-доступ, они могут в значительной степени делать то, что они хотят.
Стив Морган говорит о том, что даже если они не могут понять адреса электронной почты, они все равно могут нанести большой вред (что может быть смягчено, если они SELECT)
Также важно знать, какие ваши причины предназначены для хранения адреса электронной почты вообще. Возможно, я немного перегрузил этот ответ, но, на мой взгляд, вам действительно нужно сохранить адрес электронной почты для учетной записи? Наиболее безопасными данными являются данные, которые не существуют.
Как и большинство требований безопасности, вам необходимо понять уровень угрозы.
Какое повреждение может быть сделано, если адреса электронной почты скомпрометированы?
Какая вероятность этого?
Урон, нанесенный, если адреса электронной почты ЗАМЕНЯЮТ, может быть намного больше, чем если бы они были ЭКСПОЗИЦИИ. Особенно, если вы, например, используете адрес электронной почты для подтверждения сброса пароля в защищенной системе.
Вероятность того, что пароли будут заменены или выставлены, значительно сокращается, если вы их используете, но это зависит от того, какие другие элементы управления у вас есть.
Я понимаю, что это мертвая тема, но я согласен с логикой Arjan. Есть несколько вещей, которые я хотел бы отметить:
Кто-то может извлекать данные из вашей базы данных, не загружая исходный код (т.е. SQL-инъекция, сторонние db). Имея это в виду, разумно рассмотреть возможность использования шифрования с ключом. Хотя это только добавленная мера безопасности, а не безопасность... это для тех, кто хочет сохранить электронную почту более конфиденциальной, чем простой текст,
Во избежание того, что во время обновления что-то упускается из виду, или злоумышленнику удается получить электронные письма.
IMO: Если вы планируете шифровать электронное письмо, сохраните также соленый хэш. Затем вы можете использовать хеш для проверки и освободить накладные расходы от постоянного использования шифрования, чтобы найти массивную строку данных. Затем у вас есть отдельная частная функция для извлечения и расшифровки ваших писем, когда вам нужно ее использовать.
Я бы сказал, это зависит от приложения вашей базы данных.
Самая большая проблема заключается в том, где вы храните ключ шифрования? Потому что, если хакер имеет избыток для чего-либо большего, чем ваш БД, все ваши усилия, вероятно, будут потрачены впустую. (Помните, что вашему приложению понадобится этот ключ шифрования для дешифрования и шифрования, поэтому в конечном итоге хакер найдет ключ шифрования и используемую схему шифрования).
Pro:
Минусы:
Не случайно связывать шифрование с запутыванием. Мы обычно обфускации писем, чтобы предотвратить спам. Многие веб-сайты будут иметь "webmaster _at_ mysite.com", чтобы замедлить сканирование от разбора адреса электронной почты в качестве потенциальной цели спама. Это должно быть сделано в HTML-шаблонах - нет смысла делать это в постоянном хранилище баз данных.
Мы не шифруем что-либо, если нам не нужно хранить его в секрете во время передачи. Когда и где будут передаваться ваши данные?
Операторы SQL передаются от клиента к серверу; что в том же ящике или над защищенным соединением?
Если ваш сервер взломан, у вас есть непреднамеренная передача. Если вы беспокоитесь об этом, то, возможно, вам следует защищать свой сервер. У вас есть внешние угрозы, а также внутренние угрозы. Все ли пользователи (внешние и внутренние) правильно аутентифицированы и авторизованы?
Во время резервного копирования у вас есть намеренная передача на резервный носитель; это делается с использованием безопасной стратегии резервного копирования, которая шифрует, когда она идет?
Оба SQL Server и Oracle (и, я считаю, также другие DB) поддерживают шифрование данных на уровне базы данных. Если вы хотите что-то зашифровать, почему бы просто не абстрагировать доступ к данным, которые можно было зашифровать на стороне сервера базы данных, и оставить пользователя выбирать, использовать ли зашифрованные данные (в этом случае команда SQL будет отличаться) или нет. Если пользователь хочет, чтобы пользователь зашифровал данные, он может настроить сервер базы данных, и все работы по обслуживанию, связанные с управлением ключами, выполняются с использованием стандартного инструмента DBA, сделанного от поставщика БД, а не от вас.
Копия моего ответа на Каков наилучший и безопасный способ хранения пользовательских адресов электронной почты в базе данных?, только ради поиска...
В целом я согласен с другими, говоря, что это не стоит усилий. Однако я не согласен с тем, что любой, кто может получить доступ к вашей базе данных, возможно, также получит ваши ключи. Это, безусловно, неверно для SQL Injection и может быть неверным для резервных копий, которые каким-то образом теряются или забываются. И я чувствую, что адрес электронной почты - это личная информация, поэтому мне было бы безразлично спам, но о личных последствиях, когда адреса будут раскрыты.
Конечно, когда вы боитесь SQL Injection, вы должны убедиться, что такая инъекция запрещена. А резервные копии должны быть зашифрованы сами.
Тем не менее, для некоторых онлайн-сообществ участники, возможно, не хотят, чтобы другие знали, что они являются членами (например, связанные с психическим здоровьем, финансовой помощью, медицинскими и сексуальными советами, развлечения для взрослых, политика,...). В таких случаях можно хранить как можно меньше личных данных и шифровать те, которые требуются (обратите внимание, что шифрование на уровне базы данных не препятствует показу данных с использованием SQL Injection), возможно, не такая плохая идея. Опять же: рассматривайте адрес электронной почты как таковую в личной информации.
Для многих сайтов это, вероятно, не так, и вам следует сосредоточиться на запрещении SELECT * FROM через SQL Injection и убедиться, что посетители не могут каким-то образом получить доступ к кому-то другому персональному профилю или информации о заказе, изменив URL-адрес.
Стоит зашифровать данные в Базах данных, это не делает его немного сложнее, но сложнее, когда его зашифровано правильным способом, чтобы остановить философию и зашифровать конфиденциальные данные;)
Вам действительно нужно взвесить ваш худший случай сенарио для кого-то, получающего эти адреса электронной почты, вероятность того, что кто-то их получит, а также ваши дополнительные усилия/время, необходимые для внесения изменений.
@Roo
Я несколько согласен с тем, что вы говорите, но не стоит ли шифровать данные, чтобы сделать его немного сложнее для кого-то, чтобы получить его?
С вашими рассуждениями было бы бесполезно иметь в вашем доме блокировки или тревоги, потому что они также могут быть легко скомпрометированы.
Мой ответ:
Я бы сказал, что если у вас есть конфиденциальные данные, которые вы не хотите впадать в чужие руки, вы должны, вероятно, сделать это так же сложно, как вы можете, чтобы хакер мог его получить, даже если это не 100%.