Можно ли посолить или хешировать секрет HOTP/TOTP на сервере?
Я строю двухфакторную систему аутентификации на основе TOTP/HOTP. Для проверки otp и сервер, и otp-устройство должны знать общий секрет.
Поскольку секрет HOTP очень похож на пароль пользователя, я предположил, что должны применяться аналогичные рекомендации. В частности, настоятельно рекомендуется никогда не хранить незашифрованные пароли, а только хранить соленый хеш пароля.
Кажется, что ни RFC, ни реализации python для HOTP/TOTP не охватывают этот аспект.
Есть ли способ использовать одностороннее шифрование общего секрета OTP, или это глупая идея?
2 ответа
Есть ли способ использовать одностороннее шифрование общего секретного пароля OTP...?
На самом деле, нет. Вы можете использовать механизм обратимого шифрования, но в этом нет особого смысла.
Вы могли бы хэшировать ключ HMAC на сервере только в том случае, если клиент прошел аутентификацию, отправив полный не хэшированный ключ HMAC по сети, что, как правило, работает на основе парольной аутентификации, но это было бы уязвимо для атак воспроизведения, что в точности и соответствует HOTP/. TOTP разработан, чтобы избежать.
почему мы применяем одностороннюю функцию к паролю перед его сохранением (соль + хеш)...?
Это на самом деле хороший вопрос.
Я думаю, что это связано с тем фактом, что ранние версии операционной системы Unix хранили всю информацию о паролях в "удобочитаемом мире". /etc/passwd файл, так что их явно нужно было каким-то образом запутать, и соль + хэш оказался именно тем методом, который они выбрали.
В настоящее время, как правило, никто не делает свой файл паролей таким свободно доступным, поэтому, возможно, нет нужды его хешировать вообще.
Однако есть еще одна причина, чтобы их запутать: пароли обычно выбираются людьми, поэтому для удобства они часто выбирают один и тот же пароль для нескольких систем. Я сомневаюсь, что то же самое относится и к ключам HMAC, которые (надеюсь) выбираются с использованием криптографически более надежного механизма.
Итак, основная причина хеширования пароля в настоящее время заключается не столько в повышении безопасности вашей системы, сколько в снижении риска нарушения безопасности ваших пользователей в других системах, если ваша система будет взломана.
Если злоумышленник может прочитать незашифрованный пароль из вашей системы, он, вероятно, будет бесполезен для них, поскольку в любом случае он может также прочитать все остальное в системе.
Но, если этот же пароль был использован и в другой системе, вы потенциально дали злоумышленнику возможность также скомпрометировать эту систему.
Если бы людям можно было доверять, чтобы они не использовали один и тот же пароль для нескольких систем, то, вероятно, их вообще не нужно было бы хэшировать, но я думаю, что несколько оптимистично предполагать, что это когда-либо случится.:-)
Определение: 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) не находится внутри частной сети, защищенной несколькими уровнями брандмауэра.