Are authenticator apps the best 2FA method for your users?

Passwords alone are weak. Experts have known this for a long time, and the rest of us are becoming aware, as more and more security leaks and cases of fraud hit the headlines. As a result, businesses that sign in users digitally are now recognising the need for a form of two-factor authentication (2FA) – explained below – to ensure users are who they say they are.  
‍

But with so many 2FA solutions now available, it can be daunting to work out the best way to authenticate real users. Authenticator apps offer a stronger alternative to vulnerable email and SMS authentication – but are they the right choice for your verification? 
‍

In this blog, we’ll explain the strengths and weaknesses of app-generated codes when it comes to security, accessibility, and risk of compromise, and compare them with passwordless login with SIM-based authentication. (You can also see a handy at-a-glance comparison here.) Let’s start with a look at why authenticators were developed in the first place.

‍

How does an app prove identity?

For robust security, it’s recommended by many authorities, such as UK Finance’s Strong Customer Authentication guidelines, to reinforce your initial identity method or credential with one of three factors for proving identity:
‍

• Knowledge (something you know, eg a password or a secret answer)
• Inherence (something you are, eg a fingerprint or a face scan)
• Possession (something you have, eg a code or a mobile phone.) 
  ‍

Passwords are a type of knowledge-based security, which is flawed because knowledge can be shared or stolen. And not all users are able (or willing) to share biometric inherence information such as their fingerprint – so for a second factor, most businesses turn to possession: usually a randomly-generated code known as an OTP (one-time password). 
‍

But when is a possession not a possession? The user is considered to possess the OTP, even though it’s digital, because it’s just been generated and sent ‘only’ to them. However, when these codes are sent by SMS or email, they can easily be stolen by a bad actor. Users can be tricked into sending the OTP to a criminal, as in phishing scams, or criminals can directly intercept the OTP with an MITM (man-in-the-middle) attack or by committing SIM swap fraud. 
‍

Authenticator apps were developed specifically to address these vulnerabilities by generating the OTP within the (supposedly) protected environment of the application, and imposing a time-based limitation. But there’s still a problem with this...

Is a past action the same as a present check? 

Authenticator apps typically work like this: 
‍

• The user creates an account for Service A with a username and password 
• They enable 2FA via App B 
• They open App B and connect to Service A, using that username and password to prove their identity initially
• App B is now able to generate a TOTP (time-based one-time password) which the user can use to authenticate themselves in future for Service A. 
  ‍

However, there’s a flaw here: App B is not actively connected with any form of identity. All it proves is that in the past, the user once authorised the app using the first set of credentials. 
‍

Authenticator apps aim to demonstrate that the user is in possession of a device they previously authorised. So what happens if their device is lost or stolen? Most mobile phone passcodes are easy to guess — meaning anyone with that device could quickly gain access to a TOTP, even if the user takes action to call their carrier and deactivate their SIM. 
‍

The lack of connection between the identity and the device also means the technology could be used against a victim: an attacker who learns a victim’s credentials could set up 2FA for that account on the attacker’s own phone, locking the user out remotely. 

‍

Is an external app the best user experience?

We all know that any friction in the user experience (UX) causes users to drop off, especially at onboarding. From a UX perspective, authenticator apps are a big ask: they require the user to have a smartphone with storage, and take the time to download an external app. 
‍

This excludes many users who are either unable to download an app, unwilling to take the time and effort, or don’t understand the process. Effectively, it puts up a barrier for users of a certain age or level of comfort with technology – the same users who are often the most vulnerable to malicious actors. 
‍

Even if the user makes the effort to download and sign up for external software, they’ll still have to switch to a different app to retrieve their code every time. In addition, because the codes are time-sensitive and the process requires back-and-forth between two services, users inevitably mistype codes. 
‍

All in all, it’s a lengthy and frustrating UX – so it’s unrealistic to expect high adoption of 2FA if you only support app-based authentication.

‍

The alternative: SIM-based authentication

‍
The good news is that there’s a new verification method which is mobile-native, universal, provides a better user experience, and designed to keep out malicious actors. We call it SIM-based authentication.
‍

How it works is simple: the user enters their mobile phone number into your app or website, which communicates instantly with the MNO (mobile network operator) to verify that this number is indeed the one linked to the SIM card on the mobile device. No user data is processed or stored. 
‍

Because there’s no password or code involved, it’s a powerful and present possession factor, which can’t be compromised by bad actors. tru.ID can also actively check for SIM swap activity to mitigate the risk of SIM swap fraud. 
‍

On the user end, they wait only a couple of seconds, their identity is verified, and they can continue – no context switching to a different app, no lengthy wait and code to memorise, no inconvenience. In stark contrast to apps, it assumes zero comfort with technology on the part of the user. The result is an invisible, effortless authentication experience, with stronger security that feels like magic. 

‍

How to get started

‍

tru.ID products easily integrate into any client-server application architecture using restful APIs and iOS, Android, React Native and Mobile Web SDKs. 
‍

Developers can find all they need to get started in our documentation, including integration guides for all our products. Simply sign up to start integration, and test for free, today – or contact Sales to find out how tru.ID can help your business.