Comments 4
У вас по ссылке на сайт путаница с RFC:
На самом деле номер RFC на TOTP — 6238.
Что касается идеи самостоятельной регистрации, то она не нова. Промышленные сервера аутентификации позволяют пользователям пройти первичную регистрацию. Например, указав доменный логин и пароль можно получить дальнейшие инструкции письмом на почту или СМСкой на телефон. Можно и проще, но всегда есть баланс удобство-безопасность.
В плане самообслуживания интереснее, как предлагаете обрабатывать события утраты генератора TOTP.
Нужно ли создавать пользователей заранее вручную или они создаются на лету?
Еще вопрос: делаете ли вы автоматическую подстройку времени на сервере для каждого пользователя при каждой аутентификации?
Ну и позанудствую: не люблю когда seed передается/отображается в открытом виде. Лучше бы проводить активацию через ссылку с одноразовым кодом активации. Eсли seed попал в этот момент к злоумышленнику, то он сможет без проблем генерировать TOTP в любом времени в будущем и все они будут валидными. Обычно я рекомендую использовать HOTP, вместо TOTP, чтобы одного знания seed было бы недостаточно для генерации одноразового пароля.
RFC-2865 algorithm (TOTP: Time-Based One-Time Password Algorithm)
На самом деле номер RFC на TOTP — 6238.
Что касается идеи самостоятельной регистрации, то она не нова. Промышленные сервера аутентификации позволяют пользователям пройти первичную регистрацию. Например, указав доменный логин и пароль можно получить дальнейшие инструкции письмом на почту или СМСкой на телефон. Можно и проще, но всегда есть баланс удобство-безопасность.
В плане самообслуживания интереснее, как предлагаете обрабатывать события утраты генератора TOTP.
Нужно ли создавать пользователей заранее вручную или они создаются на лету?
Еще вопрос: делаете ли вы автоматическую подстройку времени на сервере для каждого пользователя при каждой аутентификации?
Ну и позанудствую: не люблю когда seed передается/отображается в открытом виде. Лучше бы проводить активацию через ссылку с одноразовым кодом активации. Eсли seed попал в этот момент к злоумышленнику, то он сможет без проблем генерировать TOTP в любом времени в будущем и все они будут валидными. Обычно я рекомендую использовать HOTP, вместо TOTP, чтобы одного знания seed было бы недостаточно для генерации одноразового пароля.
Спасибо за отзыв, RFC сейчас поправим.
Полного самообслуживания нет. TOTPRadius позволяет временно блокировать пользователя, если имеется в виду защита от попадания генератора в руки злоумышленников. Если же надо просто перерегистрироваться можно обнулить счетчик и у пользователя будет возможность зайти один раз для осуществления перерегистрации.
На лету если с помощью REST API. А так можно и вручную, и импорт CSV.
Нет, подстройку пока не делаем, но идея хорошая и легко выполнимая — учтем в следующем релизе.
От TOTPRadius передается зашифрованным. Если имеется в виду фаза передачи ключа конечному пользователю, то и там риск не такой большой: например в том же StoreFront для отображения seed-a пользователь должен быть залогинен с AD credentials. На нашем облачном сервисе используется SMS активация, но TOTPRadius пока этого не предоставляет.
Эта статья о продукте заточенном именно под TOTP. И вы, наверное, согласитесь что TOTP гораздо проще внедрять.
В плане самообслуживания интереснее, как предлагаете обрабатывать события утраты генератора TOTP.
Полного самообслуживания нет. TOTPRadius позволяет временно блокировать пользователя, если имеется в виду защита от попадания генератора в руки злоумышленников. Если же надо просто перерегистрироваться можно обнулить счетчик и у пользователя будет возможность зайти один раз для осуществления перерегистрации.
Нужно ли создавать пользователей заранее вручную или они создаются на лету?
На лету если с помощью REST API. А так можно и вручную, и импорт CSV.
Еще вопрос: делаете ли вы автоматическую подстройку времени на сервере для каждого пользователя при каждой аутентификации?
Нет, подстройку пока не делаем, но идея хорошая и легко выполнимая — учтем в следующем релизе.
не люблю когда seed передается/отображается в открытом виде
От TOTPRadius передается зашифрованным. Если имеется в виду фаза передачи ключа конечному пользователю, то и там риск не такой большой: например в том же StoreFront для отображения seed-a пользователь должен быть залогинен с AD credentials. На нашем облачном сервисе используется SMS активация, но TOTPRadius пока этого не предоставляет.
рекомендую использовать HOTP, вместо TOTP
Эта статья о продукте заточенном именно под TOTP. И вы, наверное, согласитесь что TOTP гораздо проще внедрять.
Спасибо за подробный ответ.
Да, я про момент активации софт-токена. Когда seed передается в открытом виде, то может утечь по пути или, что более вероятно, снят с экрана (камера за спиной или троян, делающий снимки экрана).
Интересно было бы услышать аргументы против HOTP. Мне на ум приходят только вопросы пересинхронизации, но и тут есть свои плюсы и минусы.
Если имеется в виду фаза передачи ключа конечному пользователю, то и там риск не такой большой: например в том же StoreFront для отображения seed-a пользователь должен быть залогинен с AD credentials.
Да, я про момент активации софт-токена. Когда seed передается в открытом виде, то может утечь по пути или, что более вероятно, снят с экрана (камера за спиной или троян, делающий снимки экрана).
И вы, наверное, согласитесь что TOTP гораздо проще внедрять.
Интересно было бы услышать аргументы против HOTP. Мне на ум приходят только вопросы пересинхронизации, но и тут есть свои плюсы и минусы.
троян, делающий снимки экранаэто уже другой уровень, на самом деле от этого передача ключа на смартфон тоже не защищена — там ведь тоже может сидеть троян. в данном случае защитит только аппаратный токен.
аргументы против HOTPНе против HOTP как алгоритма (на самом деле TOTP это частный случай HOTP, где счетчиком служит текущее время), а больше против дополнительного неудобства для пользователя — для HOTP нужно выполнять на одно действие больше
Sign up to leave a comment.
Самостоятельная регистрация второго фактора для двухфакторной аутентификации, основанной на протоколе RADIUS