Хранение паролей, hash () с sha-512 или crypt () с blowfish (bcrypt)?

Это моя текущая процедура хеширования паролей в проектах PHP / SQL ...

  • Возьмите 512 бит соли для каждого пользователя из / dev / urandom, хранящуюся в записи БД пользователя в дополнение к окончательному хешу.
  • Возьмите 512 бит «перца» из / dev / urandom, который хранится в файловой системе. Это константа для каждого приложения и одинакова для каждого пользователя.
  • Тогда hash('sha512', $password.$salt.$pepper, TRUE)

Хеш и соль хранятся в БД в двоичном формате, в основном по привычке. Я не думаю, что это имеет значение с точки зрения безопасности. Во всяком случае, это немного менее удобно для резервного копирования SQL и делает код PHP кажущимся несколько более сложным.

Считается, что hash() с SHA-256 или SHA-512 в наши дни заменен bcrypt?
Я считаю, что SHA-2 (256/512) по-прежнему считается криптографически безопасным, и я, вероятно, переборщил с битами энтропии. Гораздо более вероятно, что это будет недостаток в моем коде, который приведет к проблемам, чем злоумышленник, перепроектирующий хэш SHA-2 из дампа БД.

Но следует ли мне обновить свою методологию, чтобы вместо этого использовать crypt() с CRYPT_BLOWFISH (я считаю, что это называется bcrypt, а blowfish технически является шифром, а не алгоритмом хеширования)?
Даже как лучшая практика в будущем?

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

Ура, B


php bcrypt hash password-encryption sha
person batfastad    schedule 17.09.2012    source источник
comment
I guess in a way the slower the better, if it makes a server work harder to generate then it will make an attacker's work slower to brute force. Это абсолютно верно, и важной особенностью рекомендуемых стратегий хеширования является возможность настраивать (увеличивать) стоимость хеширования (без аннулирования хранимых хешей) по мере того, как усовершенствования оборудования снижают относительную стоимость хеширования. crypt с Blowfish предлагает это.   -  person grossvogel    schedule 18.09.2012
comment
См. Также структуру хеширования паролей PHP (PHPass) от Openwall. Он портативен и защищен от ряда распространенных атак на пароли пользователей. Фреймворк (SolarDesigner) написал тот же парень, который написал John The Ripper и сидит как судья в конкурсе по хешированию паролей. Так что он кое-что знает об атаках на пароли.   -  person jww    schedule 12.10.2014

Ответы (2)


arrow_upward
5
arrow_downward

Если вы можете подождать до php 5.5, для этого будут встроены некоторые полезные функции:

https://gist.github.com/3707231

А пока используйте crypt - вы можете посмотреть на этот порт с прямой совместимостью с новыми функциями:

https://github.com/ircmaxell/password_compat

person Kenny Grant    schedule 17.09.2012
comment
Хороший порт с прямой совместимостью! Думаю, пройдет некоторое время, прежде чем я увижу хостинговые среды с PHP 5.5. Я нашел openwall.com/phpass, но не уверен, насколько хорошо он поддерживается или будет в будущее. - person batfastad; 18.09.2012

arrow_upward
2
arrow_downward

Вы определенно на правильном пути, bcrypt - очень хороший способ хранить ваши пароли (scrypt лучше, но трудно найти хорошую реализацию на PHP).

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

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

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

В этом сообщении содержится отличное понимание безопасности паролей.

person donutdan4114    schedule 18.09.2012
comment
Ага, если ваша система полностью взломана, то перчить бессмысленно. Но если кому-то просто удастся сбросить вашу базу данных, это обеспечит некоторую защиту. Хотя, если кому-то удается сбросить только мою базу данных, то, вероятно, где-то есть уязвимость SQL-инъекции, и я изначально не выполнил свою работу должным образом. Мне было легко реализовать перец, поэтому я подумал, что могу это сделать. - person batfastad; 18.09.2012
comment
Да, конечно, больше защиты лучше, чем меньше защиты. Просто всегда хорошо спросить, зависит ли моя безопасность от неизвестности? Ваша система не полагается на перец, так что это не недостаток. Используйте bcrypt, и вы будете в большей безопасности, чем 99% сайтов ... (кстати, это печальный факт) - person donutdan4114; 19.09.2012