Рейтинг:3

Атака с выдачей себя за одноразовый пароль Лэмпорта

флаг in

Итак, вот я, гугля в своем мозгу о возможностях попыток подражания со стороны злоумышленника MITM на Схема одноразового пароля Лэмпорта.

Вот мой сценарий:

Скажем, у нас есть клиент и сервер. Учитывая одноразовый номер $n$, и хэш-функция $ч()$, клиент вычисляет хэш $n$ несколько раз (скажем $100$) и отправляет в первую очередь $Ч^{(100)}$ куда $ Н ^ {(100)} = ч ^ {(100)} (п) $. Во-первых, как сервер аутентифицирует личность клиента для первого значения, предоставленного клиентом, $Ч^{(100)}$? Цифровые подписи/сертификаты?

Для последующей аутентификации клиент отправляет $Ч^{(99)}$ и сервер вычисляет $ ч (Н ^ {(100)}) $ и если вычисление соответствует значению, хранящемуся на сервере (т. е. $Ч^{(100)}$), сервер аутентифицирует клиента.

Теперь, если предположить, что злоумышленник находится в середине связи, не может ли злоумышленник просто перехватить $Ч^{(99)}$ от клиента и отправить $Ч^{(99)}$ на сервер, таким образом выдавая себя за клиента только для этого конкретного сеанса, где $я$ является $99$. Это будет означать, что сервер аутентифицирует злоумышленника, а не клиента. Разве это подражание не возможно? И если да, то как OTP Лэмпорта защищает от этого.

Использование цифровых подписей или шифрования с открытым ключом для каждого сеанса аутентификации не похоже на идею Лэмпорта для использования его схемы OTP. Насколько я понимаю OTP Лампорта, он использует ТОЛЬКО хэш-функции.

kelalaka avatar
флаг in
[OTP](https://en.wikipedia.org/wiki/One-time_password) не является цифровой подписью. См. NIST [Рекомендации для Stateful Схемы подписи на основе хэша] (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf). Что, если клиент отправляет $(H^{(i)},i)$ и уменьшает $i$ для каждой сессии, конечно, сервер должен отслеживать $i$ как [упомянутая Wiki](https:/ /en.wikipedia.org/wiki/Одноразовый_пароль#Хэш_цепочки)?
Рейтинг:2
флаг in
  • На короткой стороне

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

Идея Лэмпорта основана на безопасности Hash-Chain следующим образом;

  • Инициализация системы

    1. Начальное семя $s$ выбран.
    2. Хэш $Ч$ применены $n$- раз в каскадной манере $$h_n = H^{(n)} = \underbrace{H(H(\cdots H(s) \cdots))}_{n-times}$$ к начальному семени $s$ куда $n$ может быть 1000,10000 или ..
    3. Изначально сервер хранит $h_n$ (и возможно $n$, тоже)
    4. Пользователь хранит $s$ и $n$
  • Механизм входа

    • Для первого входа

      1. Пользователь вычисляет $h_{n-1}$
      2. В процессе входа пользователь отправляет $h_{n-1}$ на сервер.
      3. Проверка сервера $H(h_{n-1}) = h_n$
      4. На успешном сервере входа
        1. увеличить счетчик $ вкл (с) $
        2. магазины $h_{n-1}$
      5. При успешном входе в систему набор пользователей $n = n-1$ (или, возможно, другая переменная)
    • Для $я$-й логин

      1. Пользователь вычисляет $h_{n-i}$
      2. В процессе входа пользователь отправляет $h_{n-i}$ на сервер.
      3. Проверка сервера $H(h_{n-i}) = h_{n-i+1}$
      4. На успешном сервере входа
        1. увеличить счетчик $ вкл (с) $
        2. магазины $h_{n-1}$
      5. При успешном входе в систему набор пользователей $n = n-1$ (или, возможно, другая переменная)

Это основы, и некоторые детали опущены для ясности; Например; по какой-то причине система может быть не синхронизирована, то есть счетчик пользователя может не синхронизироваться с сервером. Чтобы справиться с этим, сервер может сохранить параметр просмотра вперед $t$, так что на $я$-я попытка входа в систему, если нет равенства $H(h_{n-i}) \neq h_{n-i+1}$, сервер смотрит вперед, если есть совпадение с $h_{n-i+1}$ к $h_{n-i-t+1}$.

Что теперь если третье лицо увидит токен LOTP и попытается выдать себя за пользователя.

  1. Для нового входа они не могут использовать его, так как им нужно $H_{n-i-1}$. Для этого им нужно найти прообраз. Все криптографические хеш-функции сохранили свои прообразы безопасности, включая защиту от коллизий, нарушенную MD5 и SHA-1. Это не означает, что вы должны их использовать, предпочитайте современные, такие как SHA-256, SHA-512, SHA-3, BLAKE2 и т. д.

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

    Короче говоря, безопасность LTOP основана на безопасности предварительного образа $Ч$

  2. Может ли просмотр вперед вызвать проблему? Нет. Сервер обновляет сохраненные хеш-значения при каждом входе в систему. Если бы они хранили только начальный и хэши $я$-times для проверки OTP, затем просмотр вперед является точкой атаки. Это одна из причин сохранения последнего хэша, а вторая — производительность.

  3. Секрет $\mathbf{s}$ размер, с другой стороны, должен иметь по крайней мере однородные и случайно сгенерированные 128 бит, чтобы предотвратить грубую силу $s$.

Jake avatar
флаг in
Спасибо за подробное объяснение. Нравится идея упреждающего параметра. Одна вещь, однако, заключается в том, что моя точка зрения все еще не понята. Возьмем, к примеру, сеанс, в котором пользователь отправляет hп-1. Злоумышленник может перехватить hп-1 и отправить на сервер. В конце концов, сервер никогда не проверяет, где hп-1 происходит от. Все, что делает сервер, это проверяет, что hп-1 хэши в чн. Так что, если это произойдет, не будет ли это означать, что сервер аутентифицирует злоумышленника, а не пользователя? Или может быть что-то, что я упускаю.
Jake avatar
флаг in
Мне потребовалось время, чтобы придумать мой предыдущий комментарий, я только надеюсь, что вы поняли мою точку зрения. Кроме того, что если пользователь первоначально отправляет n-кратный хэш секрета s. Я имею в виду первый раз, когда пользователь отправляет свой n-кратный хэш, с которым начинает работать сервер. Как сервер обеспечивает идентификацию пользователя в первую очередь? Или мы можем предположить сценарий, в котором сервер фактически предоставляет секреты пользователю каким-то безопасным способом, заставляя пользователя вместо этого хешировать предоставленный сервером секрет. На мой взгляд, это может быть способом проверки личности пользователя сервером.
kelalaka avatar
флаг in
1) Как я уже сказал, ответ не включает все детали. Что, если сервер увеличит хеш, как только подтвердит пользователя, и забудет предыдущее значение? Такая же сессионная атака может произойти только по выбору разработчика. Если они хотят предотвратить это, то могут запросить новый токен.
kelalaka avatar
флаг in
2) Вы когда-нибудь слышали о процессе регистрации? Секрет должен быть сгенерирован пользователем или должен быть передан пользователю безопасным способом, как токены банков. Как только пользователь и сервер договорятся о регистрации, пользователь может дать свои $h_s$ в это время. проверка пользователя должна требовать как минимум двух факторов, таких как тот, который вы должны знать (пароль), тот, который вы должны иметь (телефон/токен) и т. д. LOTP — это один из факторов.
Jake avatar
флаг in
+1 за ваш отзыв, спасибо

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.