Парольная политика — организационная мера. Очень важная и правильная. Также как и осведомленность сотрудников о том, что пароли не надо выкладывать на pastebin, ssh ключи пушить в github, и записывать секреты на бумажках рядом с мониторами. Но текст не об этом.
Мы сводим к невозможной офлайн атаку через доступ только к одному хранилищу.
Не знаю сколько систем вы атаковали, но могу сказать по своей статистике за 5 лет, что это очень хороший уровень защиты. Про его обходы написано в теле статьи.
Это вообще не security through obscurity, это называется разделяемый секрет.
Security through obscurity — это если бы атакующий не знал алгоритма хэширования.
Эта соль будет в базе и захватив хранилище можно будет проводить атаку.
Если соль не будет в базе, а будет одна на всех — то можно будет быстро найти все одинаковые пароли.
«Ещё я интуитивно делаю хешеривание на стороне приложения, а не в БД — избегаю передачи пароля и глобальной соли лишний раз даже на локальной машине по файловым сокетам, не говоря о сети — мало ли кто как к каналу присосался. Или к логам БД.»
напишите как схема работает, клиент передает hash(login.salt), где hash вычисляется на JavaScript?
«Если у нас есть 624 последовательных числа сгенерированных Mersenne Twister, то применив этот алгоритм для этих последовательных чисел, мы получим полное состояние Mersenne Twister» а зачем это делать?
Все проще!
У нас есть seed и rand и они зависимы между собой. Связь однозначная.
Если же значения ранда модулированные, то есть mt_rand(0,N), то надо больше rand, но поверьте — 624 — это ПРОСТО ДОФИГА :)
См. www.slideshare.net/d0znpp/dcg7812-cryptographyinwebapps-14052863 слайды с 18го
На тему получения pid+microtime от самого аппсервера решал эту задачу и добавил в слайды с Defcon-Russia: oxod.ru/DCG7812-Cryptography-in-webapps.pdf
Вместе с этим инструментов и хотел бы использовать, но AMD все испортило :(((
Самая главная сложность — server-status. С этого можно начать и закончить.
Про Date — вы так атаковали хотя бы один сервер с балансером или фронотэдом? Как?
Про атаки на сами веб-приложения все-таки не совсем не понятно по статье. Давайте разделять — веб-сервер с пыхом в целом, и там генерация PHPSESSID и отдельно веб-приложения, в частности, с выводом mt_rand значений в HTTP ответ. Тогда с примерами покажите как это связать вместе.
Спасибо за хороший инструмент и статью! А можете собрать вариант для ATI карточек под OpenCL? Они быстрее и дешевле Nvidia.
Есть практические суровые НО, на которые стоит обратить внимание администраторам, прежде чем пытаться решить проблему на стороне каких-то Cisco.
Эта атака имеет существенное ограничение, про которое не стоит забывать — ей нельзя атаковать реальные веб-проекты. Дело в том, что заголок Date, который необходим в реальной жизни переписывает фронтэндом или балансером. Поэтому мешается. Keep-alive тоже в 50% случаях запрещен просто на балансирующей nginx и приехали. В этих условиях беда-беда, особенно если таймзона аппсервера и балансера разбежались. Это даже если открыт server-status, который в реальной жизни встречается в 5% случаев.
По статье, все очень грамотно изложено, но причем тут фраза «Принцип такой. Отправляем два запроса один за другим: первый на сброс пароля себе, второй — на сброс пароля админа. Разница в microseconds будет минимальна.» и как это связано с PHPSESSID хоть убейте — не понимаю!
Также просьба — пишите, пожалуйста, ссылки на исследования, которые легли в основу в тексте, в частности www.suspekt.org/2008/08/17/mt_srand-and-not-so-random-numbers/ забыли. Ссылки в комментах искать нереально, а разобраться почему работает тот же keep-alive, просто по атаке, очень трудно.
Еще раз спасибо за инструмент и статью, вы МОЛОДЦЫ!
Действительно, это так. Спасибо! При указании даже прямого домена, браузер все-равно проставяет на все поддомены. Новый RFC работает именно так. Надо думать…
Не знаю сколько систем вы атаковали, но могу сказать по своей статистике за 5 лет, что это очень хороший уровень защиты. Про его обходы написано в теле статьи.
Security through obscurity — это если бы атакующий не знал алгоритма хэширования.
Если соль не будет в базе, а будет одна на всех — то можно будет быстро найти все одинаковые пароли.
Дата регистрации — это соль фактически, пользовательская.
220M против 8,5k, то есть где-то на 4 порядка для GPU
напишите как схема работает, клиент передает hash(login.salt), где hash вычисляется на JavaScript?
Все проще!
У нас есть seed и rand и они зависимы между собой. Связь однозначная.
Если же значения ранда модулированные, то есть mt_rand(0,N), то надо больше rand, но поверьте — 624 — это ПРОСТО ДОФИГА :)
См. www.slideshare.net/d0znpp/dcg7812-cryptographyinwebapps-14052863 слайды с 18го
Вместе с этим инструментов и хотел бы использовать, но AMD все испортило :(((
Про Date — вы так атаковали хотя бы один сервер с балансером или фронотэдом? Как?
Про атаки на сами веб-приложения все-таки не совсем не понятно по статье. Давайте разделять — веб-сервер с пыхом в целом, и там генерация PHPSESSID и отдельно веб-приложения, в частности, с выводом mt_rand значений в HTTP ответ. Тогда с примерами покажите как это связать вместе.
Есть практические суровые НО, на которые стоит обратить внимание администраторам, прежде чем пытаться решить проблему на стороне каких-то Cisco.
Эта атака имеет существенное ограничение, про которое не стоит забывать — ей нельзя атаковать реальные веб-проекты. Дело в том, что заголок Date, который необходим в реальной жизни переписывает фронтэндом или балансером. Поэтому мешается. Keep-alive тоже в 50% случаях запрещен просто на балансирующей nginx и приехали. В этих условиях беда-беда, особенно если таймзона аппсервера и балансера разбежались. Это даже если открыт server-status, который в реальной жизни встречается в 5% случаев.
По статье, все очень грамотно изложено, но причем тут фраза «Принцип такой. Отправляем два запроса один за другим: первый на сброс пароля себе, второй — на сброс пароля админа. Разница в microseconds будет минимальна.» и как это связано с PHPSESSID хоть убейте — не понимаю!
Также просьба — пишите, пожалуйста, ссылки на исследования, которые легли в основу в тексте, в частности www.suspekt.org/2008/08/17/mt_srand-and-not-so-random-numbers/ забыли. Ссылки в комментах искать нереально, а разобраться почему работает тот же keep-alive, просто по атаке, очень трудно.
Еще раз спасибо за инструмент и статью, вы МОЛОДЦЫ!