TOTP: изменение секрета при каждой сессии
У меня есть такое требование об изменении секрета пользователя для каждой сессии для генерации OTP. Мы решили использовать TOTP в качестве нашего алгоритма для этого. Мы отправляем OTP в SMS пользователю для проверки авторизации (не нужно генерировать OTP на стороне клиента).
TOTP = HOTP(WhereSessionCalculate(SecretKey), TC)
Итак, это хорошая практика, чтобы изменить секрет пользовательской сессии мудро. Если нет, то каковы последствия, которые могут возникнуть. Пожалуйста, объясните и дайте мне знать, если нужна дополнительная информация.
1 ответ
Основная предпосылка двухфакторной (или, точнее, многофакторной) аутентификации состоит в том, чтобы дополнить обычную комбинацию имени пользователя и пароля - это вещи, которые вы знаете, - одним или несколькими дополнительными факторами другого типа. Чаще всего используется то, что у вас есть (например, ваш мобильный телефон, приложение Google Authenticator или токен RSA, Gemalto и т. Д.) Или что-то о вас (биометрические данные, такие как радужная оболочка, отпечаток пальца и т. Д.)
Кто-то может выучить имя пользователя и пароль с помощью серфинга по плечу (легко, если пароль короткий), даже перехватить его по небезопасному сетевому соединению (надеюсь, вы используете SSL с AES256 или кто-то другой для шифрования сеансов в своем приложении!), Но добавление 2FA останавливает это.
Итак, позвольте мне вернуться к вашему вопросу о том, насколько ваш подход важен для аутентификации ваших пользователей. После того как ключ OTP пользователя установлен и сохранен в записи пользователя в базе данных, и этот ключ используется для заполнения генератора TOTP, чего достигнет повторное заполнение пользователем нового ключа? Да, генерация OTP-кода и отправка с помощью SMS-сообщения подтверждают, что входящий в систему человек имеет свой телефон в тот самый момент, но затем использует Google Authenticator; Более того, и я предаю свою предвзятость фанатов Apple здесь (!), входящие SMS-сообщения отображаются на экране блокировки моего iPhone, что также отображает ваш OTP, тогда как для доступа к приложению Google Authenticator мне нужно разблокировать мой телефон с помощью моего PIN-кода.
Также имейте в виду, что большинство систем подвергается риску на сетевом или системном уровне, и целые базы данных имен пользователей и паролей, украденных для взлома, - компрометация доступа одного пользователя, как правило, не стоит проблем, если у вас нет очень ценного актива, привлекающего внимание государственных деятелей!
Изучив здесь проблемы для моего собственного приложения, я выбрал имя пользователя и пароль для первоначального входа в систему (минимальная длина 20 символов для непонятных радужных таблиц, но без указания сложности или частых изменений), максимальное количество попыток перед блокировкой учетной записи для увеличение времени для неудачных входов в систему и вторичного входа в систему с использованием Google Authenticator (поскольку он бесплатный, работает на iOS, Android и BB10 и довольно прост в использовании). Чтобы улучшить это, я бы рассмотрел биометрические данные, но мое приложение является коммерческим, а не военным и т. Д., Так что того, что у меня есть, вполне достаточно для моей оценки риска.
Я надеюсь, что это поможет вам выработать наилучший подход для вашего приложения.