Multi-factor authentication (MFA/2FA) methods
We have encountered apps and websites that use Two/Multi-Factor Authentication or 2FA/MFA for additional security. They often use email, text messages, or push notifications to send you a code you must enter and provide your username or password. Sometimes, they require you to obtain a code from a mobile app. Most organizations must have MFA on their apps and online services; furthermore, organizations mandate their employees to enable MFA on all their accounts.
In this blog post, we will explain what MFA is, what there is, and whether it would be more cost-effective to build your own or use a 3rd party service.
Using more than one multi-factor auth method to authenticate users
A user has to log in to an online service for the system to recognize that user; we call it user authentication. We can authenticate a user based on three attributes:
- What they know (i.e. their password)
- What they have (i.e. their phone or mobile device)
- What they are (i.e. their biometric attributes such as fingerprints or facial recognition)
The most common method of authenticating users is asking for their credentials, such as username/email and password. That’s what we call the first factor. A one-factor authentication is an okay security, but nowadays, we need to do more because a persistent enough form of cyber attack can eventually find a user’s credentials and break into their accounts. To make systems more secure, we must add additional challenges to the authentication workflow, and that’s where the term Multi-factor Authentication or MFA comes from.
More recent smartphones and laptop computers come with built-in biometric readers, but they don’t add additional challenges to the authentication workflow, yet they often help reduce friction. For example, after authenticating a user’s fingerprint, the device fetches user credentials from the device’s keychain and populates the username and password fields on an app.
We can use a device that a user has to add additional authentication challenges after checking their username and password credentials. That is how most Two Factor Authentication or TFA mechanisms work.
The 2FA/MFA Terminology
When an app provides a challenge to users in addition to asking for their credentials, that’s a Two-factor authentication (2FA). If there are more than two challenges in the authentication workflow, it is a Multi-factor Authentication (MFA). This blog post will use the term 2FA simplicity.
Email 2FA
In this method, we can email a numerical code to the user, and they have to open their mailbox, obtain the code, and use it during their login process.
Pros: it’s simple to implement, and all users have an email address; mainly, if the user doesn’t own a smartphone, an email 2FA can provide some additional security. In some facilities, using any mobile device is forbidden, but users have Internet access and access to their email on their laptops.
Cons: if an adversary has already compromised a user’s email account, they can initiate a password reset to create a new password and receive the email 2FA token to log in to the user’s account successfully.
Our Recommendation: email 2FA is more secure than not having any 2FA at all. If you are confident that the user’s email accounts are on a secure infrastructure, email 2FA could be a good option. Please ensure that the code you email has a short expiry time, for example, 15 minutes or less. If you are a bank, NGO, or government organization and your services should be accessible to disadvantaged users who may not have mobile devices, please provide Email 2FA to secure their accounts because accessibility is essential.
Short Message Service (SMS) 2FA
We can send the 2FA code using SMS text messaging services to the user’s mobile phone, and then they’ll use it in their authentication workflow to log in to the service they’re trying to access.
Pros: it is more secure than email 2FA even if an adversary has compromised the user’s email account but doesn’t have access to the user’s mobile phone. Implementing SMS 2FA is simple; nearly all cell phone providers offer SMS in their basic packages.
Cons: SMS is less secure than other MFA methods to deliver a token to the user because adversaries can intercept SMS messages if they try.
Our Recommendation: if your users don’t have access to smartphones and you want to offer a 2FA option that is more secure than email, SMS is the next best option. If you are a bank, NGO, or government organization that delivers services, you must assume that many users may not own smartphones, but it is safe to take that they can receive SMS messages. You can use a 3rd party subscription service that allows you to send out SMS messages or build your own using tools that cloud service providers operate, such as Amazon Simple Notification Service (SNS).
Push Notification 2FA
We can use smartphone push notifications to deliver a 2FA code to the end user. Push notifications are inherently more secure than SMS because they go through the internet, and the service uses encryption at rest and in transit. You need a mobile app published by your organization or 3rd party service provider to receive your push notifications.
Pros: push notification 2FA is more secure than SMS and delivers the best user experience UX amongst all MFA options. Users don’t even need to have a phone plan because PNs use the existing Internet access. It is relatively simple to implement using many existing 3rd party platforms.
Cons: Users should have a smartphone or tablet to receive push notifications, and if your users, for any reason, cannot own such a device and install the app that gets the PN, then your service will not be accessible to them.
Our Recommendation: if you are a bank, NGO, or government organization, PLEASE offer SMS and Email 2FA options besides the push notification 2FA. Many 3rd party service providers provide web APIs and mobile development SDKs so you can deliver push notifications in a mobile app to your users. Suppose you wish to keep information private from these 3rd party services. In that case, you can build your push notification infrastructure using cloud services such as Amazon SNS or Azure Notification Hubs.
TOTP 2FA
Time-based One-Time Password or TOTP is the most secure and preferred method of 2FA for high-stakes professional applications, and it is what IT and cyber security experts recommend.
TOTP is a computer algorithm that uses an encryption key and the current time to create a One-Time Password. Now, since the clock time in all the online computing devices such as desktops, laptops, mobile phones, and servers are all in sync, we can use a one-time password as a 2FA code that the user’s mobile phone generates, which means we don’t even have to send them a code using email, SMS, or Push Notifications. All we need to do is pair the user’s device with their account on your service, and from that point, you can verify their OTPs with the algorithm on the server side.
Users can use existing Authentication apps published by companies such as Google, Microsoft, or your branded mobile app to pair their devices with their account on your service and generate OTP codes.
If that sounds too complicated, that’s because it is a more sophisticated method of 2FA, yet the most secure. There is a caveat, however: it is less user-friendly than the other 2FA methods, which is by design. Introducing a cryptographic challenge that requires users to open a mobile app, read the OTP and enter it in a desktop or browser app is a process that is very difficult for hackers to intercept and is more secure.
Pros: it is the most secure option because the user’s mobile phone generates OTPs that are valid usually between 1 to 10 minutes only. Build your own TOTP in your private cloud infrastructure; you don’t have to share user data with 3rd party services. Therefore, TOTP is ideal for high-security services such as healthcare, science, and enterprise systems.
Cons: implementing TOTP back-end and UI/UX workflows is usually more complex than other 2FA methods, but it is something that a skilled development team can accomplish. TOTP is less user-friendly than push notifications, so consumer app service providers often refrain from offering TOTP as an option. Meanwhile, TOTP’s reduced usability enhances its security and makes it an ideal choice for professional apps and services.
Our Recommendation: when high security is a requirement, and you aren’t offering any other options such as Email, SMS, and Push Notifications, please go straight to implementing TOTP for your services. Professional and expert users appreciate TOTP’s security. They are okay with the additional steps of using an Authentication app to pair their accounts and use the generated codes when logging in. If user privacy is a high priority on your list, consider implementing your own TOTP using the existing open-source libraries rather than integrating with 3rd party services that require storing some of your user metadata on their servers to function.
Cost of building your vs. using a 3rd party service
Warning: getting technical!
To build a TOTP 2FA, good open-source libraries are now available for creating encryption codes, QR codes for pairing mobile devices with a user’s account, and methods to compare OTP codes. To build SMS and Push notifications, you can use Amazon SNS and Azure Notification Hubs to deliver 2FA codes to your users.
On the other hand, Platform-as-a-service (PaaS) authentication service providers allow you to add all sorts of 2FA functionality to your existing applications, offering subscription and enterprise pricing models.
Either approach could be a better option for you, depending on your skills and resources in your development team and how much data you are willing to share with 3rd party service providers.
In our projects, we have consistently implemented our own 2FA projects because:
- If not less, it costs the same as integrating with a 3rd party.
- We wanted to keep our client’s user data private from the 3rd party authentication service providers.
- Updating and maintaining the code is more efficient than keeping up with API changes of a 3rd party service provider.
- Our authentication is more responsive and fast because we don’t have to send web requests back and forth with the 3rd party service provider.
- Our implementation is seamless and native while implementing with a 3rd party requires creating a patchwork of using their UI/UX components with ours, which increases code maintenance overhead and introduces more bugs.
If your IT team primarily specializes in maintaining technology infrastructure rather than developing and maintaining code repositories, then integrating with a 3rd party service may be a better option. Furthermore, third-party auth service providers often invest in building tools to integrate with legacy IT infrastructure in organizations.
Please contact us if you have further questions or want to share insights.
Photo by: Sarah Pflug