Proper use of multi-factor authentication could stop most of the cyberattacks we see today, yet adoption remains low. Good security is usually at the expense of convenience, and multi-factor solutions that are easy to use are hard to implement. Fortunately, technology can be used to offset this security/convenience tradeoff. Let’s look at the pros and cons of different MFA solutions and how standard browser APIs can help.
The terminology “multi-factor authentication” (MFA) and “two-factor authentication” (2FA) comes from the notion that the user is authenticated using two or more methods. The first factor is usually your password ("something you know"), while secondary factors can be a hardware security key ("something you have") or a biometric identification such as a fingerprint ("something you are").
Why MFA matters
According to Microsoft, MFA could stop 99.9% of attacks, yet the adoption rate is only 22%. There are two main problems to overcome: applications need to implement MFA securely, and users need to enable and start using MFA. The latter requires the solution to be easy to use and understand, making the former even harder.
In 2021, the White House issued an Executive Order on Improving the Nation’s Cybersecurity, including a requirement for federal agencies to adopt multi-factor authentication.
Developers of business applications should take note – we should not be the weakest link. Now is the time to implement multi-factor authentication.
Types of MFA
Printed tables with one-time (OTP) codes are cumbersome and are quickly becoming a thing of the past. One remaining use for predefined one-time codes is for backup; the user is given a list of backup codes for account recovery. The problem is that the backup codes become the weakest link if not stored securely.
One-time code apps
One of the more common methods currently in use is time-based, one-time (TOTP) codes generated by an app on the user's phone. The user scans a QR code with a generic authenticator app, such as Google Authenticator, which generates a frequently changing code only known to the app and the server.
The drawback with this solution is that it is not very easy for users to understand and set up the first time.
There are also hardware solutions using a keyfob to display a changing code. Because this needs to be set up for each user and is not self-service, it becomes almost as cumbersome as the printed codes.
Also, one-time codes are not resistant to phishing and man-in-the-middle (MITM) attacks. A fake, look-alike site can trick the user into entering the TOTP code, allowing the attacker access to the actual application.
Custom authentication apps
Many companies have started to provide their own custom authentication app to mitigate some of the problems and improve usability. The same TOTP technology can be used behind the scenes, but the custom app hides some of the complexity. A notification can prompt the user to open the authenticator app and they only have to press a button in the app, instead of manually entering a code. The drawback is that the user has to install an additional app.
A common misconception is that this approach is phishing-resistant. A custom authenticator app is still vulnerable to phishing attacks using a fake site to drive the real site behind the scenes (MITM). One best practice can improve the situation: the authenticator app should always clearly indicate what operation is being confirmed. For instance, if the recipient is clearly shown in the authenticator app, the user might notice that an attacker is secretly trying to divert the payment to their own account.
Hardware, biometric
A solution that is both easy to use and phishing-resistant is to use the standardized Webauthn APIs built into modern browsers. This provides developers with a standard interface to hardware and biometric authentication devices.
From the usability standpoint, users are already quite used to this type of authentication through Touch ID, Face ID, and similar technologies used on mobile phones. No additional app needs to be installed.
Because these solutions are tied to a specific application via public-key cryptography and refuse to talk to a malicious site, they are phishing-proof. A man-in-the-middle cannot gain access to your private token or perform replay attacks, as the security device only talks directly to the correct server over a secure connection.
The White House highlights Webauthn as a good, phishing-resistant way to implement MFA.
"The World Wide Web Consortium (W3C)’s open ‘Web Authentication’ standard, another effective approach, is supported today by nearly every major consumer device and an increasing number of popular cloud services."
- White House Memorandum, January 26, 2022
Many laptops intended for business use come with built-in fingerprint readers compatible with Webauthn.
Another hardware-based option is to use a security key, such as Yubikey or Google Titan. These are small devices that look like a key and can be plugged into the USB port of a computer. Some keys provide a fingerprint reader as additional security.
A drawback is that the user has to keep track of an extra key. A benefit is that the security key is a portable authenticator that is not tied to a specific computer.
SMS and email are not recommended
A very common practice for MFA and account recovery is to send an SMS or an email with a one-time code or magic link.
We do not recommend this.
SMS is convenient, but SIM swapping continues to be a big problem. Also, many phones are still configured to show the notification with the code in plain text on the locked screen.
Email is a big unknown; it is not intended for this purpose, and we cannot know how secure the user's email is. MFA should provide additional security, but if password recovery and MFA are both handled via email, there is only one factor left. Further, email is often slow, and there is nothing more frustrating than repeatedly refreshing your inbox so you can get on with your workday.
Considerations and best practices
Whichever MFA approach you take, there are some common considerations.
- MFA is not only for login; the most effective approach may be to protect important actions with MFA. In some applications, it makes sense to only protect specific important actions with MFA. Using biometric authentication as the first factor (passwordless login) can also be considered.
- Always display all relevant details for the action that is being confirmed, so that the user might discover if some information was tampered with. Unfortunately, generic actions such as “login” cannot benefit from this.
- MFA setup is the hardest part and a weak link, as it is not protected by MFA. Take care to make it both easy and secure.
- Allow the user to add multiple authenticator devices.
- Account recovery is crucial. The device used for MFA might get lost or stolen, or malfunction. Careful: the recovery method can become the weakest link and make MFA ineffective. Enrolling an additional backup security key is most secure. Backup codes can be a good alternative, as long as the user understands the need to store them securely.
- Showing notifications or popping up the authenticator app might be a security risk in some cases, as the user might accidentally confirm an action they did not intend to. In other cases, it might alert the user of suspect activities. Consider what type of users your application has, and whether they might erroneously confirm a malicious action.
Demo
Vaadin Labs has made a technical showcase for the Webauthn API in action. After you log in for the first time (an account is automatically created), you are asked to add an authenticator device.
You can use a built-in fingerprint reader (or similar) or a hardware security key, such as Yubikey or Titan.
.png?width=1182&name=Screenshot%20on%202022-04-28%20at%2013-20-49%20(1).png)
As a novelty in this demo, you can also use an external phone as the authenticator. This means most users will have an existing authenticator device in their pocket already, and they do not need to install anything. The drawback is the same as with any external authenticator app: the authenticator cannot verify which site is displayed in the main browser, so this approach is not fully MITM-proof. Displaying full details for the action being confirmed mitigates this concern.
Once an authenticator has been added to your account, actions can only be confirmed using that authenticator. The user can also enable the option to require MFA at login.
Final thoughts
With the Webauthn standard, we no longer have a valid excuse – the security benefit is undeniable, and the user experience no longer has to suffer. We no longer have to make the tradeoff between security and usability. Using biometric/hardware solutions for authentication can be more efficient and more secure. It is time to implement multi-factor authentication!
Try out MFA with our demo app, or build your own custom app at start.vaadin.com.