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 right answer to this question, but I believe one of the reasons (probably not the most important, though) is that many software engineers blindly 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 think about 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 see what the options are when you decide what precisely the third factor is suitable.
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 send 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 potentially 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 of sending 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 are in full control of all aspects of the OTP generation and transfer.
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 called Time-based One-time Password, or TOTP in 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 that is 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: RSA SecureID®, Yubikey from Yubico, Titan from Google, and many, many others.
Let’s describe how the device with 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 the device she/he owns. 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, 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 to the laptop while transporting, so the laptop 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 a SID for the code generation.
There are plenty of mobile applications that 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 of them 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 was recently brought about by the relatively new 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 have an opportunity to choose the best one for your use case.
