Pull to refresh

Comments 34

интерактив с пользователем: заставлять нажимать десяток кнопок наверное бессмысленно

Активность пользователя как раз часто и используют для генерации сида для ГСЧ. Например, TrueCrypt просит случайным образом подвигать мышкой в специальном окне минуту-другую.
упс, читал невнимательно, про мышку у вас как раз написано.
Прочитал и задумался.
Если по TrueCrypt понятно, как верно заметили выше, она заставляет двигать мышь, но возник интерес к другой используемой мною программе, в которой генерируются рандомные пароли, — KeePass. Полез на офф сайт проверять.
Random Number Generation

KeePass needs to generate several random bytes (for the IV, the master key salt, etc.). For this, several pseudo-random sources are used: current tick count, performance counter, system date/time, mouse cursor position, memory status (free virtual memory, etc.), active window, clipboard owner, various process and thread IDs, various window handles (active window, desktop, ...), window message stack, process heap status, process startup information and several system information structures. Additionally, KeePass uses random bytes provided by the system's default CSP RNG.

This pseudo-random data is collected in a random pool. To generate 16 random bytes, the pool is hashed (SHA-256) with a counter. The counter is increased after 16 generated bytes. This way, as many secure random bytes can be produced efficiently as needed.
Уф, невольный респект разработчикам, с «рандомностью» вроде всё в порядке у них.
да, все как следует сделали. единственное, что несколько лишних параметров есть (не лень им было?), по принципу больше — не меньше.
Имхо, это чистые понты.
Если уж они так озабочены получением случайного числа, то лучше было просто взять аппаратный генератор случайных чисел.
Оу, сорри проглядел что речь идёт о программе.
И организовать систему, когда пользователи будут удалённо к нему подключаться и запрашивать результаты его работы? Не слишком ли уязвимо получится? К тому же не везде есть доступ в интернет.
А с другой стороны, если у пользователя уже есть аппаратный генератор, было бы глупо со стороны программы его не использовать.
на мой взгляд достаточно просто траектории движения мышки по форме до кнопки Generate, с учетом временных задержек между изменением положения.
Мне, как пользователю, гораздо удобнее, когда программа «в фоне» реализует свою «рандомность», чем нежели каждый раз просит меня подёргать мышью.
Это скорее вопрос психологии. Пользователь видит, что надежность генерируемых паролей в его руках (ага, в прямом смысле), думает «О, я сейчас такую кракозябру мышкой нарисую — никто никогда не подберет!» и доволен. А если что-то в фоновом режиме собирается, то у пользователя не пропадает паранойя «а так ли надежен там генератор, как заявляют?».
Как-то надуманно звучит. Юзеры обычно предпочитают доверять разработчиком и не заморачиваются качеством псевдослучайных вычислений (они и слов то таких не знают).
Разве что фичу с мышкой можно сделать опциональной для любителей «брать ситуацию в свои руки».
Многие юзеры и про менеджеры паролей не знают, и про трукрипт, и про Хабр. А кто-то вообще доволен одним паролем «12345» на все. Но мы же с вами не о них речи ведем.
существования односторонних функций, которые в свою очередь существуют, если P != NP.


Это пока доказано только в обратную сторону. То есть если P!=NP, то не факт, что существуют односторонние функции. Однако, если существуют односторонние функции, то, очевидно, P!=NP.
То есть, существование односторонних функций доказать сложнее, чем P!=NP.
при наличии интернета — можно сделать ping или traceroute до какого-нибудь реально удаленного сервера.
Так и делают, собирают данные из TCP/IP соединений, это один из источников получения random seed в OpenBSD (в других *nix, скорее всего, тоже).
а есть какие-нибудь открытые библиотеки, которые предоставляют хороший ГСЧ?
Было бы интересно использовать G-sensor в мобильных устройствах — потряс телефон и готово)
Я прямо сейчас ломаю архив античта, в данный момент моим достижением является расшифровка 31% паролей за 16 секунд, на perl. В данный момент оптимизируется словарь и пишется c++ реализация финального подборщика. 77% не обещаю, но по времени ожидаются ошеломляющие результаты. У меня появились совсем иные соображения по части генерации паролей. Изложу в виде топика завтра.
При дальнейшем анализе понял что моя идея о генерации безопасного пароля не корректна. А идея была в том чтобы идти от обратного, выбрать наиболее непопулярные подстроки из паролей и из них уже собрать себе пароль, он бы получился в конце списка подобных переборщиков. Но понял что надо всё -таки генерить именно рандомный, дабы знание вашей тактики генерации не помогало злоумышленнику в атаке на вас конкретно.
Да мне тоже эта мысль давно в голову приходит. Но с точки зрения вероятности так даже хуже, ибо есть некоторая инфомрация о способе мышления пользователя при создании пароля.
UFO just landed and posted this here
UFO just landed and posted this here
Почему в процессоре не реализован аппаратно генератор случайных чисел или хотябы начальных значений…
UFO just landed and posted this here
А зачем вообще нужны пароли с сегодняшнего дня?? Они вроде как теперь запрещены:
habrahabr.ru/blogs/infosecurity/122703/
Если уж делать пароль, то простой и короткий. Чем меньше символов, тем лучше. Сравните: «Забытие пароля» и «Забытие пароля в особо крупном размере». )
Никакие замечательные магические последовательности вроде Xi+1 = (a*Xi + c) mod m не дадут никакой надежной (криптографической случайности).

Подождите, а как же Алгоритм Блюма — Блюма — Шуба. Скорость у него конечно не такая как у хеш-функций, но это уже другой вопрос.
я раньше делал себе пароли из хэша морды какого-нибудь новостного сайта, подсоленный временем.
Довольно слабый метод. Если знать хотя бы приблизительно время создания пароля, его можно легко воспроизвести. Пусть вы берете время с дискретностью 1 секунда, а атакующему оно известно с точностью до суток. Как сказано в статье, достаточно перебрать 86400 вариантов (число секунд в сутках). Морда новостного сайта, фактически, тоже является функцией времени, ее можно найти в различных веб-архивах и кэшах поисковиков.
«Таким образом, зная, что человек использовал определенный генератор, работающий на функции time достаточно просто узнать дату его регистрации на ресурсе»
OMG, автор, я вас прошу. Откуда кто-то узнает об этом самом «определённом генераторе», и какой генератор генерирует пароли, которые являются точной функцией от времени?

Что же касается:
«перебрать 86400 начальных значений (столько секунд в сутках), что делается за минуты»
Это если у вас есть хешкод пароля, который вы добыли… как?
Если у вас его нет, то никакой нормальный ресурс вам не позволит сделать 86400 попыток логина за минуты.

«Морда новостного сайта, фактически, тоже является функцией времени, ее можно найти в различных веб-архивах и кэшах поисковиков»
Остаётся только применить телепатию, чтоб узнать, «морда» _какого именно_ вебсайта была использована, и +150 везения, чтоб найти её точную копию в кешах.
Мы тут рассматриваем несколько идеализированный случай:

1) Атакующему известен алгоритм генерации ключа. В криптоанализе принято считать, что ему известно все, кроме данных, составляющих секрет. Ну допустим, он знает что популярная программа «Password Generator 3000» использует (о, позор кодерам!) функцию от времени. Можно предположить, что кто-то из юзеров пользовался этой программой.
2) Также, предполагается, что у атакующего есть хеш пароля. Например, он взломал БД сайта. Если бы это было невозможно, то и пароли хешировать незачем, храни открытым текстом, все равно до них никто не доберется. Жизнь подтверждает, что это не так, базы пользователей часто уводят. Время регистрации обычно хранится в той же базе.
3) Телепатия не нужна, достаточно составить список новостных сайтов по популярности и перебрать хотя бы первую сотню (или тысячу). С поиском точной копии страницы за один из прошедших дней уже сложнее, но тоже нет ничего невозможного.
«В криптоанализе принято считать, что ему известно все, кроме данных, составляющих секрет»
Понятно. Но в данном случае именно вопрос, стоит ли считать алгоритм генерации пароля секретом. В рассматриваемом случае пусть нет, но in real life наверное стоит.

Что же касается 3 — а кто сказал что все используют новостные сайты, а не форумы какие-нибудь или блоги вроде Хабрарахбра.
Для отдельно взятого пользователя алгоритм генерации его пароля — несомненно, секрет. Но если брать большую выборку, возникают разные общие закономерности. Какой именно сайт выбрал пользователь, мы конечно не знаем и знать не можем, можно лишь предположить, какой сайт это будет с большей вероятностью. Вообще атаки по подбору пароля приводят к успеху только с некоторой (не 100%) вероятностью. В интересах взломщика этот шанс повысить, а винтересах пользователя — понизить.
Sign up to leave a comment.

Articles