Комментарии 37
Добро пожаловать на хабр. С почином, отличная статья. Завтра на свежую голову попробую по разбираться. Добавил в закладки.
ошибки исправьте, слово «спациальный» глаза режет
Инвините, я не понял: что мешает Мэлори сгенерировать верный пароль, назвавшись как Алиса?
пароль генерируется на основе секретного ключа, секретный ключ уникален для каждого пользователя, если перехватить секретный ключ то ничего не помешает :)
отсутствие секретного ключа
Не-не-не… Автор предлагает авторизацию на базе некой аутентификации.
С авторизацией всё понятно — индивидум N подтверждает свои права на некие права.
Не понятно с аутентификацией: кому позволять подтверждаться?
______________________________________________
Теперь дошло. Через вспомогательный механизм «Для этого на стороне сервера каждому пользователю генерируется уникальный секретный ключ, который должен быть передан на смартфон». То есть ранее интересующей нас сессии была произведена передача K, предположительно надёжным способом.
Тогда большой разницы нету передавать K или в качестве K передать мегабайт рандома для XOR.
Впрочем наверное там люди поумнее меня, коли «the algorithms was adopted by many companies worldwide (see below) and became the world's leading standard[citation needed]».
И более другие, которые добавили [citation needed].
С авторизацией всё понятно — индивидум N подтверждает свои права на некие права.
Не понятно с аутентификацией: кому позволять подтверждаться?
______________________________________________
Теперь дошло. Через вспомогательный механизм «Для этого на стороне сервера каждому пользователю генерируется уникальный секретный ключ, который должен быть передан на смартфон». То есть ранее интересующей нас сессии была произведена передача K, предположительно надёжным способом.
Тогда большой разницы нету передавать K или в качестве K передать мегабайт рандома для XOR.
Впрочем наверное там люди поумнее меня, коли «the algorithms was adopted by many companies worldwide (see below) and became the world's leading standard[citation needed]».
И более другие, которые добавили [citation needed].
Оказалось гораздо проще чем раньше думал… спасибо
К сведению автора, у secureid (ныне RSA) есть софтверный клиент.
Да и у прочих производителей токенов тоже.
Да и у прочих производителей токенов тоже.
> Время жизни одноразового пароля 300 секунд
Это значит, что для проверки пароля сервер должен сгенерировать на своей стороне 300 паролей, соответствующих всем допустимым значениям времени?
Это значит, что для проверки пароля сервер должен сгенерировать на своей стороне 300 паролей, соответствующих всем допустимым значениям времени?
как я понимаю, если на клиенте использовать время с точностью в 300 секунд (то есть округлять по 5 минут) — то на сервере надо будет всего лишь проверить два варианта — текущие 5 минут и предыдущие 5 минут (на случай границы).
если округлять время по 100 секунд — то на сервере надо будет проверить… 3-4 варианта.
всё дело в округлении времени.
это как я вижу.
если округлять время по 100 секунд — то на сервере надо будет проверить… 3-4 варианта.
всё дело в округлении времени.
это как я вижу.
А каков алгоритм действий в случае поломки (поломки, перепрошивки, hard-reset) смартфона?
На сервере все равно ключ сохраняется. Так что никто не запрещает залогиниться на свой аккаунт и еще раз посмотреть на картиночку с кодом.
насколько я в курсе, гугл предлагает возможность бекапа на сервер данных приложений со смартфона.
то есть можно просто бекапить на сервер свои ключи.
но тогда гугл-сервер должен стать самым охраняемым сервером в мире :)
то есть можно просто бекапить на сервер свои ключи.
но тогда гугл-сервер должен стать самым охраняемым сервером в мире :)
И почему вы реализовали HOTP как time-based OTP, тогда как в оригинале он event-based? Понятно, что криминала тут особого нет, но ведь сложность дополнительная — часы у клиента и сервера должны быть синхронизированы (до секунды, если я правильно прочитал код).
Меня вот тоже это смутило. Лишние проблемы. Вполне можно было бы просто генерировать на основании счетчика (и ключа разумеется). Сервер знает количество верных авторизаций, так что после очередной тоже у себя увеличиает счетчик. И в общем-то заранее знает, какой следующий должен быть пароль.
Если же клиента скомпрометируют и своруют ключ, то тут уже пофиг, по времени он делается или еще как.
Если же клиента скомпрометируют и своруют ключ, то тут уже пофиг, по времени он делается или еще как.
А как смартфонное приложение узнает количество верных авторизаций? Заставлять пользователя нажимать каждый раз специальную кнопку?
Да, нажимать на кнопку. Смартфон тоже будет считать количество генераций tokencode. В случае несовпадения счетчика на сервере и смартфоне — включать режим next-tokencode (просить пользователя ввести два подряд сгенерированных кода, пропускать только в том случае, если оба совпали).
Количество генераций tokencode != количество успешных авторизаций. Пользователь может сгенерить пароль и не ввести его (или упустить время). Выходит, нужно
1) нажать кнопку «сгенерировать одноразовый пароль»
2) ввести пароль
3) после авторизации нажать кнопку «все в порядке, пароль принят»
Вот этот-то третий шаг легко пропустить, что собьет синхронизацию.
1) нажать кнопку «сгенерировать одноразовый пароль»
2) ввести пароль
3) после авторизации нажать кнопку «все в порядке, пароль принят»
Вот этот-то третий шаг легко пропустить, что собьет синхронизацию.
Не нужна кнопка 3). Любой tokencode считается введенным. Единичные ошибки легко отсекаются небольшой модификацией алгоритма — принимать не только текущий код, но и плюс-минус N-ый (N-небольшое число, например 2). Если в эти границы tokencode не укладывается — считать попытку аутентификации неуспешной и после нескольких таких попыток включать режим next-tokencode.
Спасибо, разъяснили. А где можно почитать, как реализуется режим next-tokencode?
Мммм… даже и не знаю, что посоветовать. Термин этот я встретил впервые в документации на RSA SecurID, но она, по-моему, не доступна публично.
Если на пальцах, то работает это примерно так:
Дано:
а) У сервера есть константа N, задающая допустимые отклонения порядкового комера токенкода от текущего значения. Например, N=2. Если введенный пользователем токенкод попадает в +-N, то аутентификация считается успешной
б) У сервера есть константа L, на глубину которой он просчитывает токенкоды аккаунта. Если введенный пользователем токенкод не попадает в +-L, то аутентификация считается неуспешной. Например, L=20.
1) Количество неуспешних аутентификаций для аккаунта превысило допустимый предел. Cервер активирует для него флаг «режим next-tokencode», подозревая брутфорс или серьезную рассинхронизацию.
2) Сервер внезапно получает tokencode, попадающий в +-L и понимает — возможно, это наконец-то настоящий владелец аккаунта.
3) Чтобы убедиться наверняка, он подстраивает счетчик под найденное значение и просит пользователя сгенерировать и ввести следующий один код (next tokencode). Если и этот совпадает — ура, это хозяин!
Это, конечно, немного поверхностно и сумбурно, но, надеюсь, общая идея понятна.
Если на пальцах, то работает это примерно так:
Дано:
а) У сервера есть константа N, задающая допустимые отклонения порядкового комера токенкода от текущего значения. Например, N=2. Если введенный пользователем токенкод попадает в +-N, то аутентификация считается успешной
б) У сервера есть константа L, на глубину которой он просчитывает токенкоды аккаунта. Если введенный пользователем токенкод не попадает в +-L, то аутентификация считается неуспешной. Например, L=20.
1) Количество неуспешних аутентификаций для аккаунта превысило допустимый предел. Cервер активирует для него флаг «режим next-tokencode», подозревая брутфорс или серьезную рассинхронизацию.
2) Сервер внезапно получает tokencode, попадающий в +-L и понимает — возможно, это наконец-то настоящий владелец аккаунта.
3) Чтобы убедиться наверняка, он подстраивает счетчик под найденное значение и просит пользователя сгенерировать и ввести следующий один код (next tokencode). Если и этот совпадает — ура, это хозяин!
Это, конечно, немного поверхностно и сумбурно, но, надеюсь, общая идея понятна.
А чем, простите, сервис E-num не устраивает?
В данной реализации пароль не является одноразовым: если его перехватить, по нему можно авторизоваться повторно, пока не кончилось время жизни пароля, естественно.
Интересная статья, вот только непонятно зачем писать свой генератор, когда есть готовый, опенсоурсный, по известному протоколу, который к тому-же используется в гулвевской двухуровневой авторизации, и по этому у многих уже стоит:
Google Authenticator
Google Authenticator
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Генерация одноразовых паролей при помощи смартфона