Хеширование пароля: Keccak или нет

Question

Был выбран победитель конкурса SHA-3. Алгоритм победителя: Keccak.

Я использую Blowfish и действительно нравится, но Keccak считается лучшим. Стоит ли использовать его для хранения паролей пользователя на моем веб-сайте?

Если да, существуют ли какие-либо реализации Keccak для PHP, Python, Ruby или любых других языков, используемых в веб-программировании?

Надеюсь, этот вопрос поможет другим людям. Благодаря!

Answer 1

I use Blowfish and really like it, but Keccak is said to be better.

"Лучше" такое понятие относительное. Лучше в чем? Безопасность, производительность, масштабируемость, переносимость, ...?

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

Это говорит о том, что Keccak - достойный вариант, если вы ищете что-то для работы на встроенной архитектуре или хотите большую переносимость. Here is a PHP implementation on github, и here is another Вы также можете сделать свой собственный язык на downloading the Keccak source.

Но, честно говоря, лучше всего придерживаться того, что вы знаете. Если хакер может легко получить хеши blowfish, которые вы используете в настоящий момент, проблема заключается не в алгоритме хэширования, а в доступе к базе данных. Также обратите внимание, что расширение PHP должно быть установлено на ВСЕХ серверах, используя это, что может быть или не быть возможным, если вы используете общий хост.

В действительности вы, вероятно, должны придерживаться того, что у вас есть. Скорее всего, это достаточно безопасно, и как только реализация Keccak будет перенесена на стандартное ядро ​​PHP, вы можете перейти (тогда вам нужно). Только мои два цента.

Answer 2

короткий ответ:

Нет, и, наверное, никогда. Для хеширования паролей BCrypt & PBKDF2-HMAC- xxx - лучший выбор, чем любой простой алгоритм SHA-1/2/3. И до тех пор, пока у SHA-1/2 не будет фактических предикатных атак, SHA-3 на самом деле является худшим выбором, в частности , потому что его скорости и низкого размера кеша.

развернутый ответ:

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

Одним из основных критериев SHA-3 является то, что он должен эффективно работать на встроенных архитектурах, которые типичны для небольших объемов кеша, регистров и т. Д.Но это также описывает современные графические процессоры: меньшее количество регистров/аккумуляторов, меньшие по размеру кэши; но на оборотной стороне их кремний оптимизирован для параллельной параллельной работы над большими объемами данных. Это идеально подходит для попыток грубой силы вашего атакующего: навсегда потраченный на кремний доллар, ваш атакующий получает больше хэшей SHA3/сек, покупая другой графический процессор, чем вы, покупая лучший процессор.

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

Вот почему необработанная скорость является врагом хэширования паролей. Вы хотите выбрать алгоритм, чья самая быстрая комбинация программного и аппаратного обеспечения предлагает вашему злоумышленнику наименьшее преимущество за доллар над программным обеспечением/аппаратным обеспечением, которое вы будете использовать. Прямо сейчас, это BCrypt или немного меньший выбор PBKDF2-HMAC- xxx. Поскольку графические процессоры, вероятно, будут лучше собираться на SHA3, я сомневаюсь, что это будет правильный выбор. У меня нет чисел на SHA3, но «более безопасный» не является туманно относительным термином - это правило может использоваться для точного количественного определения.

Answer 3

Это старый вопрос, но похоже, что все снова запутаны cryptography terminology. Давайте разберемся.

• Keccak - это криптографическая хэш-функция.
• Blowfish - это блок-шифр (который имеет размер 64-битного блока и больше не должен использоваться для шифрования).
• Bcrypt - это функция хэширования , которая имеет другой прецедент, чем простая криптографическая хеш-функция. Bcrypt основан на Blowfish, но это не Blowfish.

Я не просто педантичен; эти различия важны, потому что Keccak не конкурирует с bcrypt, он конкурирует с SHA-256.

Вот простой способ safely store a password in PHP:

1. Использование password_hash(), password_verify() и password_needs_rehash()

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

В настоящее время этот интерфейс обеспечивает bcrypt. Bcrypt в основном в порядке, за исключением нескольких ножные пуль, чтобы следить за:

1. Он обрезает пароли после того, как 72 символов, что снижает безопасность длинных паролей с низкой энтропии ключевого пространства каждого символа.
2. Если вы попытаетесь обойти предыдущую футовую пулю путем предварительного хеширования, будьте осторожны, чтобы вы не передавали необработанный двоичный код в bcrypt, потому что он также обрезается после NUL символов.

Если вы беспокоитесь об этих проблемах, существует временная остановка в password_lock.

В PHP 7.2, вероятно, будет возможно использовать Argon2i через этот интерфейс (при условии прохождения RFC).

Через несколько лет (около PHP 7.5, не допуская серьезных ошибок) мы можем видеть, что PASSWORD_ARGON2I станет новым значением для PASSWORD_DEFAULT, но, возможно, нет. У нас есть несколько лет для исследователей криптографии, чтобы получить уверенность в этом.