Вопрос по database, encryption, mysql – Лучшие практики для хранения имен пользователей и паролей в базах данных MySQL [дубликаты]

15

Возможное дублирование:
Безопасный хеш и соль для паролей PHP

Я создаю систему, в которой хранятся учетные данные пользователя (электронная почта, имя пользователя и пароль) в базе данных MySQL, и я видел противоречивые мнения об использовании типов шифрования, засолки и шифрования.

Какие самые лучшие методы вы бы порекомендовали? Кодировка в MD5 или SHA1? Солить или не солить? Зашифровывать только пароль или все 3 элемента?

Ваш Ответ

5   ответов
11

PBKDF2 его NIST утвержден. Вы должны использовать случайную несекретную соль для каждого пароля и нетривиальный (более 1000) счетчик итераций.

Для имени пользователя и электронной почты, вероятно, не стоит шифровать.

@ csharptest.net Я согласен с вашим количеством итераций, хороший пример. jbtule
+ 1 для PBKDF2 намного лучше, хотя я обычно использую 10 000 итераций, когда производительность не является проблемой;) Например: Csharptest.net / 470 / ... csharptest.net
6

Используйте алгоритм хеширования, такой как SHA256 или SHA512. MD5 теперь небезопасен, так как вы можете изменить хеш / выполнить атаку радуги.

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

Не используйте шифрование.

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

+ 1 Хэширование электронных писем и имен пользователей будет непростым делом, поскольку они, как правило, также не чувствительны к регистру. Marcus Adams
Это неправильный ответ. Вы хотите использовать правильную функцию хеширования пароля, такую как PBKDF2 или bcrypt. imichaelmiers
@ imichaelmiers - это не значит, что мой ответ неверен. Вы порекомендовали более сильную функцию хеширования, однако SHA256 и 512 по-прежнему действительны, поскольку хеш-коллизий не обнаружено. Darren
@ DarrenDavies Проблема не в коллизиях. Настало время попытаться угадать пароль. Вы можете сделать по крайней мере 2300 миллионов sha1 хэшей в секунду на GPU. Это означает, что вы можете приблизительно угадать столько паролей. Учитывая, насколько короткими являются большинство паролей, это делает sha1 довольно бесполезным. Логика для этого изложена здесь. Он рекомендует использовать другую функцию, bcrypt, но логика и смысл одинаковы: функции хеширования паролей должны быть медленными, чтобы ограничить угадывание, а sha1 / 256 - быстрыми по своей конструкции. Codahale.com / как к безопасно-магазине-а-пароль imichaelmiers
И я не говорю конкретно о sha1, хотя это то, для чего я могу быстро найти данные. Вы можете делать как минимум 65 миллионов хэшей в секунду, и сайт, который я получаю, выглядит старым и устаревшим. Insidepro.com / рус / egb.shtml Логика применима к любой хэш-функции общего назначения. SHA 256/512 труднее получить при столкновении и труднее его инвертировать (поскольку с момента выдачи выходных данных на случайном входе восстановить входные данные, а не проверить предположение о входных данных). Они предназначены для быстрого вычисления. Если они быстрые, вы можете быстро угадать парол imichaelmiers
2

который вам нужно зашифровать. Реально, вы должны быть обаHashing (это то, что вы имеете в виду, когда говорите кодирование) в алгоритменаимене SHA-256 действительно (я почти уверен, что MD5 и SHA1 взломаны?)А ТАКЖ Salting ваши пароли для большей безопасности.

Вот ответ о предпочтительном способе их хранения: Предпочтительный способ хранения паролей в базе данных

1

они должны быть в открытом виде, они будут более полезными.

Что касается паролей: они должныАБСОЛЮТН быть зашифрован или хеширован, желательно с солью тоже. До сих пор я использовал для этого несколько интересную технику: AES, ключом к которой является сам пароль. Так что если пользователь делает свой пароль «blabla123», то я бы сохранил его в MySQL, вызвавAES_ENCRYPT('blabla123', 'blabla123'). Для этого есть 2 преимущества:

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

Действительность тогда делается путем шифрования того, что пользователь вводит, и сравнения двух значений.

@ PhilFaceplantYoung, я думаю, ты захочешь солить это. Это открыто для радужных атак без соли. Marcus Adams
Этоотве приводит несколько хороших аргументов в пользу использования хеширования, а не шифрования. Morgan Bruce
-1 для предложения использовать шифрование для паролей, -1 для высказывания «желательно с солью», -1 для предложения ДЕЙСТВИТЕЛЬНО плохого представления о шифровании пароля AES паролем, -1 для НЕ предлагать PBKDF2. --Nutshell: НЕ ИСПОЛЬЗУЙТЕ ЭТОТ ОТВЕТ - csharptest.net
-1Не делай этого. Как уже говорили другие, вы хотите использовать специально разработанные функции хеширования паролей, которые работают медленно. Таким образом, злоумышленник не может просто перебрать все возможные пароли. Вы можете сделать по крайней мере 2300 миллионов sha1 хэшей в секунду на GPU. Используйте что-то вроде PBKDF2 с большим количеством итераций, bcrypt или scrypt, чтобы действительно сделать это безопасно. Они призваны существенно замедлить атакующег imichaelmiers
Я действительно хочу удалить это, но не могу ... так как это принятый ответ ... Radu Murzea
0

MD5, либо SHA1), чтобы предотвратить атаку с использованием радужных таблиц.

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

Пожалуйста, не используйте MD5 или SHA1. Они оба криптографически взломаны. Marcus Adams

Похожие вопросы