WifiOTP: Convenient Two-Factor Authentication Using Wi-Fi SSID



    Problem: Two-factor authentication is too complicated for most users


    Classical two-factor authentication involves a rather tedious procedure for users. We describe the sequence of steps required to enter the same Gmail on a personal computer using a mobile phone as a one-time password generator (OTP). After logging in using the first factor (password), you must:
    1) Find the phone
    2) Unlock it
    3) Find the OTP generator application (for example, Google Authenticator or Token2 Mobile OTP )
    4) Peek OTP and enter it from the keyboard

    It is approximately the same “difficult” with hardware keys of the TOTP / HOTP standard (with U2F keys a little easier). It is clear that everything has its own price, but for ordinary users, especially those who have not previously experienced account compromise, this measure seems superfluous. It is not surprising that in cases where two-factor authentication is optional, only a small percentage of users activate this option. According to researchers, in the case of Gmail, this is about 6% [1]. In general, to solve this problem, you only need to find an alternative channel between the main system (in our case, the browser on the computer) and the key (mobile application).

    Existing solutions


    Several two-factor authentication providers offer a simpler procedure for users. Let's consider some of them.

    DuoSecurity and Authy


    If you don’t go into details of the architecture, the principle of both systems is based on push notifications: when a second factor is requested, a request is sent to the device for permission to enter, and the user only needs to confirm it. This simplifies the end-user process to one action.

    The downside of push notifications is the need for Internet access on a mobile device. If there is no Internet, applications can be used in fallback mode, where OTP must be entered manually, that is, just like with Google Authenticator.

    Authy has another fallback mode available only for MacOS - it sends OTP code via the BLE protocol. Perhaps this is easier than entering codes from the keyboard, but to enter OTP using Authy BLE you need to: 1) select the item in the Authy Connector App (OTP will be copied to the clipboard) and 2) Paste OTP from the clipboard. Given that BLE support is not everywhere, I suspect that Authy BLE is not particularly popular.

    SlickLogin, SoundLogin, etc.


    Ultrasound is used as a channel for OTP transmission in SlickLogin and SoundLogin projects. The principle is simple - the computer’s microphone picks up the OTP that a device or mobile application generates through DTMF in ultrasound. The minus is obvious - the need to use sound subsystems (microphone) and the dependence on their characteristics (not everyone will be able to catch or generate ultrasound).
    There are several more initiatives trying to solve the problem, and each has its pros and cons. But there is one common minus: unlike WifiOTP, they are not able to replace the client part without changing the server part, that is, they are not the so-called “drop-in” replacement of the same Google Authenticator-a.

    WifiOTP: Our solution


    The idea is simple, use the SSID as the channel for OTP transmission.
    By the way, we are not the first to use the name WiFi networks for alternative purposes.

    The system consists of two components:
    - WifiOTP token: a Wi-Fi access point that changes the network name (SSID) every 30 seconds. An SSID format, for example, a network named WOTP_5533_OTP-Encrypted, where OTP-Encrypted is the current one-time password encrypted with a key that is known only to the client and token. OTP is generated based on the HMAC key, in accordance with RFC6238 , which is used only to generate OTP and is not transmitted to the client in any way.
    - WifiOTP client: an application running on a client computer. The client periodically scans the list of available networks, finds the desired network by prefix. Further, OTP is decrypted and available for use. In the Windows client example, the decrypted OTP can be entered into any current field by pressing Ctrl + Alt + X.

    The video shows the process of working WifiOTP client on Windows 8.



    As you can see in the video, for the demo we use the usual gmail account, that is, WifiOTP can replace the standard Google Authenticator (and any other TOTP token) without changing the server side.

    I’ll also clarify that the client can be connected to the network as desired, including via Wi-Fi; As such, there is no connection to the wireless network generated by the WifiOTP token - the WiFi adapter can scan broadcast networks without disconnecting from the current one.

    The project is by no means ready for commercial use, but PoC implementations for various platforms are already ready:
    - WifiOTP token for Windows
    WifiOTP token on OpenWRT
    I ordered such a device for 15USD, I hung it on a USB socket. I use to enter Gmail at home, just press Ctrl + Alt + X when it asks for OTP.

    - WifiOTP client for Windows
    - WifiOTP client for Android in a separate application format
    WifiOTP client for Android in custom keyboard format (current OTP can be entered by pressing a single button on the on-screen keyboard)


    WifiOTP will be presented at the ITU Kaleidoscope 2015 conference on December 9th . The full article is available in the archives of the University of Geneva.

    The source code for Windows is posted on 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

    Also popular now: