HOTP - счетчик значений безопасности - PullRequest
Новая
       87

HOTP - счетчик значений безопасности

0 голосов
/ 18 апреля 2020

У меня есть два вопроса о «(H) OTP алгоритме» относительно проблемы безопасности.

Мы все знаем, как работает «TOTP», мы сканируем код qr и каждые 30 секунд новые 6-8 Код цифры отображается, почти не волхвов c.

Теперь вернемся к «HOTP», в дополнение к полезной нагрузке от «TOTP» мы также получаем значение «counter».

Безопасно ли отображать значение счетчика на стороне клиента? Или это вызывает какие-либо проблемы с безопасностью?

И общий вопрос: всегда ли «секретное» значение 16 цифр? (Я спрашиваю, потому что я видел mfa-приложения, принимающие менее 16 цифр)

Спасибо!

1 Ответ

1 голос
/ 18 апреля 2020

Вопрос первый: Безопасно ли отображать значение счетчика на стороне клиента?

«Счетчик» не является секретом. Хотя «секретный ключ» остается секретным, знание текущего или недавнего значения «счетчика» бесполезно для противника. Если «секретный ключ» скомпрометирован, значит, у вас проблемы. RFC4226 много говорит о том, чтобы держать секретный ключ в секрете, и вообще ничего не говорит о секретности "счетчика". (И с TOTP, очевидно, это не так!)

Если злоумышленник узнает «секретный ключ» и «счетчик», он находится внутри. Если ему нужно угадать, и 8-байтовый » counter "засевается случайным образом, тогда это начинает выглядеть как атака грубой силы. Раздел 7.1 RF C содержит требования к протоколу аутентификации P, в том числе:

RP2 - P НЕ ДОЛЖЕН быть уязвимым для атак методом перебора. Это подразумевает, что схема регулирования / блокировки РЕКОМЕНДУЕТСЯ на стороне сервера проверки.

, поэтому существует некоторая дополнительная безопасность для безопасного хранения "счетчика", , но ни для клиента, ни сервер обязан сделать это. И даже если клиент делает, сервер не может. И это не часть формального анализа безопасности.

«E.4. Метод ресинхронизации на основе счетчиков» (из RF C) требует от клиента отправки своих « счетчик ", и мы имеем:

RP3 - P ДОЛЖЕН быть реализован по безопасному каналу, чтобы защитить конфиденциальность пользователей и избежать атак повторного воспроизведения.

... нет упоминания о безопасной отправке «счетчика», кроме как побочный эффект.

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

Вопрос второй: Всегда ли" секретное "значение составляет 16 цифр?

Я предполагаю, что это относится к "секретному ключу", также известному как "общий секрет" - поэтому под цифрами вы подразумеваете байтов ?

Раздел 4 RF C «Требования к алгоритму» включает в себя:

R6 - алгоритм ДОЛЖЕН использовать сильный общий секрет Длина общего секретного кода ДОЛЖНА быть не менее 128 бит. Этот документ РЕКОМЕНДУЕТ использовать общий секретный ключ длиной 160 битов.

Таким образом, "секретный ключ" размером менее 16 байтов не соответствует.

...