Сторми Питерс (Stormy Peters), директор по взаимодействию с разработчиками, сообщила (https://blog.mozilla.org/security/2014/08/01/mdn-database-di.../) об инциденте с безопасностью на одном из серверов Mozilla, в результате которого в публичном доступе появилась база данных, содержащая данные об около 76 тысячах e-mail адресов и 4 тысячах хэшей паролей участников сообщества Mozilla Developer Network. Данные появились 23 июня и оставались доступны примерно 30 дней. В качестве причины инцидента называется сбой процесса чистки БД, в результате которого в публично доступной директории остался coredump с отрывками БД сайта MDN (https://developer.mozilla.org/en-US/).
В процессе анализа инцидента не были выявлены явные свидетельства доступа к данной информации сторонних лиц, но тем не менее вероятность утечки не исключается. Всем пользователям, аккаунты которых были затронуты инцидентом отправлены уведомления с просьбой установить новый пароль. Сообщается, что в настоящее время невозможно использовать подобранные по хэшам пароли для входа в Mozilla Developer Network, но злоумышленники могут попытаться подключиться к другим сервисам, в которых пользователь установил тот же пароль.
URL: https://blog.mozilla.org/security/2014/08/01/mdn-database-di.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=40319
Господа, а по логике то плевать, не? Участники подобных проектов используют криптостойкие пароли, на сам подбор которых уйдут годы, и глупо было бы отвергать то, что база хэширована sha512 - в таком случае прямой перебор идет лесом. Думаю, что для серьезных проектов подобного рода утечки хэшэй совершенно не критичны, а вот сам факт нарушения модели угрозы - да, косяк..
> sha512 - в таком случае прямой перебор идет лесом.Прямым перебором никто и не будет подбирать, радужные таблицы рулят!
А под SHA512 радуга вообще бывает?
Конечно, только занимает 864Гб. Взять можно здесь http://project-rainbowcrack.com/table.htm
> Конечно, только занимает 864Гб.Вообще-то зависит от длины атакуемого пароля :). А так - производители винчей радоваться должны, я бы на их месте даже коммитил в пасскрякеры тихой сапой ;].
Там только sha1. sha512 более криптостойкий.
А еще можно соли добавить.
> А еще можно соли добавить.Ты добавил? Покажь коммит!
Но мой пароль должен бы в радужной таблице. Или хотябы пободный. И то алгос пободия на столько разнообразен, что лишь на толику сокращает время подбора. Поправь меня, если я заблуждаюсь, буду благодарен.
Для примера: %@#20_0p3nN3T_14#@% - обломается радужная таблица, если к тому же добавлять год.месяц и автоматом менять цифру месяца в удобном для тебя порядке, о которм знаешь только ты. Я, кстати, примерно так и делаю раз в месяц.
Нет, не должен. В таблице будет пароль, хэш которого совпадает с вашим. Коллизия-с..
Скорее нет, чем да. Скажем, у радужной таблицы пространство ключей 10^17, сколько такие таблицы занимают места можно прикинуть сходив по ссылке выше.Тогде вероятность того, что в эти таблицы входит элемент типа %@#20_0p3nN3T_14#@%, что, грубо говоря, похоже на, скажем, 96^19, составит 10^17/96^19.
Если же пространство ключей ограничено только пространсвом ключей хешей, то в нашем случае вероятсноть будет порядка 10^17/2^512.
Всё грубо, но я к тому, что не надо бояться коллизий. Лучше бойтесь атак на поиск прообраза, коль скоро речь идёт о хранении хешей паролей.
Не забывай про http://ru.wikipedia.org/wiki/Парадокс_дней_рождения
Парадокс дней рождения работает если вы ищете пару люыбх p1, p2, такую, что h(p1) == h(p2). При утёкших хешах же вы ищете такое любое p2, что h(p2) == H, где H фиксированное и равно h(p1), так как p1 тоже фиксированное, и вы его не знаете.
Если к паролю добавляется соль, то радужные таблицы помогут не сильно. Просто гипотетически пусть считается md5 от (user_name password user_name). Ну и чем здесь помогут радужные таблицы?Предположим они скажут, что выбранной контрольной сумме соответстует строка "aaaabbbasaassa", но ты ее не можешь послать на удаленный сервер, т.к. к ней добавят имя пользователя и сумма не сойдется.
> Если к паролю добавляется соль, то радужные таблицы помогут не сильно. Просто"Если" - хорошее слово. :))))))))
Я к тому, что радужные таблицы имеют достаточно ограниченную применимость
> Я к тому, что радужные таблицы имеют достаточно ограниченную применимостьАй, что ты, вихрь! Расскажи это хэшкоту, а?
Hashcat не использует таблицы. Он брутит.
> Stormy wrote on August 1, 2014 at 6:08 pm::
> The passwords included salts that were unique to each user record.https://blog.mozilla.org/security/2014/08/01/mdn-database-di...
> но злоумышленники могут попытаться подключиться к другим сервисам, в которых пользователь установил тот же пароль......и ту же соль :)
мне на почту пришло уведомление об инцеденте -- в котором была ссылка на пост, в котором говорится:
"... The encrypted passwords were salted hashes and they by themselves cannot be used to authenticate with the MDN website today. ..."
При чём тут соль?Утек хеш с солью. Злой дядя сбрутил пароль и пошёл на твою страницу в твиторе, указал тот же пароль, твитор приделал к указзаному паролю соль из своей базы и захешировал. Результат сравнил с хешем из базы. Если ты имел глупость использовать на твиторе тот же пароль, то твитор аутентифицирует злого дядю как тебя-настоящего.
> При чём тут соль?
> Утек хеш с солью. Злой дядя сбрутил пароль и пошёл на твою
> страницу в твиторе, указал тот же пароль, твитор приделал к указзаному
> паролю соль из своей базы и захешировал. Результат сравнил с хешем
> из базы. Если ты имел глупость использовать на твиторе тот же
> пароль, то твитор аутентифицирует злого дядю как тебя-настоящего.О дааааааа, соль!!!! Валшебная пуля!!!!
Она-ж криптографически считается, соль-то! Неужто? Давно ли?
Мужик, ты "Введение в криптографию"-то видал?
>> При чём тут соль?
>> Утек хеш с солью. Злой дядя сбрутил пароль и пошёл на твою
>> страницу в твиторе, указал тот же пароль, твитор приделал к указзаному
>> паролю соль из своей базы и захешировал. Результат сравнил с хешем
>> из базы. Если ты имел глупость использовать на твиторе тот же
>> пароль, то твитор аутентифицирует злого дядю как тебя-настоящего.
> О дааааааа, соль!!!! Валшебная пуля!!!!
> Она-ж криптографически считается, соль-то! Неужто? Давно ли?
> Мужик, ты "Введение в криптографию"-то видал?Ты о чём вообще? Я лишь сказал предыдущему оратору, что наличие соли на двух разных сервисах его не спасёт, если утёк хеш (и был потом сбручен) одного с одного сервиса, а на обоих он использует один пароль.
Что касаемо "как считается соль", то она не считается, а, в идеале, генерируется как псевдослучайное значение.
Что пытаешься донести ты - неясно.
> наличие соли на двух разных сервисах его не спасёт, если утёк хеш (и был потом сбручен)если был бы сбрутен, то да.
но как сбрутить хеш с солью?
это же неимоверные усилия. (нельзя вспользоваться готовой базой. и нельзя возпользоваться распределённым подходом если остальные участники потенциального распределения не заинтересованы в этой же соли. а соль разная у каждого логина, так что да -- ни кто не заинтересован в распределённом бруте).
apache index забыли на папку дампа снять?
> apache index забыли на папку дампа снять?ты бы ещё сказал бы -- "забыли поставить галочку 'Скрытый' в свойствах файла в проводнике?" :)
Я так и знал, что с 29-ой версии разработку Firefox'а по-тихому угнали люди из Гугла.
Это наш шанс наконец-то закоммитить поддержку webp в firefox!
Это были старые пароли, тех, кто ещё не входил через Persona
> Dave wrote on August 1, 2014 at 5:23 pm:
> MDN currently requires a sign in with Persona. What was in the password fields that were leaked?
> Stormy wrote on August 1, 2014 at 5:34 pm::
> It was the old password, not the Persona password.https://blog.mozilla.org/security/2014/08/01/mdn-database-di...
Шёл 2014й год, люди продолжали наступать на всё те же грабли:
- используя быстрые хэш функции тпиа sha* для хранения паролей
- используя во всех формах ограничения на длину пароля, что заставляет пользователей придумывать или простые пароли или те, которые не возможно запомнить (F!12fj-v1zxz).
- продолжая использовать пароли вообще.
> Шёл 2014й год, люди продолжали наступать на всё те же грабли:
> - используя быстрые хэш функции тпиа sha* для хранения паролей
> - используя во всех формах ограничения на длину пароля, что заставляет
> пользователей придумывать или простые пароли или те, которые не возможно запомнить
> (F!12fj-v1zxz).Ага, и часто ограничивают не только длину, но и набор символов.
> - продолжая использовать пароли вообще.А есть реальная универсальная альтернатива?