> Время жизни одноразового пароля 300 секунд
Это значит, что для проверки пароля сервер должен сгенерировать на своей стороне 300 паролей, соответствующих всем допустимым значениям времени?
Для отдельно взятого пользователя алгоритм генерации его пароля — несомненно, секрет. Но если брать большую выборку, возникают разные общие закономерности. Какой именно сайт выбрал пользователь, мы конечно не знаем и знать не можем, можно лишь предположить, какой сайт это будет с большей вероятностью. Вообще атаки по подбору пароля приводят к успеху только с некоторой (не 100%) вероятностью. В интересах взломщика этот шанс повысить, а винтересах пользователя — понизить.
Мы тут рассматриваем несколько идеализированный случай:
1) Атакующему известен алгоритм генерации ключа. В криптоанализе принято считать, что ему известно все, кроме данных, составляющих секрет. Ну допустим, он знает что популярная программа «Password Generator 3000» использует (о, позор кодерам!) функцию от времени. Можно предположить, что кто-то из юзеров пользовался этой программой.
2) Также, предполагается, что у атакующего есть хеш пароля. Например, он взломал БД сайта. Если бы это было невозможно, то и пароли хешировать незачем, храни открытым текстом, все равно до них никто не доберется. Жизнь подтверждает, что это не так, базы пользователей часто уводят. Время регистрации обычно хранится в той же базе.
3) Телепатия не нужна, достаточно составить список новостных сайтов по популярности и перебрать хотя бы первую сотню (или тысячу). С поиском точной копии страницы за один из прошедших дней уже сложнее, но тоже нет ничего невозможного.
Довольно слабый метод. Если знать хотя бы приблизительно время создания пароля, его можно легко воспроизвести. Пусть вы берете время с дискретностью 1 секунда, а атакующему оно известно с точностью до суток. Как сказано в статье, достаточно перебрать 86400 вариантов (число секунд в сутках). Морда новостного сайта, фактически, тоже является функцией времени, ее можно найти в различных веб-архивах и кэшах поисковиков.
Да какой эффект не используй, получить больше энергии, чем пользователь затратил на нажимание кнопки, невозможно. Работа нажатия = сила * перемещение. По хорошему, конечно, интеграл брать надо, но для оценки можно считать силу постоянной.
Пусть усилие нажатия клавиши составляет 1Н (примерно 100 грамм, довольно туго), ход клавиши 5 мм (0,005 м), тогда за одно нажатие (при 100% КПД) пользователь вырабатывает 5мДж энергии. Даже если непрерывно стучать со скоростью 200 нажатий/минуту, получаем среднюю мощность 16мВт. Напомню, это при КПД 100%! Мне кажется, овчинка выделки не стоит.
Многие юзеры и про менеджеры паролей не знают, и про трукрипт, и про Хабр. А кто-то вообще доволен одним паролем «12345» на все. Но мы же с вами не о них речи ведем.
Это скорее вопрос психологии. Пользователь видит, что надежность генерируемых паролей в его руках (ага, в прямом смысле), думает «О, я сейчас такую кракозябру мышкой нарисую — никто никогда не подберет!» и доволен. А если что-то в фоновом режиме собирается, то у пользователя не пропадает паранойя «а так ли надежен там генератор, как заявляют?».
Рисунок еще раз переделывать уже не буду, т.к. это всего лишь иллюстрация принципа. А вообще вы правы, и дело тут даже не в понятности. В dataflow системах стремятся избегать узлов с некоммутативными входами, так как появляется задача научить систему отличать «левый» операнд от «правого»: добавляются лишние поля в контекст, усложняется устройство сопоставления… Зачем нам лишние проблемы, проще заменить вычитание умножением на (-1) и сложением.
интерактив с пользователем: заставлять нажимать десяток кнопок наверное бессмысленно
Активность пользователя как раз часто и используют для генерации сида для ГСЧ. Например, TrueCrypt просит случайным образом подвигать мышкой в специальном окне минуту-другую.
Думаю, далеко не каждый алгоритм обратим. Пример: на входе два простых числа, на выходе — их произведение. А обратно факторизовать результат уже гораздо сложнее.
Это значит, что для проверки пароля сервер должен сгенерировать на своей стороне 300 паролей, соответствующих всем допустимым значениям времени?
1) Атакующему известен алгоритм генерации ключа. В криптоанализе принято считать, что ему известно все, кроме данных, составляющих секрет. Ну допустим, он знает что популярная программа «Password Generator 3000» использует (о, позор кодерам!) функцию от времени. Можно предположить, что кто-то из юзеров пользовался этой программой.
2) Также, предполагается, что у атакующего есть хеш пароля. Например, он взломал БД сайта. Если бы это было невозможно, то и пароли хешировать незачем, храни открытым текстом, все равно до них никто не доберется. Жизнь подтверждает, что это не так, базы пользователей часто уводят. Время регистрации обычно хранится в той же базе.
3) Телепатия не нужна, достаточно составить список новостных сайтов по популярности и перебрать хотя бы первую сотню (или тысячу). С поиском точной копии страницы за один из прошедших дней уже сложнее, но тоже нет ничего невозможного.
Весь компьютер — нереально, а вот кулер, работающий от тепла процессора уже есть.
и про Хабр. А кто-то вообще доволен одним паролем «12345» на все. Но мы же с вами не о них речи ведем.Активность пользователя как раз часто и используют для генерации сида для ГСЧ. Например, TrueCrypt просит случайным образом подвигать мышкой в специальном окне минуту-другую.