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

[duburlan]

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

вот несколько плюсов навскидку
1. если после sql-иньекции злоумышленник узнает данные из БД - то они ему не сильно помогут...
2. многие люди имеют доступ к БД. к пхпмайадмину.. и среди них могут оказаться и шибко любопытные... и если пароли хранятся в октрытом виде - то можн попытаться войти на почту юзера используя сей пароль... ну и также в icq и тд...
3. за дамп базы не так страшно... ну стырят хеши и что? без соли они будут долго ковырятся (если вообще возьмутся)
4. стыреть пароль могут также и при передаче от клиента к серверу... поэтому можно сделать вообще почти идеальный вариант - юзер на этапе регистрации вводит пароль... тутже на месте получаем его md5 - при помощи небольшой библиотеки на js. на сервер отправляется md5 от пароля.. а уже там к нему добавляется соль и применяется еще всякие дополнительные примочки...

 

[MiksIr]

Алгоритм соления является преимуществом при условии его нераспространения. Т.е. 1) вы уверены, что код не сопрут всесте с базой, 2) с кодом работают только мега-доверенные лица и стадии разработки так же хорошо защищены, 3) вы никому и никогда этот код не покажите, 4) вы никогда не будете интегрировать другой софт с пользовательской базой напрямую.
При абсолютном соблюдении этих условий - можете делать свой алгоритм соления. Правда, тогда непонятно, зачем вообще в такой защищенной среде пароли шифровать.
При нарушении хотя бы одного из этих условий смысл своего соления теряется и обретаются проблемы: 1) ваша соль вряд ли будет столь же ресурсоемкой, чем crypt, 2) вы не сможете поменять алгоритм соления, когда поймете, что вы вряд ли умнее тех всех людей, которые разрабатывают алгоритмы для crypt

 

[cDLEON]

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

Бред. Даже зная соль подобрать пароль не так уж и просто.

 

[Wicked]

MiksIr
имхо ты перепутал термины хэширования и соления

 

[tardis]

Автор оригинала: duburlan
вот несколько плюсов навскидку

Я вообще эту цитату комментировал:

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

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

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

это да

Автор оригинала: dimagolov
то есть взломщик должен будет строить свои словари для каждой уникальной соли

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

 

[MiksIr]

Wicked, почти не перепутал. Тут такие темы ходят, типа "а давайте хитро посолим, а потом на это дело md5 скажем". Но вообще, можно называть все это алгоритмом криптования, что бы больше никто к словам не придирался.
cDLEON, хто здесь? Вы как, урывками, урывками, да? )

 

[phprus]

MiksIr

cDLEON, хто здесь? Вы как, урывками, урывками, да? )

cDLEON Был прав, когда утверждал, что:

Бред. Даже зная соль подобрать пароль не так уж и просто.

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

Предположим, что у нас есть 10^3 пользователей и словарик на 10^6 слов, которые могут являться паролями. Классическая реализация без соли потребует 10^6 операций хеширования для построения списка хешей и очевидно, что это число не зависит от числа пользователей. Дальше в списке пользователей ищутся те пользователи у которых хеши совпадут с предгенерированными.
В случае наличия соли при тех-же исходных цифрах наша хеш-функция станет функция 2-х аргументов, каждый из которых надо прогнать по всему допустимому множеству и в таком случае мы получаем уже 10^9 операций хеширования, что есть уже побольше.
Соль дает защиту не по тому, что она как-то удлиняет и усложняет пароль, а по тому, что она делает непригодными заранее сгенерированные словари. И для проведения даже словарной атаки на пароль пользователя надо будет для каждого из них генерировать свою таблицу соответствий возможный пароль-хеш с учетом того, какая соль была у этого конкретного пользователя.

 

[MiksIr]

Да об этом тут все 3 страницы говорится. Читайте тему, что ли...

 

[phprus]

MiksIr
Я прочитал, но я не могу понять почему вы утверждаете, что лучше использовать функцию crypt.

Кроме того Вы принципиально не правы в своем утверждении:

Алгоритм соления является преимуществом при условии его нераспространения.

Даже при известном алгоритме соления криптостойкость значительно возрастает.

 

[MiksIr]

> Даже при известном алгоритме соления криптостойкость значительно возрастает.
Возрастает, возрастает.. и вырастает в большого и взрослого дядю. Вырастает по сравнению с чем?

>я не могу понять почему вы утверждаете, что лучше использовать функцию crypt.
http://phpclub.ru/talk/showthread.php?postid=817461#post817461

-~{}~ 05.10.08 12:13:

> Кроме того Вы принципиально не правы в своем утверждении:
>> Алгоритм соления является преимуществом при условии его нераспространения.
Давай я придумаю свой алгоритм соления, и дам вам сгенерированные хеши и соль... но алгоритм не скажу. А вы попробуйте хоть один словарик построить.

 

[phprus]

MiksIr

Возрастает, возрастает.. и вырастает в большого и взрослого дядю. Вырастает по сравнению с чем?

По сравнению с хешированием без соли.

Давай я придумаю свой алгоритм соления, и дам вам сгенерированные хеши и соль... но алгоритм не скажу. А вы попробуйте хоть один словарик построить.

А давайте я вам дам базу в 10000 пар <хеш, salt> и дам алгоритм по которому я строил этот соленый хеш (да к примеру md5(пароль + соль)), а вы попробуйте построить хоть один словарик к этому набору. У вас так-же ничего не получиться.

http://phpclub.ru/talk/showthread.php?postid=817461#post817461

и в-третьих обеспечивается совместимость.

Не вижу проблем с совместимостью при использовании стандартизированного md5, в отличие от не стандартизированного crypt.

 

[Wicked]

MiksIr
security through obscurity - не наш метод, особенно касательно алгоритмов

 

[tardis]

после поста phprus наконец-то понял, что это

то есть взломщик должен будет строить свои словари для каждой уникальной соли

и это

перебирать пароли не строя словари хэшей, а сравнивая так сказать в рил-тайм

по сути одно и то же, так как подразумевает одно и то же кол-во операций хэширования

 

[MiksIr]

phprus - 10^9 операций md5 занимает у меня около 16 минут, 10^9 операций crypt - около 100 часов. Не так много, именно по-этому md5-crypt считается устаревшим, но смысл ясен?

> от не стандартизированного crypt.
и о чем тут говорить?

Wicked, несомненно, не ваш.

 

[phprus]

MiksIr

и о чем тут говорить?

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

10^9

10^6 - это не очень большой список возможных паролей. Да и пользователей может быть больше чем 1000.

именно по-этому md5-crypt считается устаревшим, но смысл ясен?

Но вот только судя опять-же по ману и по реальным тестам моя система использует именно алгоритм md5 внутри crypt. Об этом говорит строка $1$ в начале хеша. Хотя с тем, что crypt несколько медленнее, чем md5 я согласен.

 

[MiksIr]

phprus, да, $1$ - это md5. Только crypt делает множественное хеширование специально для увеличения времени работы. Подробнее в вики было описано.
И... сейчас сложно найти серверные ОС, которые не поддерживают хотя бы md5-based crypt. Так что теоретически - возможно, практически - маловероятно.

 

[dr-sm]

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

 

[Wicked]

.

 

[dr-sm]

Wicked, единственной радужной возможностью для взломщика будет weak password, находящийся в словаре .
ты путаешь словарь и rainbow table, состоящий из предварительно рассчитанных хешей.

тут вот tardis сделал неверный вывод о том, что дескать если база унас является несливаемой, то паролям будет неплохо и в открытом виде.
суть хранения хеша, как раз в том, что мы сами не знаем пароль, который установил пользователь, но можем проверить .
основные требования к фунции хеширования:
1. нереверсируемость.
2. минимальная вероятность коллизий.

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

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

 

[Wicked]

dr-sm
торможу

но перебор по словарю все равно будет в 1000 раз медленнее, с этим-то ты согласен?