Проблема: двухфакторная аутентификация слишком сложна для большинства пользователей


Классическая двухфакторная аутентификация подразумевает достаточно утомительную для пользователей процедуру. Опишем последовательность действий, необходимых для входа в тот же Gmail на персональном компьютере с использованием мобильного телефона в качестве генератора одноразовых паролей (OTP). После входа с помощью первого фактора (пароля), надо:
1) Найти телефон
2) Разблокировать его
3) Найти приложение-OTP генератор (например, Google Authenticator или Token2 Mobile OTP)
4) Подсмотреть OTP и ввести его с клавиатуры

Примерно так же «сложно» с аппаратными ключами стандарта TOTP/HOTP (с U2F ключами чуть проще). Понятно, что у всего есть своя цена, но для обычных пользователей, особенно не сталкивавшихся прежде с компрометацией учетных записей, эта мера кажется лишней. Неудивительно, что в случаях, где двухфакторная аутентификация необязательна, только небольшой процент пользователей активирует эту опцию. По данным исследователей, в случае с Gmail, это около 6% [1]. В целом, для решения этой проблемы надо только найти альтернативный канал между основной системой (в нашем случае браузер на компьютере) и ключом (мобильным приложением).

Существующие решения


Несколько провайдеров двухфакторной аутентификации предлагают более простую для пользователей процедуру. Рассмотрим некоторые из них.

DuoSecurity и Authy


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

Минусом push notifications является необходимость интернет доступа на мобильном устройстве. Если интернета нет, приложения можно использовать в fallback режиме, где OTP надо вводить вручную, то есть, точно так же как с Google Authenticator.

У Authy есть еще один fallback-режим, доступный только для MacOS – это передача OTP кода через протокол BLE. Возможно, это и проще чем ввод кодов с клавиатуры, но для ввода OTP с помощью Authy BLE надо: 1) выбрать пункт в Authy Connector App (OTP будет скопирован в буфер обмена) и 2) Вставить OTP из буфера. Учитывая то что поддержка BLE есть не везде, подозреваю, что особой популярностью Authy BLE не пользуется.

SlickLogin, SoundLogin и др.


В качестве канала для передачи OTP в проектах SlickLogin и SoundLogin используется ультразвук. Принцип прост – микрофон компьютера улавливает OTP которые генерирует устройство или мобильное приложение через DTMF в ультразвуке. Минус очевиден- необходимость использования звуковых подсистем (микрофона) и зависимость от их характеристик (не все смогут уловить или сгенерировать ультразвук).
Есть еще несколько инициатив, пытающихся решить проблему, и у каждого есть свои плюсы и минусы. Но есть один общий минус: в отличие от WifiOTP, они не способны заменить клиентскую часть без изменения серверной части, то есть не являются так называемым “drop-in” заменой того же Google Authenticator-a.

WifiOTP: Наше решение


Идея проста, использовать SSID качестве канала для передачи OTP.
Кстати, мы не первые, кто использует название WiFi сетей в альтернативных целях.

Система состоит из двух компонентов:
— WifiOTP токен: точка доступа Wi-Fi которая меняет название сети (SSID) каждые 30 секунд. Формат SSID, например, сеть с именем WOTP_5533_OTP-Encrypted, где OTP-Encrypted это текущий одноразовый пароль, зашифрованный ключом, который известен только клиенту и токену. OTP генерируется на основе HMAC ключа, в соответствии с RFC6238, который используется только для генерации OTP и клиенту никак не передается.
— WifiOTP клиент: приложение, запущенное на клиентском компьютере. Клиент периодически сканирует список доступных сетей, находит нужную сеть по префиксу. Далее, OTP расшифровывается и доступен для использования. В примере Windows клиента, расшифрованный OTP можно ввести в любое текущее поле нажав Ctrl+Alt+X.

На видео показан процесс работы WifiOTP клиента на Windows 8.



Как видно на видео, для демо мы используем обычный gmail акаунт, то есть WifiOTP может заменить стандартный Google Authenticator (и любой другой TOTP token) без изменений серверной части.

Уточню еще то, что клиент может быть подключен к сети как угодно, в том числе и по Wi-Fi; как такового подключения к беспроводной сети, генерирующейся WifiOTP токеном, нет – WiFi адаптер может сканировать транслируемые сети, не отключаясь от текущей.

Проект пока никоим образом не готов для коммерческого использования, но уже готовы PoC реализации для различных платформ:
— WifiOTP токен для Windows
WifiOTP токен на OpenWRT
Заказал за 15USD вот такой девайс, повесил на USB розетку. Пользуюсь для входа в Gmail дома, просто нажимаю Ctrl+Alt+X когда просит OTP.

— WifiOTP клиент для Windows
— WifiOTP клиент для Android в формате отдельного приложения
WifiOTP клиент для Android в формате кастомной клавиатуры (текущий OTP может вводиться нажатием одной кнопки на экранной клавиатуре)


WifiOTP будет представлен на конференции ITU Kaleidoscope 2015 9 декабря. Полный текст статьи доступен в архиве Женевского университета.

Исходный код для Windows выложен на Github.

[1] Thanasis Petsas, Giorgos Tsirantonakis, Elias Athanasopoulos, and Sotiris Ioannidis. 2015. Two-factor authentication: is the world ready?: quantifying 2FA adoption. In Proceedings of the Eighth European Workshop on System Security (EuroSec '15). ACM, New York, NY, USA,, Article 4, 7 pages. DOI=http://dx.doi.org/10.1145/2751323.2751327

Комментарии (10)


  1. nmk2002
    27.11.2015 00:01

    Я правильно понимаю, что чтобы иметь доступ к «токену», нужно с собой носить точку доступа?


    1. Token2
      27.11.2015 00:15

      Если пользоваться только wifiotp, то да. Но одно другому не мешает, я например использую wifiotp дома, а «с собой» беру Google Authenticator с тем же ключом.
      Опять же, сейчас есть точки доступа размером с флешку


  1. SimWhite
    28.11.2015 13:06

    Как-то это сомнительно выглядит. Хоть оно и зашифровано, но доступно всем желающим в радиоканале, повышается вектор атаки IMHO.


    1. Token2
      28.11.2015 13:13

      Как посмотреть: то же можно сказать и о bluetooth и push notifications: в той или иной степени эти пакеты тоже можно перехватить хоть они и зашифрованы.
      В этом смысле надежнее всего аппаратные ключи… хотя нет, там циферки тоже можно подглядеть через плечо или шпионскими камерами :)


      1. ktrunin
        01.12.2015 12:02

        Здесь гораздо хуже. Не знаю деталей того как алгоритмически сделана генерация токенов, но наверняка можно пособирав подряд кучу токенов определить последовательность и начать генерить ее самому.

        И даже все еще проще — если вы постоянно вещаете свой второй ключ то украв у вас первый и находясь рядом с вами сразу же получаем второй.

        По сути вы второй ключ вешаете на крючок перед входом в квартиру.


        1. Token2
          01.12.2015 12:30

          Здесь гораздо хуже. Не знаю деталей того как алгоритмически сделана генерация токенов
          не понимаю что именно вы ставите под сомнение, по сути новизна в данном случае только в методе передачи токенов (не ручками/клавиатурой а через wifi) — как альтернатива тому же BLE & push notifications
          все остальное (алгоритм, и, соответственно, уровень безопасности) остается неизменным, даже чуточку получше: токены передаются зашифрованными (в текущей имплементации синхронным шифрованием, но можно легко заменить его и асинхронным) и, в отличие от того же Google Authenticator, не светятся нигде вообще
          можно пособирав подряд кучу токенов определить последовательность и начать генерить ее самому.

          А это уже вообще не к нам вопрос, а к стандарту TOTP, вы серьезно утверждаете что можете взломатъ HMAC-based One-time Password Algorithm?
          «пособирать подряд кучу токенов» тоже не так легко, они не транслируются открытым текстом


          1. ktrunin
            01.12.2015 12:40

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


            1. Token2
              01.12.2015 12:59

              наш PoC вообще ничего не меняет, я уже говорил об этом выше в комментах
              если взломщик так близко что может перехватить adhoc SSID, то он с тем же успехом может перехватитъ Bluetooth или даже подсмотреть токен на аппаратных ключах.

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

              научно доказано, восстановитъ хэш невозможно, даже с тысячей «утекших» токенов:
              RFC 4226: Appendix A — HOTP Algorithm Security: Detailed Analysis

              хотелось бы посмотреть на такого математика…


              1. ktrunin
                01.12.2015 13:20

                С вашим подходом перехватить токен можно просто находясь «за стенкой».
                А для того чтобы перехватить аппаратный токен нужно физически отобрать у пользователя аппаратный токен, либо отобрать телефон с софтварным токеном и выпытать у него пин код от телефона — согласитесь, это на порядки сложнее.

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


                1. Token2
                  01.12.2015 13:29
                  +1

                  вашим подходом перехватить токен можно просто находясь «за стенкой».
                  не сам токен, а зашифрованный токен (в теории, чем-то вроде aes-256)
                  либо отобрать телефон с софтварным токеном и выпытать у него пин код от телефона — согласитесь, это на порядки сложнее

                  людям пробовавшим расшифровать aes-256 может показаться что легче отобрать телефон :)
                  больше данных для взлома то вы взлом можете сделать быстрее
                  гляньте обсуждение здесь: > knowing many previous passwords should not give any additional advantage to the attacker.