Подтвердить что ты не робот

Возможно ли солить и/или хэш HOTP/TOTP на сервере?

Я создаю двухфакторную систему аутентификации на основе TOTP/HOTP. Чтобы проверить otp, сервер и устройство otp должны знать общий секрет.

Поскольку секрет HOTP очень похож на пароль пользователя, я предположил, что аналогичные рекомендации должны применяться. В частности, настоятельно рекомендуется никогда не хранить незашифрованные пароли, сохраняя только засоленный хэш пароля.

Ни в RFC, ни в реализациях Python HOTP/TOTP, похоже, не охватывают этот аспект.

Есть ли способ использовать одностороннее шифрование секретного ключа OTP, или это глупая идея?

Ответ 1

Есть ли способ использовать одностороннее шифрование общего секретного ключа OTP...?

Не совсем. Вы можете использовать обратимый механизм шифрования, но, вероятно, не так много.

Вы можете использовать только хеш HMAC на сервере, если клиент аутентифицирован, отправив полный unhashed ключ HMAC по сети, который обычно как работает аутентификация на основе пароля, но это будет уязвимо для повторных атак, что именно то, что рекомендуется для HOTP/TOTP.

почему мы применяем одностороннюю функцию к паролю перед его хранением (соль + хеш)...?

Это действительно хороший вопрос.

Я думаю, что это связано с тем, что ранние версии операционной системы Unix сохраняли всю свою информацию о пароле в "читаемом мире" файле /etc/passwd, поэтому они явно должны были быть запутаны каким-то образом, а salt + hash просто оказался методом, который они выбрали.

В настоящее время, как правило, не делается доступ к их файлу паролей, поэтому нет необходимости вообще их хешировать.

Однако есть еще одна причина для их обфускации, а именно, что пароли обычно выбираются людьми, поэтому для удобства они часто выбирают один и тот же пароль для нескольких систем. Я сомневаюсь, что это верно и для ключей HMAC, которые (надеюсь) выбраны с использованием криптографически более сильного механизма.

Итак, главная причина для хэширования пароля в настоящее время - это не столько повысить безопасность вашей системы, сколько снизить риск нарушения безопасности ваших пользователей в других системах, если ваш система была скомпрометирована.

Если злоумышленник может читать пароль незашифрованного текста из вашей системы, он, вероятно, не очень им подходит, потому что, возможно, они все равно могут читать все остальное в системе.

Но если один и тот же пароль использовался и в другой системе, то вы потенциально дали злоумышленнику средства для компрометации этой системы.

Если бы людям можно было доверять не использовать один и тот же пароль для нескольких систем, то, вероятно, им не понадобилось бы хэшировать их вообще, но я думаю, что несколько оптимистично предположить, что это когда-либо произойдет.: -)

Ответ 2

Определение: HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF - где K - секретный ключ, а C - счетчик. Он разработан так, что хакеры не могут получить K и C, если они имеют строку HOTP, поскольку HMAC является односторонним хэшем (не двунаправленным шифрованием).

K и C необходимо защитить, так как потеря, которая приведет к компрометации всей системы OTP. Сказав, что если K находится в словаре, и мы знаем C (например: текущее время), мы можем сгенерировать весь словарь HOTP/TOTP и выяснить K.

Применение одностороннего шифрования к HOTP/TOTP (то есть: двойное шифрование) математически затрудняет его декодирование, хотя оно не предотвращает другие формы атаки (например: ведение журнала нажатия клавиш) или применение одного и того же шифрования к списку словарей от HOTP/TOTP.

Это человеческая натура, чтобы повторно использовать один и тот же набор легко запоминаемых паролей для ВСЕГО и, следовательно, необходимость скрыть этот пароль на цифровых устройствах или при передаче через Интернет.

Реализация процедуры или протокола безопасности также имеет решающее значение, это похоже на выбор хорошего пароля K, но оставьте его лежащим вокруг стола для всех, или сервер, содержащий K (для HMAC), находится не в частной сети защищенный несколькими уровнями брандмауэра.