Комментарии 28
Интересно, чем существующая crypt их не устроила? и зачем был нужен еще один велосипед?
0
Я так понял, что криворукостью и безалаберностью многих web-разработчиков, которые или не занимались безопасностью хранения паролей вообще (например, хранили в открытом или почти открытом виде), или реализовывали «на отвяжись» (просто md5 без соли, например).
А тут название функции как бы говорит разработчику: для паролей используй меня, девелопернейм, и будет всё труЪ.
А тут название функции как бы говорит разработчику: для паролей используй меня, девелопернейм, и будет всё труЪ.
+1
Совершенно верно, причем такая безалаберность была даже на крупных, известных проектах.
Например:
LinkedIn.com — хранили пароли в SHA-1 и возможно даже без соли вот и похудели на 6,5 миллионов аккаунтов.
Last.fm — 40 млн, hotmail.com, msn.com, live.com и др.
И всё из-за того же.
Например:
LinkedIn.com — хранили пароли в SHA-1 и возможно даже без соли вот и похудели на 6,5 миллионов аккаунтов.
Last.fm — 40 млн, hotmail.com, msn.com, live.com и др.
И всё из-за того же.
0
криворукостью и безалаберностью многих web-разработчиков, которые или не занимались безопасностью
Интересно, как изобретение ещё одного велика, позволит выпрямить руки, сделать разрабов залаберными и заставит их заняться безопасностью?
О шифровании паролей односторонним алгоритмом написано сейчас везде во всех статьях, книгах и документациях, однако, ленивые разрабы остаются ленивыми.
0
Насколько безопасно это решение? Хранить соль хеширования совместно с хешем?
-3
имхо полностью. соль нужна только для того, чтобы по предварительно сгенерированной таблице хэшей пароль не подобрали.
0
Вот из википедии:
Где хранить соль? Не опасно ли хранить ее в открытом виде? Можно ли поместить соль в код и ее использовать для всех паролей?
Все, что может быть украдено, будет украдено. Если вы уверены в защищенности кода, то свой алгоритм хеширования поможет лучше соли. Помните — соль не защищает один конкретный хеш от перебора, поэтому нет цели прятать соль — она хранится в открытом виде рядом с хешем. Задача соли — спасти набор украденных хешей, «удлинняя» пароль, а сделать она это может только в том случае, если у каждого хеша будет своя соль. Поэтому мы храним соль рядом с хешем и для каждого хеша генерируем свою уникальную последовательность символов соли.
0
Да, в википедии такой бред не редко попадается.
Конечно, соль лучше прятать отдельно. Зная соль, можно быстро построить радужные таблицы и пройтись по словарю.
Конечно, соль лучше прятать отдельно. Зная соль, можно быстро построить радужные таблицы и пройтись по словарю.
-2
Тогда вопрос номер раз: где именно её прятать?
Вопрос номер два: в каких продуктах такое есть?
Всякие друпалы не берём. В OTRS, по-моему, соль рядом с хэшем лежит. В Linux («теневые пароли») пароль солят, по-моему, то ли uid/guid'ом, то ли логином. И т.д.
Да и при условии, что для каждого пароля собственная соль (а так и должно быть) таблицу придётся строить для каждого пароля (о чём, кстати, во всеми нелюбимой википедии написано). В том и смысл соли: не дать гарантию, что пароль невозможно подобрать, а максимально усложнить подбор.
Вопрос номер два: в каких продуктах такое есть?
Всякие друпалы не берём. В OTRS, по-моему, соль рядом с хэшем лежит. В Linux («теневые пароли») пароль солят, по-моему, то ли uid/guid'ом, то ли логином. И т.д.
Да и при условии, что для каждого пароля собственная соль (а так и должно быть) таблицу придётся строить для каждого пароля (о чём, кстати, во всеми нелюбимой википедии написано). В том и смысл соли: не дать гарантию, что пароль невозможно подобрать, а максимально усложнить подбор.
+1
у меня постоянно происходит конфликт мыслей. и паранойя не уменьшается даже посолив пароли. и не покидают голову следующие мысли:
вся суть защиты паролей солями и хешами — это усложнить взлом паролей в уже украденной базе.
но вот, тут и проблема. базу кто ворует? очевидно те у кого есть доступ к ней. Но в подавляющем большинстве, те кто имеют доступ к базе — имеют его и к исходникам. Так, как же сработает эта защита, если украли все, исходники и базу?
Или все таки есть способ защитить хеши так что при потери исходников и базы — взлом был «невозможен»?
вся суть защиты паролей солями и хешами — это усложнить взлом паролей в уже украденной базе.
но вот, тут и проблема. базу кто ворует? очевидно те у кого есть доступ к ней. Но в подавляющем большинстве, те кто имеют доступ к базе — имеют его и к исходникам. Так, как же сработает эта защита, если украли все, исходники и базу?
Или все таки есть способ защитить хеши так что при потери исходников и базы — взлом был «невозможен»?
0
ИМХО потеря исходников не грозит ничем (при условии, что прочитав исходники нельзя найти дыры в системе).
Хэши паролей можно потерять по-разному: может сисадмин (или какой-то другой сотрудник) «подсмотреть», могут бэкап сдёрнуть, могут доступ на сервер получить (причём при правильно организации прав доступа сам факт доступа к серверу ещё не означает фатальную угрозу). В крайнем случае, если даже получен root-доступ, вы можете быстро реальную систему перекинуть на другой сервер при этом пользователи не пострадают (но, конечно, лучше попросить сменить пароли к системе).
Конечно, если вы не наблюдаете за системой и она долгое время живёт «автономно», то ничего хорошего в доступе неавторизованного лица нет — но это уже не проблема хранения паролей / соли.
Хэши паролей можно потерять по-разному: может сисадмин (или какой-то другой сотрудник) «подсмотреть», могут бэкап сдёрнуть, могут доступ на сервер получить (причём при правильно организации прав доступа сам факт доступа к серверу ещё не означает фатальную угрозу). В крайнем случае, если даже получен root-доступ, вы можете быстро реальную систему перекинуть на другой сервер при этом пользователи не пострадают (но, конечно, лучше попросить сменить пароли к системе).
Конечно, если вы не наблюдаете за системой и она долгое время живёт «автономно», то ничего хорошего в доступе неавторизованного лица нет — но это уже не проблема хранения паролей / соли.
0
потеря исходников не грозит ничем
дргими словами вскрытие алгоритма самого соления ничем не грозит? можно подробнее этот момент.
0
Ничем… Или должен быть очень хитрый алгоритм (который фактом своего существования как-то защищает открытый пароль).
Во-первых, есть куча opensource проектов, где алгоритм соления известен всем.
Во-вторых, имея регистрацию в системе, жэш и соль пароля, я с определённой вероятностью (для большинства проектов) могу раскрыть алгоритм соления.
И самое главное: соление не гарантирует взломоустойчивость, оно лишь усложняет (замедляет) взлом.
По сравнению со скоростью перебора солёных паролей, скорость изучения алгоритма соления ничтожно мала.
Во-первых, есть куча opensource проектов, где алгоритм соления известен всем.
Во-вторых, имея регистрацию в системе, жэш и соль пароля, я с определённой вероятностью (для большинства проектов) могу раскрыть алгоритм соления.
И самое главное: соление не гарантирует взломоустойчивость, оно лишь усложняет (замедляет) взлом.
По сравнению со скоростью перебора солёных паролей, скорость изучения алгоритма соления ничтожно мала.
0
А как его изучить то? Если соль спрятана в исходниках скрипта, и нам известен только хеш. Даже если взять соль состоящую из даты регистрации йдишника и секретной фразы, из хеша алгоритм соления не получится получить.
0
Алгоритмы я-ля md5($salt. md5($password)) при наличии хэша, соли и самого пароля подбираются на ура (а таких алгоритмов большинство).
Другой вопрос в том, что значит «соль спрятана в исходниках скрипта»? Одна соль на все пароли? Такого не должно быть.
Другой вопрос в том, что значит «соль спрятана в исходниках скрипта»? Одна соль на все пароли? Такого не должно быть.
0
Вот о том и речь. Что нужно знать соль чтобы раскрыть алгоритм каким образом генерируется хэш. Если соль является частью хэша, то искать её даже не нужно, берем соль генерируем таблицу хэшей и пошли перебирать.
Просто когда хэш и соль хранится в разных местах, сложнее добыть и то и другое. Стянул базу не добрался до кода на php. А так получается утянул базу у тебя есть и соль и хэш.
Просто когда хэш и соль хранится в разных местах, сложнее добыть и то и другое. Стянул базу не добрался до кода на php. А так получается утянул базу у тебя есть и соль и хэш.
0
ИМХО если факт публикации алгоритма шифрования / хэширования или чего-либо другого относящегося к криптографии способен нанести ущерб безопасности, то это плохой алгоритм (но при этом допускаю, что в определённых ситуациях закрытый алгоритм поможет избежать дополнительных проблем). С моей точки зрения, взломщику больше усложнит жизнь, например, скорость генерации хэшей (при применении соответствующих алгоритмов).
0
Я, например, солю всегда каким-то статическим параметром из базы. Например, так: hash(«sha256», $user->id.$user->register_time.$user->password); Если исходники не утянут, то секьюрно вроде бы. Если утянут, правда, то ничего не спасёт.
0
Считается, что алгоритм шифрования заранее известен злоумышленнику. Соль можно считать частью алгоритма шифрования.
И ещё, по идее соль должна быть случайной.
И ещё, по идее соль должна быть случайной.
0
Естественно, лучше айца хранить по отдельным корзинам, например, в серверном коде соль, в базе лишь хеш. Есть системы, которые требуют чтобы эти данные хранились лишь в оперативной памяти, тогда даже кража сервака не так страшна. В том же линукс прямой доступ к shadow имеет телько root, остальные делают запросы через сервис.
В вэбе большая часть пользователей используют в качестве пароля обычные слова-дату, поэтому зная соль по хешу можно очень быстро найти пароли по словарю.
В вэбе большая часть пользователей используют в качестве пароля обычные слова-дату, поэтому зная соль по хешу можно очень быстро найти пароли по словарю.
0
> Естественно, лучше айца хранить по отдельным корзинам
Это бесспорно :)
> например, в серверном коде соль
Одна соль для ВСЕХ пользователей? Она тогда резко теряет смысл, разве нет?
Или вы про то, что её как-то динамически генерировать для каждого пользователя?
> В том же линукс прямой доступ к shadow имеет телько root, остальные делают запросы через сервис.
Ну так и в вебе, вроде, хэши не публичная инфа. Речь идет про компрометацию системы или хэшей.
Это бесспорно :)
> например, в серверном коде соль
Одна соль для ВСЕХ пользователей? Она тогда резко теряет смысл, разве нет?
Или вы про то, что её как-то динамически генерировать для каждого пользователя?
> В том же линукс прямой доступ к shadow имеет телько root, остальные делают запросы через сервис.
Ну так и в вебе, вроде, хэши не публичная инфа. Речь идет про компрометацию системы или хэшей.
0
«Быстро построить» это насколько быстро? Даже если соль известна, но индивидуальна для каждого пароля, таблицы придётся строить для каждого пароля отдельно.
0
> P.S после 15 сек как добавил статью карма -1,0 и рейтинг –0,5, спасибо за «хорошие» впечатления о данном ресурсе на 1ом же посте.
Chameleoh, не парься, хабр не для адекватных людей… статьи лучше пиши в своем блоге, а тут читай желтуху и иногда что нибуть интересное…
Chameleoh, не парься, хабр не для адекватных людей… статьи лучше пиши в своем блоге, а тут читай желтуху и иногда что нибуть интересное…
-1
(facepalm) password_needs_rehash
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изменить настройки темы
PHP 5.5 «API хэширования паролей»