Pull to refresh
52
0
Ivan Novikov @d0znpp

User

Send message
Парольная политика — организационная мера. Очень важная и правильная. Также как и осведомленность сотрудников о том, что пароли не надо выкладывать на pastebin, ssh ключи пушить в github, и записывать секреты на бумажках рядом с мониторами. Но текст не об этом.
В тексте ссылки на тексты Solar Designer, какому еще эксперту в криптографии вы доверяете?
С точки зрения оптимизации — вы полностью правы. Но проблемы возникают на доказательстве реально величины энтропии этих случайностей.
Мы сводим к невозможной офлайн атаку через доступ только к одному хранилищу.

Не знаю сколько систем вы атаковали, но могу сказать по своей статистике за 5 лет, что это очень хороший уровень защиты. Про его обходы написано в теле статьи.
Зависит от, надо тестировать конкретную систему. Если у вас скорости менее 1000 хэшей в секунду — вы ничего не заметите. Иначе — давайте смотреть ТТХ.
Это вообще не security through obscurity, это называется разделяемый секрет.
Security through obscurity — это если бы атакующий не знал алгоритма хэширования.
Специально начал статью с определения условий применимости, чтобы избежать таких странных комментов — но всем пофигу :)
Эта соль будет в базе и захватив хранилище можно будет проводить атаку.
Если соль не будет в базе, а будет одна на всех — то можно будет быстро найти все одинаковые пароли.
Константа вне базы? Тогда это и есть локальный параметр.
Дата регистрации — это соль фактически, пользовательская.
я же большими буквами написал, что bcrypt
там же снизу цифры!
220M против 8,5k, то есть где-то на 4 порядка для GPU
«Ещё я интуитивно делаю хешеривание на стороне приложения, а не в БД — избегаю передачи пароля и глобальной соли лишний раз даже на локальной машине по файловым сокетам, не говоря о сети — мало ли кто как к каналу присосался. Или к логам БД.»

напишите как схема работает, клиент передает 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 работает именно так. Надо думать…
Все проверил — никто не ставит на поддомены. Вы на чем проверяли?

Information

Rating
Does not participate
Location
Россия
Registered
Activity