Способы хранения паролей

[VKuznetsov]

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

Суть дилеммы такова: md5 сам по себе, как способ хеширования не считается безопасным, однако, если соорудить конструкцию вида :

1. генерируем случайную цифробуквенную комбинацию (соль) и хешируем ее
2. дописываем получившиеся данные к паролю пользователя
   
3. хешируем полученную строку.
   

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

 

[jonjonson]

Посмотрите как сделано, например, в laravel.

 

[Yaponchick]

Маразм какой-то... соль-то хранится? значит и брут пройдёт.
Забейте на мд5, используйте алгоритмы которые хэшатся по 1-2 сек. и всё. брут будет лет через 20.

 

[fixxxer]

Не надо изобретать велосипеды, надо пользоваться password_hash(). Если интересно, как эта функция работает (или надо поддерживать музейные версии php) - вот реализация на php: https://github.com/ircmaxell/password_compat

"Сооружать конструкции" самостоятельно не стоит, такая "комбинаторика" может привести к фатальным результатам. Вот пример: http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html

 

[grigori]

@S.Chushkin, иди на тот сайт обсуждать кнопку лайков.

@VKuznetsov, как лучше - зависит от специфики проекта. Для обычного сайта на одном сервере лучше всего использовать встроенную функцию, как рекомендует fixxer. Это важная функция, ее сделали специально обученные люди, которые много лет занимаются этим вопросом. Ничего лучше не придумать, пользуйся по документации.

 

[MiksIr]

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

 

[MiksIr]

К слову о "не один сервер" https://habrahabr.ru/company/yandex/blog/336860/
Особых велосипедов там не изобретают. Берут Аргон, который хочет много памяти и много ввода-вывода в память, от чего GPU становятся черепахами и чуточку сетапят. Дефолтный для password_hash "крипт-блоуфиш" тоже отличается повышенными затратами по памяти, из-за чего и стал дефолтным. И да, они подмешанный секретный ключ тоже используют, но при этом не бегут к простым алгоритмам.

 

[AnrDaemon]

Маразм какой-то... соль-то хранится? значит и брут пройдёт.

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

 

[MiksIr]

И, кстати, в 7.2 включена поддержка Argon2, так что можно будет password_hash('password', PASSWORD_ARGON2I);

 

[fixxxer]

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

Ну и в невозможности использования rainbow tables.

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

Добавить per project secret к соли - конечно, можно (это еще "перец" называют), хуже от этого не будет (если там не встретится \x00, хехе).

 

[AnrDaemon]

Ну и в невозможности использования rainbow tables.

Не совсем так. Радужные таблицы по-прежнему возможно использовать, просто придётся искать каждый хэш дважды. Или сколько раз строка была "посолена".

 

[MiksIr]

Не совсем так. Радужные таблицы по-прежнему возможно использовать, просто прижётся искать каждый хэш дважды. Или сколько раз строка была "посолена".

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

 

[AnrDaemon]

Радужные таблицы строят по хэшу, а не по исходной строке
Да, построить прехэш всех возможных значений по ресурсам действительно сложно.
Но это не означает, что соль предотвращает использование подобных таблиц. И её длина не так важна, как сам факт её использования.

 

[MiksIr]

Радужные таблицы строят по хэшу, а не по исходной строке

Ась?

 

[grigori]

Использование md5 последние годы не рекомендуется, и многими стандартами запрещено.
Функции семейства sha-2 считаются стандартом, но специалистами по безопасности уже не рекомендуются. Сеть биткоин вычисляет порядка 8 миллионов терахешей двойного sha-256 в секунду. Полный перебор всех sha-256 для 8-символьного пароля займет у крупного майнера меньше минуты.

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

 

[fixxxer]

@grigori, ...и именно из этих соображений и придумали "медленные" алгоритмы хэширования типа bcrypt и argon2.

А если правильно пользоваться password_hash + password_needs_rehash с PASSWORD_DEFAULT и своевременно обновлять PHP, можно об этом всем вообще не думать

 

[VKuznetsov]

Изначально немного оговорился, солью здесь служит хеш от случайной строки, случайной длинны от n до m. Для каждой учетки строка своя. В случае использования шифрования - будет где-то храниться ключ в любом случае, даже если он будет для каждого пользователя он свой, как только его украдут - у злоумышленников будет пароль. В случае с хешем его еще пробрутить надо, даже зная соль. Если не мд5 - то что из алгоритмов хеширования посоветуете? Только чтобы желательно была реализация для других ЯП.

В вообще, вопрос был лишь теоретический, понятно дело, что использование мд5 "убивается" об радужные таблицы.

Вообще, суть вопроса "хеш vs шифрование". Просто встречал реализации, где пароли именно шифруют, и сам считаю, что это бред. Но вопрос все равно закрался в голову.

P.S: чего некоторые прямо накинулись - не понимаю...

 

[VKuznetsov]

Спойлер: Оффтоп

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

это просто я там ответил... Запутался в темах немного

 

[MiksIr]

Изначально немного оговорился, солью здесь служит хеш от случайной строки, случайной длинны от n до m. Для каждой учетки строка своя.

Хешировать совсем не нужно, просо случайная строка фиксированной длины.

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

Шифруют во всяких менеджерах паролей и т.п. Если задача - аутентификация пользователя, то только хеш, конечно. Использовать шифрование в этом случае пряча ключ где-то в коде - это просто полнейшая неграмотность.

В случае с хешем его еще пробрутить надо, даже зная соль. Если не мд5 - то что из алгоритмов хеширования посоветуете? Только чтобы желательно была реализация для других ЯП.

BCRYPT (CRYPT_BLOWFISH aka $2y$) - он есть в большинстве современных библиотек
Ну или Argon2, который в принципе более эффективен, лучше тюнится на используемые ресурсы, но для больгиства ЯП придется искать какие-то сторонние расширения.

P.S: чего некоторые прямо накинулись - не понимаю...

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

 

[MiksIr]

Может потому, что нет аргументов, кроме последнего - "в морду"?

Потому что в случае утечки такого ключа (а его 100% защиту никто гарантировать не может) - эти хеши начинают щелкать как орешки. Тебе это уже говорили 100500 раз.

В обоих случаях это рабочие варианты и достаточно надёжные для практического использования.

Бред.