Шифрование паролей

[Wicked]

а я бы, кстати, не советовал использовать crypt().
доводы:
1) оно сильно зависит от отперационных систем (насколько я помню, на маках нету даже md5-варианта)
2) чтобы выбрать md5-хэширование, нужно поплясать с бубном, вручную генерируя строки вида $1$...$
3) всякие ограничения на соль: для md5, например, не больше 8 значащих символов

лично я выбираю такой способ хранения:
поле для md5|sha1(соль + пароль) + отдельное поле для соли

 

[MiksIr]

Wicked
1) возможно не на всех есть... у меня на телефоне точно нет - я проверил. Правда и субд там нет... странно.
2) проблема сгенерить соль в виде '$1$' . $salt . '$'? Странное представление о плясках с бубном
3) Длина соли при известном алгоритме ее использования никак не поможет.

-~{}~ 02.10.08 14:44:

Кстати, почитайте всеж в вики... об алгоритме примешивания соли и получения хеша. И почему он ныне считатется не так хорош. И потом посмотрите на свои md5(соль+пароль)

 

[Nelius]

$hash = sha1(md5($password.$uniq_user_salt.$server_key));
В БД поля для хранения хэша и соли для юзера.

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

Но, ИМХО, кто смог спереть базу, скорее всего сможет спереть и скрипты и узнать какой алгоритм был использован, так что все бесполезно.

Из того что реально может улучшить защиту (по моему мнению):
- Использовать sha256 - или любой другой "strong" алгоритм хэширования
- Запретить юзерам с "мощными" правами использовать простые пароли, так как первым делом будет использован не брутфорс а прогон по списку известных хэшей
- Идеальной защиты не существует, "прочная" защита на мой взгляд, это когда уделяется внимание всем частям системы в целом. Ну и конечно золотое правило, обрабатывать ВСЕ входные данные перед использованием, НО не фильтровать а "отбрасывать" и выдавать сообщение об ошибке.
- Уделять внимание защите не только самого приложения но и сервера в целом, так как никто не станет биться головой об стену а будет искать обходные пути.

 

[Wicked]

MiksIr
1) ну ты тут ёрничаешь, а нас в свое время изначальное использование crypt() привело к написанию замены для него на чистом пхп - класса на 88 строк
использовали бы обычный md5 с отдельной солью - этого бы не потребовалось.
2) $salt = '$1$' . strtr(substr(base64_encode(md5(..., true)), 0, 8), '+', '.') . '$';
вместо
$salt = md5(...);
- если и не пляски с бубном, то уж точно не очень красиво.
3) я понимаю. просто не люблю всякие искусственные ограничения.

поэтому и посчитал нужным предупредить

Кстати, почитайте всеж в вики... об алгоритме примешивания соли и получения хеша. И почему он ныне считатется не так хорош. И потом посмотрите на свои md5(соль+пароль)

это мне? ссылку

 

[Beavis]

Так кто в паре слов доступно объяснит, нафига соль, кроме того что в md5(pass.salt) ещё приписывать к началу?

 

[MiksIr]

Ссылка была выше. Именно там рассказано, почему реализация crypt несколько сложнее md5(pass+salt)... и в новых алгоримах ее еще стараются усложнить.

-~{}~ 02.10.08 16:33:

2) $salt = '$1$' . Salt::generate(8) . '$'
=)

-~{}~ 02.10.08 16:44:

Beavis, соль нужна для 2-х вещей. Первое - что бы одинаковые пароли имели разные хеши. Второе - усложнить задачю подбора по словарю (на каждый пароль придется строить свой словарь) и перебором (на каждый вариант пароля придется создавать столько хешей, сколько разных солей мы имеем). Скажете "плевое дело, построить словарей сколько надо?"... ну вот развитие crypt идет как раз в сторону многократного хеширования и т.п. - т.е. сознательное увеличение вычислительных потребностей для построения хеша.

 

[Andre]

кстати, вот почему нужна соль http://www.passcracking.ru/

 

[Beavis]

MiksIr
да я не спрашиваю зачем нужна соль, я просто попросил чтоб мне в двух словах объяснили в чем преимущество $salt.md5($pass.$salt) перед md5($pass.$salt)

 

[kruglov]

Тоже интересно, ибо security by obscurity - не наш метод.

 

[MiksIr]

Beavis вы формулируйте пояснее свои вопросы. Второй вариант - это с фиксированной солью, зашитой в коде?

 

[dr-sm]

Автор оригинала: MiksIr
Кстати, почитайте всеж в вики... об алгоритме примешивания соли и получения хеша.
И почему он ныне считатется не так хорош. И потом посмотрите на свои md5(соль+пароль)

ну не знаю, для стандартных нужд, по моему, вполне достаточно мд5 с солью.
а уж если параноит прям, по полной, то тогда конечн нада юзать PBKDF2 уже .

 

[kruglov]

Я, кажется, понял.

Beavis
Salt приписывается к началу, чтоб она вообще была известна. Хранить-то ее надо где-то.

 

[HraKK]

Systems that use PBKDF2
* Wi-Fi Protected Access (WPA and WPA2)
что WPA что WPA2 ломаются за 15 минут.

 

[MiksIr]

dr-sm, для стандартных целей лучше использовать крипт. Ибо это во-первых более криптостойко, во-вторых не сильно сложнее и в-третьих обеспечивается совместимость. Т.е. скорее "а какой резон использовать md5 с солью, если можно crypt?". Кому знакома проблема переноса базы пользователей какого-нить одного движка на другой или интеграция нескольких продуктов для авторизации по одной базе - поймут, насколько важна совместимость, ну... остальные пойдут по своим граблям.

 

[dr-sm]

HraKK ну только если weak passphrase, а так чета слабо верицо

 

[MiksIr]

ps: уж что может быть проще на пхп, чем сказать crypt('password') и получить хеш с солью.

 

[dr-sm]

MiksIr, по поводу совместимости полностью согласен.
если же она не важна, то использовать крипт или мд5, это дело вкуса скорее ))).
я к тому, что криптостойкость тут не имеет особого значения, тк возможность слива базы, это такая мега дыра, что дальше уже некуда ).
еще, как вариант, можно средствами самой СУБД защититься,
если user'у дать доступ к таблице пользователей только через хранимые процедуры например.

 

[Beavis]

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

 

[tardis]

ох и разошлись вы тут без меня

Автор оригинала: dimagolov
К брутфорсу хеш не имеет никакого отношения. Защита от подбора пароля осуществляется совсем с другого бока.

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

Автор оригинала: dimagolov
хеш это необратимое преобразование. то есть такое, что априории нельзя раскодировать.

уж это-то я как раз прекрасно понимаю, поэтому слово "расшифровать" у меня стоит в кавычках

Автор оригинала: dimagolov
Соль можно скомпрометировать только одним способом: октрыв правила ее примешивания к данным

что мы и сделаем, если будем хранить в базе конструкцию
$1$12345678$o2n/JiO/h5VviOInWJ4OQ/, из которой сразу становится понятно, что пароль шировали md5-crypt'ом с солью $1$12345678$.

А дальше засвеченная соль может позволить подобрать недлинный пароль вышеописанным способом перебора, а вот в случае же если ее не светить, подобрать даже самый короткий пароль (хоть 123) станет нереально.

Автор оригинала: dr-sm
я к тому, что криптостойкость тут не имеет особого значения, тк возможность слива базы, это такая мега дыра, что дальше уже некуда ).

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

 

[dimagolov]

сила хранить в базе конструкцию $1$12345678$o2n/JiO/h5VviOInWJ4OQ/ в том, что соль будет уникальна для каждого пароля. при этом нельзя будет выявить одинаковые пароли по одинаковому хешу и как следствие понять какие из них простые, а какие нет. то есть взломщик должен будет строить свои словари для каждой уникальной соли.

п.с. все вышесказанное не запрещает делать предварительное хеширование пароля с единой "секретной" солью, которую держать, например, в зазенденом коде.