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

Question

Отказ от ответственности: есть много схожих вопросов по SO, но я ищу практическое предложение, а не просто общие принципы.Кроме того, не стесняйтесь указывать на реализацию «идеального» алгоритма (PHP был бы неплох;для хранения в базе данных?Я знаю, что должен:

• использовать соль
• повторять процесс хеширования несколько раз (хеширование для растяжение ключа )

Iя думал об использовании такого алгоритма:

x = md5( salt + password);
repeat N-times:
    x = md5( salt + password + x );

Я уверен, что это вполне безопасно, но есть несколько вопросов, которые приходят на ум:

1. будет ли этовыгодно ли включать имя пользователя в соль?

2. Я решил использовать общую соль для всех пользователей, есть ли в этом недостаток?

3. Что такоерекомендуемая минимальная длина соли, если таковая имеется?

4. мне следует использовать md5, ша или что-то еще?

5. Есть ли что-то не так с приведенным вышеалгоритм / какие-либо предложения?

6. ... (не стесняйтесь предоставлять больше :)

Я знаю, что решения обязательно зависят от ситуации,но я ищу решение, которое бы:

• обеспечивало бы максимально возможную безопасность
• было бы достаточно быстро (<0,5 секунды в декабреent machine) </li>

Итак, как будет выглядеть идеальный алгоритм, предпочтительно в псевдокоде?

Answer 1

"Идеальная" функция хеширования пароля на данный момент - bcrypt .Он включает в себя обработку соли и настраиваемое количество итераций.Существует бесплатная реализация PHP с открытым исходным кодом .

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

Что касается ваших конкретных вопросов:

1.Было бы полезно включить имя пользователя в соли?

Не совсем.

2.Я решил использовать поваренную соль для всех пользователей, есть ли в этом недостаток?

Да: это устраняет преимущества наличия соли.Единственная причина существования - быть уникальным для каждого хешированного пароля.Это позволяет атакующему атаковать два хэшированных пароля с меньшими усилиями, чем в два раза, чем атака одного хэшированного пароляСоли должны быть уникальными .Даже наличие соли для пользователя плохо: соль также должна быть изменена, когда пользователь меняет свой пароль.Оптимизация, которую злоумышленник может применить при повторном использовании / совместном использовании соли, включает (но не ограничивается) таблицы предварительно вычисленных хешей, такие как радужные таблицы .

3,Какова рекомендуемая минимальная длина соли, если таковая имеется?

Соль должна быть уникальной.Уникальность - сложное свойство поддерживать.Но используя достаточно длинных случайных солей (генерируемых хорошим генератором случайных чисел, предпочтительно криптографически сильным), вы получаете уникальность с достаточно высокой вероятностью.128-битные соли достаточно длинные.

4.я должен использовать MD5, Sha или что-то еще?

MD5 плохо для связей с общественностью.У него есть известные недостатки, которые могут или не могут применяться к данному использованию, и очень трудно с какой-либо достоверностью «доказать», что эти недостатки не относятся к конкретной ситуации.SHA-1 лучше, но не «хорошо», потому что он также имеет слабые стороны, хотя и гораздо менее серьезные, чем у MD5.SHA-256 - разумный выбор.Как было указано выше, для хеширования пароля вам нужна функция, которая хорошо не хорошо масштабируется на параллельных архитектурах, таких как GPU , а SHA-256 хорошо масштабируется, поэтому Blowfish-производное, используемое в bcrypt, является предпочтительным.

5.Что-то не так с приведенным выше алгоритмом / какие-либо предложения?

Это домашнее.Это плохо.Проблема в том, что не существует известного теста на безопасность криптографического алгоритма.Лучшее, на что мы можем надеяться, это позволить нескольким сотням профессиональных криптографов попытаться взломать алгоритм в течение нескольких лет - если они не могут, то мы можем сказать, что хотя алгоритм на самом деле не «доказан» как безопасный, по крайней мере, слабые стороныне должно быть очевидным.Bcrypt был вокруг, широко развернут и проанализирован в течение 12 лет.Вы не можете победить это самостоятельно, даже с помощью StackOverflow.

Как профессиональный криптограф, я бы поднял подозрительную бровь при использовании простой конкатенации в MD5 или даже SHA-256: это Merkle – Damgård хеш-функции, которая хороша для сопротивления столкновению, но не обеспечивает случайного оракула (существует так называемая «атака с удлинением длины»).В PBKDF2 хеш-функция используется не напрямую, а через HMAC .

Answer 2

Я склонен использовать фиксированную соль приложения, имя пользователя и пароль

Пример ...

string prehash = "mysaltvalue" + "myusername" + "mypassword";

Преимущество в том, что люди, использующие один и тот же пароль, не заканчиваютс таким же значением хеш-функции, и это препятствует тому, чтобы люди, имеющие доступ к базе данных, копировали свои пароли другим пользователям - конечно, если вы можете получить доступ к БД, вам не нужно взламывать логин для получения данных;)

IMO, длина соли не имеет большого значения, длина хэшированного значения всегда будет 32 в любом случае (с использованием MD5 - что опять-таки является тем, что я бы использовал)

Я бы сказал в терминахбезопасности, этого шифрования пароля достаточно, самое главное, чтобы убедиться, что в вашем приложении / базе данных нет утечек безопасности!

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