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

Ответ 1

Используйте SHA1 или SHA256 хеширование с помощью соления. Это способ хранения паролей.

Ответ 2

Не используйте SHA1 или SHA256, как предлагают большинство других людей. Определенно не используйте MD5.

SHA1/256 и MD5 предназначены для создания контрольных сумм файлов и строк (и, при необходимости, других типов данных). Из-за этого они разработаны как можно быстрее, так что контрольная сумма быстро генерируется.

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

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

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

Мне лично нравится bcrypt. Должна быть доступна версия Perl, так как быстрый поиск в Google дал несколько возможных совпадений.

Ответ 3

MD5 обычно используется, но SHA1/SHA256 лучше. Все еще не лучшее, но лучше.

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

Но вы хотите как можно меньше замедлить атакующего, не так ли? Не было бы лучше использовать алгоритм, который займет десятую часть секунды вместо хэша пароля? Десятая часть секунды все еще достаточно быстро, что пользователи обычно не замечают, но злоумышленник, у которого есть копия вашей базы данных, сможет делать только 10 попыток в секунду - потребуется 100 000 раз дольше, чтобы найти рабочий набор учетных данных для входа. Каждый час, когда он будет принимать их за микросекунду за попытку, будет составлять 11 лет на одну десятую секунды за попытку.

Итак, как вы это делаете? Некоторые люди подделывают его, выполняя несколько раундов переваривания MD5/SHA, но алгоритм bcrypt разработан специально для решения этой проблемы. Я не полностью понимаю математику за ней, но мне сказали, что она основана на создании кадров Blowfish, которая по своей сути медленна (в отличие от операций MD5, которые могут быть сильно обтекаемы на правильно настроенном оборудовании), и она имеет настраиваемый параметр "стоимость", так что, по мере того как закон Мура продвигается, все, что вам нужно сделать, это настроить "стоимость", чтобы поддерживать хеширование вашего пароля так же медленно, как и в течение десяти лет, как сегодня.

Ответ 4

Мне нравится bcrypt лучшее, а SHA2 (256) - близкое второе. Я никогда не видел, чтобы MD5 использовался для паролей, но, возможно, некоторые приложения/библиотеки используют это. Имейте в виду, что вы всегда должны использовать соль. Сама соль должна быть полностью уникальной для каждого пользователя и, на мой взгляд, как можно дольше. Я никогда бы никогда не использовал хеш против строки без соли, добавленной к ней. В основном потому, что я немного параноик, а также так, что он немного более надежный в будущем.

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

Ответ 5

Модуль pgcrypto в PostgreSQL имеет встроенный suppotr для хэширования паролей, который довольно умен в отношении хранения, генерации, мульти-алгоритма и т.д. См. http://www.postgresql.org/docs/current/static/pgcrypto.html, раздел "Функции Хеширования пароля". Вы также можете увидеть раздел pgcrypto http://www.hagander.net/talks/hidden%20gems%20of%20postgresql.pdf.

Ответ 6

Если вы не используете механизм восстановления пароля (не пароль reset), я думаю, что использование хеширующего механизма лучше, чем пытаться зашифровать пароль. Вы можете просто проверить хеши без риска для безопасности. Даже вы не знаете пароль пользователя.

Ответ 7

Я бы предложил сохранить его в виде соленого хеша md5.

INSERT INTO user (password) VALUES (md5('some_salt'||'the_password'));

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

Вы также можете использовать sha1 в качестве альтернативы, но я не уверен, что Postgres имеет встроенную реализацию этого.

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

Я всегда использую одноразовую случайно сгенерированную соль и сохраняю ее в источнике приложения или в файле конфигурации.

Еще одно преимущество использования хеша md5 или sha1 для пароля - вы можете определить столбец пароля как фиксированную ширину CHAR (32) или CHAR (40) для md5 и sha1 соответственно.