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