Есть ли смысл в соли из хеша пароля?

Question

[Вячеслав Овчинников]

Прочитал кучу статей про правильное хранение и шифрование паролей.
Из всего существующего самым «популярным» является сохранение пароля в базе в виде md5(md5(password)+salt), при этом соль хранится в базе в соседней колонке (ну или в той же колонке где и хэш).
Такой способ конечно усложняет взлом пароля, но имея хеш и соль взломать все равно можно.
Есть ли смысл, если
1. хешируем пароль: hash1 = md5(password)
2. в качестве соли берем допустим 10 символом от хеша hash1
3. получаем итоговый хэш по старому алгоритму: md5(md5(password)+salt), или
md5( md5(password)+substr(md5(password),0,10) )

Вопрос: будет ли этот способ лучше способа с хранением соли в отдельной колонке, или хуже? Может есть что-то более «хитро-извращенное»?

Answer 1

[nternovoy]

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

Если уж хочется чего-то «хитро-изварщенного», то можно хранить в базе что-то такое:

substr(md5(md5 (<динамическая соль> . $password) . <статическая соль>), 0, 16);

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

substr($login, 0, 3) . ($password, 1, 5) . $login[4] .$password[0] . <статическая соль>

Answer 2

[Александр Зеленин]

на Хабре уже было столько статей на эту тему, что даже отвечать стыдно.

Comments

[Вячеслав Овчинников]

Да действительно. Поторопился с вопросом.
Выбрал алгоритм 5000 кратного хеширования в SHA-512 с солью функцией crypt

Answer 3

[Артур]

Вообще есть довольно стандартное решение: использовать HMAC. Он специально разрабатывался для хэширования с солью. Естественно соль нужно генерировать рандомно и хранить рядом с хэшэм.

Answer 4

[Сергей Протько]

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

А можно сделать еще круче — можно использовать медленные алгоритмы. Тобиш скажем хеширование происходит в цикле. Если колличество итераций динамическое — то и это хорошо. И алгоритмы шифрования надо брать не быстрый md5 а что-нибудь помедленнее, например sha512. Это в свою очередь сведет попытки подбора хэша и генерации радужных таблиц на нет, ибо каждый вариант перебора будет происходить немыслимо медленно. На хорошей видиокарте с CUDA можно в секунду сгенерить миллиончик MD5 хэшей. А так хорошо если сотню сгенерит.

Answer 5

[Леонид Святов]

md5 уже давно не актуален, используйте bcrypt и не ломайте голову.

Answer 6

[Mercury13]

Для чего вообще нужна соль? А для того, чтобы md5(password)+salt было достаточно длинным, чтобы его нельзя было получить из хэша по предвычисленным таблицам. Таблица-то даст что-то, но нет никакой гарантии, что в конце будет именно ваша соль.

По-моему, криптостойкость одна и та же: тот же уровень противодействия перебору и та же защита от таблиц.

Comments

[Вячеслав Овчинников]

Мне кажется что при md5(password)+salt — весь смысл соли теряется. Нужно или md5(md5(password)+salt), или хотя бы md5(password+salt)

[Mercury13]

Конечно, ova777. md5(password)+salt — это то, что находтся под md5, а значит, его надо как-то получить, имея хэш.

Answer 7

[rbtaxi]

Я не силён в криптографии, но насколько я помню, соль использовали не только как способ увеличить строку пароля, а значит и стойкость хеша. Но и как безопасный метод передачи данных от браузера на сервер. Гляньте форумы готовые, движки итп, почему все хронят соли в базе, а не пишут алгоритмы динамических солей?
Скажем, вы пишите форум, решили использовать алгоритм с динамической солью, аля

substr(md5(md5 (<динамическая соль> . $password) . <статическая соль>), 0, 16);

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

Answer 8

[Razaz]

Если с английским все ок, то советую почитать RFC 2898

Answer 9

[galaxy]

Одна из важнейших целей засаливания паролей — не допустить одинаковых хешей в случае совпадения паролей.
Не хотите отдельную колонку — храните соль в той же в качестве префикса фиксированной длины. А еще лучше, продайте велосипед и возьмите crypt() — она умеет и соль, и bcrypt, и все хранится в одной колонке

Answer 10

[acspro]

Ну и как известно, одним из слабых мест md5 является наличие коллизий. То есть по простому два разных куска текста могут задавать один и тот же hash. Поэтому солить md5, при современных вычислительных мощностях - не шибко эффективно. Можно сбрутить также с помощью хеш таблиц. Да и куча онлайн сервисов предоставляет уже несколько лет свои услуги. MD5 последнее время используют больше для сверки контрольной суммы, а как и сказали выше смотрите bcrypt.