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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно используется MD5, но лучше SHA1 / SHA256. Все-таки не лучший, но лучше.

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

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

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