Стоит ли шифровать адреса электронной почты в базе данных?

Question

Я уже использую соленое хеширование для хранения паролей в моей базе данных, что означает, что я должен быть защищен от радужных таблиц атак.

У меня была мысль: а вдруг кто-нибудь завладеет моей базой данных? Он содержит адреса электронной почты пользователей. Я не могу их хэшировать, потому что я буду использовать их для отправки уведомлений по электронной почте и т. Д.

Должен ли я их зашифровать?

Answer 1

У Брюса Шнайера хороший ответ на подобные проблемы.

Криптография не является решением ваших проблем безопасности. Это может быть частью решения, или это может быть частью проблемы. Во многих ситуациях криптография начинает с того, что усугубляет проблему, и совершенно не ясно, что использование криптографии - это улучшение.

По сути, шифрование ваших электронных писем в базе данных «на всякий случай» на самом деле не делает базу данных более безопасной. Где хранятся ключи для базы данных? Какие права доступа к файлам используются для этих ключей? Доступна ли база данных публично? Зачем? Какие ограничения существуют для этих учетных записей? Где хранится машина, у кого есть физический доступ к этому ящику? А как насчет удаленного входа / доступа по SSH и т. Д. И т. Д. И т. П.

Так что я полагаю, что вы можете зашифровать электронные письма, если хотите, но если это степень безопасности системы, то это на самом деле мало что делает, и фактически усложнит работу по поддержанию базы данных.

Конечно, это может быть частью обширной политики безопасности для вашей системы - если так, то отлично!

Я не говорю, что это плохая идея - но зачем иметь замок на двери от Deadlocks'R'us, который стоит 5000 долларов, когда они могут прорезать фанеру вокруг двери? Или войти через окно, которое вы оставили открытым? Или, что еще хуже, они находят ключ, оставленный под ковриком. Безопасность системы так же хороша, как и самое слабое звено. Если у них есть root-доступ, они могут делать то, что хотят.

Стив Морган отмечает, что даже если они не могут понять адреса электронной почты, они все равно могут принести много вреда (который можно было бы смягчить, если бы у них был только доступ SELECT)

Также важно знать, по каким причинам вы вообще храните адрес электронной почты. Я мог бы немного переборщить с этим ответом , но я хочу сказать, вам действительно нужно хранить адрес электронной почты для учетной записи? Наиболее безопасные данные - это несуществующие данные.

Answer 2

Я понимаю, что это мертвая тема, но я согласен с логикой Арджана за этим. Я бы хотел отметить несколько вещей:

Кто-то может получить данные из вашей базы данных без извлечения исходного кода (т. Е. SQL-инъекция, сторонние базы данных). Имея это в виду, разумно рассмотреть возможность использования шифрования с ключом. Хотя это только дополнительная мера безопасности, а не безопасность ... это для тех, кто хочет сохранить электронную почту более конфиденциальной, чем открытый текст, В случае если во время обновления что-то упускается из виду, или злоумышленнику удается получить электронные письма.

IMO: Если вы планируете зашифровать электронную почту, сохраните также и соленый хеш. Затем вы можете использовать хеш для проверки и сэкономить время на постоянном использовании шифрования для поиска массивной строки данных. Затем используйте отдельную частную функцию для извлечения и расшифровки ваших электронных писем, когда вам нужно их использовать.

Answer 3

Как и большинство требований безопасности, вам необходимо понимать уровень угрозы.

Какой ущерб может быть нанесен, если адреса электронной почты скомпрометированы?

Какова вероятность того, что это произойдет?

Ущерб, нанесенный при замене адресов электронной почты, может быть намного больше, чем при их разоблачении. Особенно, если вы, например, используете адрес электронной почты для проверки сброса пароля в защищенной системе.

Вероятность того, что пароли будут заменены или предоставлены, значительно уменьшится, если вы их хешируете, но это зависит от того, какие другие элементы управления у вас есть.

Answer 4

Не случайно путайте шифрование с обфускацией. Мы обычно запутываем электронные письма, чтобы предотвратить спам. Многие веб-сайты будут иметь "webmaster _at_ mysite.com", чтобы замедлить сканеры от анализа адреса электронной почты как потенциальной цели спама. Это должно быть сделано в шаблонах HTML - нет смысла делать это в постоянном хранилище базы данных.

Мы ничего не шифруем, если только нам не нужно хранить это в секрете во время передачи. Когда и где будут передаваться ваши данные?

1. Операторы SQL передаются от клиента к серверу; это на той же коробке или через безопасное соединение?

2. Если ваш сервер скомпрометирован, у вас есть непреднамеренная передача. Если вас это беспокоит, возможно, вам следует защитить свой сервер. У вас есть внешние угрозы, а также внутренние угрозы. ВСЕ ли пользователи (внешние и внутренние) должным образом аутентифицированы и авторизованы?

3. Во время резервного копирования у вас есть преднамеренная передача на носитель резервного копирования; это сделано с использованием стратегии безопасного резервного копирования, которая шифрует по ходу дела?

Answer 5

Я бы сказал, что это зависит от применения вашей базы данных.

Самая большая проблема в том, где вы храните ключ шифрования? Потому что, если у хакера есть избыток чего-то большего, чем ваша БД, все ваши усилия, вероятно, будут потрачены впустую. (Помните, что вашему приложению потребуется этот ключ шифрования для дешифрования и шифрования, поэтому в конечном итоге хакер найдет ключ шифрования и использованную схему шифрования).

Pro:

• Утечка только вашей БД не будет раскрывать адреса электронной почты.

Минусы:

• Шифрование означает потерю производительности.
• Совокупность действий базы данных будет сложнее, если не невозможнее.

Answer 6

И SQL Server, и Oracle (и я полагаю, также и другие БД) поддерживают шифрование данных на уровне базы данных. Если вы хотите что-то зашифровать, почему бы просто не абстрагировать доступ к данным, которые могут быть зашифрованы на стороне сервера базы данных, и оставить пользователю выбор, использовать ли зашифрованные данные (в этом случае команда SQL будет отличаться) или нет. Если пользователь хочет использовать зашифрованные данные, он может настроить сервер базы данных, и все работы по обслуживанию, связанные с управлением ключами, выполняются с использованием стандартного инструмента DBA, сделанного от поставщика БД, а не от вас.

Answer 7

Стоит зашифровать данные в базах данных, это не делает их немного сложнее, но намного сложнее, если их правильно зашифровать, так что остановите философию и зашифруйте важные данные;)

Answer 8

Копия моего ответа на Какой самый лучший и безопасный способ хранения адресов электронной почты пользователей в базе данных? , только для поиска ...

---

В общем, я согласен с другими, говоря, что это не стоит усилий. Однако я не согласен с тем, что любой, кто может получить доступ к вашей базе данных, может также получить ваши ключи. Это, конечно, неверно для SQL-инъекций и может быть неверно для резервных копий, которые так или иначе потеряны или забыты. И я считаю, что адрес электронной почты - это личная деталь, поэтому я не буду беспокоиться о спаме, а о личных последствиях, когда адреса будут раскрыты.

Конечно, когда вы боитесь SQL-инъекций, вы должны убедиться, что такие инъекции запрещены. И резервные копии должны быть зашифрованы сами.

Тем не менее, для некоторых онлайн-сообществ участники могут определенно не хотеть, чтобы другие знали, что они являются членами (например, связанные с психическим здоровьем, финансовой помощью, медицинскими и сексуальными консультациями, развлечениями для взрослых, политикой, ...). В этих случаях сохранение как можно меньшего количества персональных данных и шифрование необходимых (обратите внимание, что шифрование на уровне базы данных не препятствует отображению подробностей с использованием SQL-инъекции), может быть не такой уж плохой идеей. Опять же: рассматривайте адрес электронной почты как личную информацию.

Для многих сайтов вышеупомянутое, вероятно, не так, и вам следует сосредоточиться на запрете SELECT * FROM с помощью SQL-инъекции и убедиться, что посетители не могут каким-либо образом получить доступ к чужому личному профилю или информации о заказе, изменив URL.

Answer 9

@ Roo

Я в некоторой степени согласен с тем, что вы говорите, но разве не стоит шифровать данные только для того, чтобы кому-то было немного сложнее их получить?

С вашей точки зрения было бы бесполезно иметь в вашем доме замки или сигналы тревоги, потому что они также могут быть легко взломаны.

Мой ответ:

Я бы сказал, что если у вас есть конфиденциальные данные, которые вы не хотите, чтобы попасть в чужие руки, вам, вероятно, следует сделать это так сильно, как вы можете, чтобы хакер получил их, даже если они не на 100% защищены .

Answer 10

Вы действительно должны взвесить ваш худший случай, когда кто-то получает эти адреса электронной почты, вероятность того, что кто-то их получит, и ваши дополнительные усилия / время, необходимые для того, чтобы повлиять на изменение.