After another leak of susceptible personal data from one of the big company’s systems, we at Jappware have been asked a good question by one of our customers: why are even the biggest and most reach companies vulnerable to data thefts despite their investing an enormous amount of money and effort on their IT systems security? I doubt anyone has the correct answer to this question. Still, I believe one of the reasons (probably not the most important, though) is that many software engineers mindlessly follow some security recommendations without a clear understanding of the topic.
Let’s look at one of the standard authentication techniques — Multi-factor authentication, or MFA for short — and consider what approach to MFA is secure enough in your particular case.
What actually MFA is
Briefly, MFA is a way to grant (or deny) a user access to a system based on a combination of multiple factors, like his uniqueness, i.e., who the user is (determined by login or username or email, etc.), his secret knowledge (password), his unique possession (a hardware device, access to some third party system or information, biometric data, etc.), or even his location.
In most common software systems, the MFA is implemented as a combination of a user’s identity, password, and some third factor. Let’s review the options available when deciding precisely the suitable third factor.
Random one-time password (OTP)
When you first think of the OTP, you might imagine the random numeric or alphanumeric code generated upon login attempt and sent to a user via some communication channel, such as email, SMS, GSM voice call, or even via instant messengers like WhatsUp, Viber or Facebook Messenger.
Despite the seeming simplicity, you will have to solve a few problems:
- Make sure you use a secure random algorithm. Otherwise, an attacker could reconstruct the sequence and “guess” your OTP. Most pseudo-random algorithms use fairly simple math to produce statistically distributed “random” values, not the unpredictable random sequence.
- You have to keep track of which OTP belongs to whom and make sure it cannot be reused.
- To make it even stronger, you should make sure your OTP expires after a certain amount of time, even if it hasn’t been used.
- You must take care to send the OTP via the communication channel of your choice. This is essentially an integration problem, and integration problems have always been a source of headache, e.g., every integration point is a potential point of failure, such as network issues (so the OTP could not be delivered) or security issues (the channel might be insecure, like SMS, or compromised).
Pros: You fully control all OTP generation and transfer aspects.
Cons: you have to manage all aspects of the OTP lifecycle; there is a risk of the communication channel being broken, insecure, or compromised.
Hardware security tokens
Another approach to generating temporary codes is a Time-based One-time Password or TOTP short. The idea is that there are two physically independent places where the code is generated — the server/application the user tries to log in to and some other independent device — a security token.
The tokens come in different flavors, such as keyrings with a small display showing the TOTP code, a USB drive plugged directly into the user’s computer, and the fact it’s plugged in means the user is authenticated, NFC tags, etc. A few examples are RSA SecureID®, Yubikey from Yubico, Titan from Google, and many others.
Let’s describe how the device with a small display works. It generates a security code using an algorithm based on a unique SID and current time. The server/application is aware of the SID the specific device is using, so it can generate the code using the same source information, too. Upon login, the user is requested to enter the code from their own device. If the entered code matches the code generated by the application internally, the user is authenticated.
Pros: no need to transport OTP to the user; standardized TOTP algorithm so you can use an existing library to generate TOTP in your application.
Cons: hardware token may be lost or stolen; in practice, users often leave the USB token plugged into the laptop while transporting, so the computer may be lost together with the token; there is a need to store the device-associated identifier, such as device ID or serial number or the SID, which may be a security concern.
Software Tokens or Virtual Devices
The idea behind the software tokens is similar to their hardware counterparts, except that the code is generated by an application on another device (e.g., mobile app) or in another program (e.g., browser plugin).
To initialize the virtual token, the application generates a hash code (often provided to the mobile app in the form of a QR code), which is then used on both sides as an SID for the code generation.
Plenty of mobile applications can act as TOTP generators, e.g., Google Authenticator (despite the name, it’s an open-source application not related to any Google service and doesn’t require a Google account), Authy, Microsoft Authenticator, etc. Some also support alternative and more sophisticated MFA approaches involving third-party servers in the verification process (e.g., Okta or Authy).
Pros: no need to transport OTP to the user; standardized TOTP algorithm, you can use an existing library to generate TOTP in your application; no need to take care of additional security token device.
Cons: the physical device, such as a mobile phone with the Software Token application, may be damaged, lost, stolen, or compromised.
Push notifications
Significant improvement in user experience offers a push notification approach — instead of re-typing the verification code from a token to the login screen, the user has to press an “Accept” button in the mobile application. It may seem to be less secure, but actually, it’s more. The trick is that push authentication implements end-to-end encrypted communications between the application and a secured authentication service.
A good overview of the Push Notifications approach is given in the Push Authentication: Bringing the Most Secure Method of 2FA Mainstream article by Authy.
Pros: the safest solution from the cryptographic point of view; better user experience compared to other approaches.
Cons: you must use a third-party service unless you have your own mobile application.
Bottomline
There is a good list of MFA methods to choose from. As usual, neither is ideal, but you can select the best one for your use case.
