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

tardis

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

Здравствуйте, не могу понять как лучше хранить зашифрованные crypt'ом пароли в базе - вместе с salt или без.
Кстати, у меня сrypt копирует salt в начало возвращаемой строки и при MD5-шифровании, а не только при DES, вопреки утверждениям php.net.

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

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

В общем интересует, какой способ более правильный и существенны ли те подводные камни, которые я описал.
 

dimagolov

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

HraKK

Мудак
Команда форума
hint:
salt = crypt( salt+password) !=crypt(salt).crypt(password)
 

tardis

lazy
я правильно понимаю, что salt суммируется со строкой, после чего эта "сумма" хэшируется?

Автор оригинала: HraKK
сrypt( salt+password) !=crypt(salt).crypt(password)
я так и не считал
 

tardis

lazy
я просто полагал, что salt - это нечто вроде ключа, который влияет на сам ход шифрования
но тем не менее, если кто-то будет знать salt ему ведь легче будет осуществить перебор
-~{}~ 02.10.08 01:46:

И еще CRYPT_MD5 - это ведь не то же самое что простое md5-шифрование, но с salt?
 

dimagolov

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

tardis

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

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

поэтому наверное целесообразней хранить такой хэш
OMOhp1QU2.ElZ9OTE4CIh/
нежели такой
$1$12345678$OMOhp1QU2.ElZ9OTE4CIh/

тогда перебирать придется гораздо дольше
 

dimagolov

Новичок
ты квартиру тоже не запираешь, потому что если кто-то подберет или найдет потерянный тобой ключ, то сможет открыть? :)

-~{}~ 01.10.08 19:11:

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

MiksIr

miksir@home:~$
tardis в принципе хренение соли вдали от пароля могло бы дать пользу, еслибы не давало столько вреда ;) Первый вред ты сам описал - невозможность поменять соль. Второй вред более весомый - соль будет одна и та же, а это очень плохо - соль для каждого пароля должна генериться своя, думаю, догадаешься почему.
Так что хранение такого хеша пароля в том виде, что выдал crypt - залог спокойствия и уменьшения головной боли в далнейшем... например в вопросах совместимости, переносимости и т.д.
 

tardis

lazy
dimagolov
Но перебирать ведь могут не только на сайте, но и слив каким-либо образом предварительно базу (но при этом, например, атаку заметили и базу закрыли, т.е. слить данные слили, а доступа не получили). После чего решили брутить пароли на своей машине. Даже пусть перебирают по словарям наиболее употребимых паролей. Преположим, что у некого юзера пароль password. Соль пусть будет такой$1$12345678$, хэш (с содержащейся в ней солью) таким
$1$12345678$o2n/JiO/h5VviOInWJ4OQ/
В таком случае проверив crypt("password","$1$12345678$") == $1$12345678$o2n/JiO/h5VviOInWJ4OQ/ злоумышленник узнает, что за данным хэшем скрывается пароль password. А если мы будем хранить только o2n/JiO/h5VviOInWJ4OQ/, то чтобы узнать пароль ему придется проверять комбинацию $1$12345678$password, которой в его словарике паролей конечно же нету. Так ведь?

Автор оригинала: dimagolov
ты квартиру тоже не запираешь, потому что если кто-то подберет или найдет потерянный тобой ключ, то сможет открыть? :)
salt в данном случае скорее не ключ, а чехол для ключа, который мешает сфоткать ключ и сделать по фото дубликат

-~{}~ 02.10.08 02:21:

MiksIr
можно например в качестве соли использовать логин или даже лучше часть логина, причем не обязательно с начала

-~{}~ 02.10.08 02:23:

а что касается переносимости, то если на сервере, например, не поддерживается CRYPT_MD5, а ты изначально использовал его, то как ни храни, все равно хрен чо сделаешь
 

MiksIr

miksir@home:~$
можно... наверняка этот вариант попробуют ;) скорее уж правильнее придумать свой формат хеша - встроить туда соль, но хитро... в середину, или через букву ;)
Но все же это все от лукавого. Вероятность работать потом с этим паролем в другом софте (и поиметь гимор) выше, чем вероятность потерять базу (хотя смотря какова команда разработки). От словарного перебора лучше защищаться на стадии выбора пароля пользователем, а от буквенного перебора - длинной пароля... можно требовать наличие букв и цифр и даже знаков припинания - если пользовательские данные действительно настолько дороги.
Не создавайте проблем на ровном месте.

-~{}~ 02.10.08 02:29:

> то если на сервере, например, не поддерживается CRYPT_MD5
такой сервер придется еще долго и упорно искать
 

tardis

lazy
Автор оригинала: MiksIr
можно... наверняка этот вариант попробуют ;)
Автор оригинала: tardis
или даже лучше часть логина, причем не обязательно с начала

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

MiksIr

miksir@home:~$
Послушайте, вам чужой опыт граблей или поспорить? Более правильный способ - не строить на каждый пук велосипед. Если вас ночами будет греть то, что пароли хранятся в хитровые...м формате, то делайте так. Только если у вас сопрут базу, то где гарантия, что не сопрут код с этим самым алгоритмом генерации хеша... вот ведь обидно будет - а столько сил то потратили.
 

tardis

lazy
:) да нет, я не спора ради, а расширения кругозора для
ладно, я сам себя за излишнюю любознательность наказал, мог бы уже давно крепко и безмятежно спать
зато хоть какая-то ясность в голове появилась
спасибо за развернутую полуношную консультацию

-~{}~ 02.10.08 02:46:

а, еще один вопрос по-прежнему интересует
CRYPT_MD5 - это ведь не то же самое что простое md5-шифрование, но с salt?
 

cDLEON

Онанист РНРСlub
Что за камни в сторону "соли" ?
Даже подобрав, не факт, что это будет один и тот же результат - следовательно (говоря простыми словами, md5(password)==md5(other_password) и если ты будешь использовать соль, то совпадения не произойдёт.
 

dr-sm

Новичок
tardis, можешь, в качестве антипараноидальных мер, еще добавлять к паролю какой нибуть secret key, известный только на сервере.

те два в одном:

$pwdhash = $salt . ':' . md5($secret . $password . $salt);

cDLEON, вероятности совпадения хешей паролей с солью и без соли равны, имхо ,)
 

fixxxer

К.О.
Партнер клуба
вероятность совпадения хэшей от паролей обычной их длины (<30 bytes) равна практически нулю

по крайней мере такие коллизии еще никто не находил
 

dimagolov

Новичок
Соль пусть будет такой$1$12345678$, хэш (с содержащейся в ней солью) таким
$1$12345678$o2n/JiO/h5VviOInWJ4OQ/
В таком случае проверив crypt("password","$1$12345678$") == $1$12345678$o2n/JiO/h5VviOInWJ4OQ/
я вот все понять не могу, то ли у меня лыжи не едут, то ли ты таки не понял что такое хеш и в каком месте пользуется соль при хешировании данных.

1. К брутфорсу хеш не имеет никакого отношения. Защита от подбора пароля осуществляется совсем с другого бока.
2. хеш это необратимое преобразование. то есть такое, что априории нельзя раскодировать. То есть применяется для того, чтобы хранить ответственную инфу там, где она МОЖЕТ и скорее всего будет скомпрометированна. что можно с хеш-функциями делать, так это строить словари. Ну еще вон радужный метод есть. Но все они дают результаты при ограниченной длинне исходных данных. Соль можно скомпрометировать только одним способом: октрыв правила ее примешивания к данным. Но и это само по себе ничего не дает, надо строить именно под нее словари и только после этого мы можем имея хеши попытаться угадать пароли к ним.
 
Сверху