WifiOTP: Convenient two-factor authentication using Wi-Fi SSID

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

Classical two-factor authentication implies a rather tedious procedure for users. We describe the sequence of actions required to log into 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 need:
1) Find a phone
2) Unlock it
3) Find an OTP application generator (for example, Google Authenticator or Token2 Mobile OTP )
4) Look for OTP and enter it from the keyboard

Approximately the same "difficult" with the hardware keys of the standard TOTP / HOTP (with U2F keys a little easier). It is clear that everything has its price, but for ordinary users, especially not previously faced with the compromise of accounts, this measure seems superfluous. Not surprisingly, 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, it is only necessary 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. Consider some of them.
')

DuoSecurity and Authy

Without going into details of the architecture, the principle of both systems is based on push notifications: when requesting the second factor, a request for permission to enter the device is sent to the device, and the user only needs to confirm it. This simplifies the process for the end user to one action.

The downside of push notifications is the need for internet access on a mobile device. If the Internet is not available, 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 - this is the transfer of OTP code via the BLE protocol. It may be easier than entering codes from the keyboard, but to enter OTP using Authy BLE you must: 1) select the item in the Authy Connector App (OTP will be copied to the clipboard) and 2) Paste OTP from the buffer. 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 transmitting OTP in SlickLogin and SoundLogin projects. The principle is simple - a computer microphone picks up the OTP that the device or mobile application generates via DTMF in ultrasound. A minus is obvious - the need to use sound subsystems (microphone) and dependence on their characteristics (not everyone will be able to catch or generate ultrasound).
There are a few more initiatives trying to solve the problem, and each has its own pros and cons. But there is one common disadvantage: 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.

WifiOTP: Our solution

The idea is simple, use the SSID as the channel to transmit the OTP.

The system consists of two components:
- WifiOTP token: a Wi-Fi access point that changes the network name (SSID) every 30 seconds. The SSID format, for example, the 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 the token. The OTP is generated based on the HMAC key, in accordance with RFC6238 , which is used only to generate the OTP and is not transmitted to the client.
- 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, decrypted OTP can be entered into any current field by pressing Ctrl + Alt + X.

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



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

I will also clarify that the client can be connected to the network as you wish, including via Wi-Fi; There is no connection to the wireless network generated by the WifiOTP token as such - the WiFi adapter can scan the 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 client for Windows
- WifiOTP client for Android in the format of a separate application


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 laid out on Github .

[1] Thanasis Petsas, Giorgos Tsirantonakis, Elias Athanasopoulos, and Sotiris Ioannidis. 2015. Two-factor authentication: is it world ready ?: quantifying 2FA adoption. In Proceedings of the 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