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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

Answer 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) не находится внутри частной сети, защищенной несколько слоев брандмауэра.