This guidance assists organizations in selecting a suitable method for authenticating their customers accessing online services. It is targeted at retailers, hospitality providers, and utility services, but is applicable to any organization that requires customer authentication when using online apps or websites. Integrating any of the methods detailed in this guidance (in addition to traditional password authentication) will significantly enhance the security of customer accounts.
Multiple authentication methods offer security that transcends passwords. This guide summarizes the advantages and limitations of each method, enabling you to select the one that best fits your organization and your customers. It also provides links to more extensive NCSC guidance on each authentication method.
Why Consider Alternatives to Passwords?
Nearly two decades ago, Bill Gates predicted the end of passwords. Many expected alternative methods to emerge, but passwords persist as the default authentication method for many services across both professional and personal domains. Password authentication is cost-effective, easy to implement, and familiar to users. The rise of online services and the widespread use of personal computers, smartphones, and tablets has only increased password usage.
The average user manages numerous online accounts, making it difficult to create and remember distinct passwords for each one. Users often resort to strategies for ‘password overload,’ including predictable patterns or reusing the same password across different platforms. Cybercriminals exploit these familiar tactics, leaving both customers and organizations vulnerable.
- Research by Google has revealed that 52% of passwords are reused across multiple accounts.
- FIDO data indicates that passwords account for over 80% of security breaches.
Introducing additional authentication methods also makes sound business sense. Estimates suggest that approximately 25% of online purchases are abandoned due to forgotten passwords, as the recovery process can deter many potential customers.
How Can Additional Authentication Help?
Criminals can steal passwords in various ways; the most frequent cause is when an organization that holds account credentials experiences a data breach. They often use stolen passwords to attempt access to various accounts, a technique known as credential stuffing, thriving because many individuals reuse their passwords across different platforms.
Additionally, criminals may utilize phishing tactics (through email, SMS, or direct messaging) to gain account access, or simply try basic passwords that millions still commonly use.
Without implementing additional authentication methods, criminals can exploit stolen credentials to gain unauthorized access to user accounts, potentially exposing sensitive personal data (including financial information like credit card details) or impersonating users to conduct malicious actions. By adding a second factor of authentication for customer accounts, you significantly reduce the likelihood of criminal harm.
Note:
When developing your organization’s password policy, please consult the NCSC’s guidance for system owners. This resource outlines how to implement technical measures that alleviate the burden on customers while supporting their natural working methods.
Select the Right Model for Your Needs
This guidance examines four authentication models:
For each authentication method, consider both the security and usability aspects, as well as the specific profile of your customer base. For example, some users may hesitate to purchase additional devices to shop on your online platform.
Despite their weaknesses (as discussed), passwords are a well-understood and widely accepted authentication method. Whatever additional authentication model you choose to implement, providing user support during account setup and beyond is essential. Ultimately:
- offering a variety of methods will help you reach a broader user base
- providing these options during account setup gives you a chance to clarify the benefits and functionality of extra authentication
Multi-factor Authentication (MFA)
The most prevalent authentication method that goes ‘beyond passwords’ is multi-factor authentication (MFA), also referred to as 2-step verification (2SV) or two-factor authentication (2FA). Accounts set up with MFA require users to provide a second factor, accessible only to them. The second factor may include:
Note:
The most appropriate second factor for MFA depends on your organization’s offered services and your customer demographics. For instance, using a PIN code sent via SMS is common and well-understood, but not the most secure option. Offering users a choice of second factors ensures you cater to the widest customer base. For further details on implementing MFA and selecting authentication factors, refer to the NCSC’s guidance on Multi-factor Authentication.
The second factor used in MFA should not be enforced every single time the service is accessed, as this could frustrate users. It should be required only when a high-impact activity is detected, such as:
- transferring significant amounts of money
- changing passwords
- updating account details (including credit card information)
A second factor should also be prompted when suspicious account activity is detected, such as a login from an unusual device or location.
Implementing MFA means providing user support during setup and in the long run (including guidance on what to do if users lose access to their second factor). The NCSC has created resources that can aid your users in understanding MFA. This guidance can be integrated into your support materials if necessary.
The following table summarizes situations where MFA may be appropriate.
| MFA is likely to be appropriate when: | MFA is less likely to be appropriate when: |
| Security is prioritized over user experience. | User experience is prioritized over security. |
| Your users are open to providing an additional contact method (phone or email). | Your users are averse to having additional contact information linked to your site. |
| Your users are comfortable using mobile devices and can recognize unexpected or false requests. | Your users struggle with mobile devices and may not understand authentication notifications. |
| You can offer various verification options to users. |
MFA: A Practical Scenario
Consider a large online marketplace where customers engage in buying and selling goods. Amidst the rise in password attacks (like credential stuffing), you aim to bolster customer security by implementing MFA on accounts. Offering a choice of authentication factors, customers might choose to receive a code via SMS or utilize an authenticator app. To avoid burdening users, prompt them for the second factor only when a new device or login location is detected.
For instance, Jean, who sells handmade items through your platform, is aware of phishing and credential theft incidents impacting other marketplaces. Concerned about being targeted in future attacks, she understands that this additional verification measure greatly reduces her account’s vulnerability.
OAuth 2.0
OAuth 2.0 enables customers to sign in to a new service using an existing account from another well-established provider (such as Apple, Facebook, or Google). This approach is commonly referred to as Single Sign-On (SSO), eliminating the need for users to create a new account on every new website.
Moreover, if OAuth providers have security measures in place (like MFA or token revocation options), your service can avoid the costs and risks of implementing these security measures in-house.
Conversely, if a criminal gains access to the OAuth provider’s account, they could potentially access any services using that account for authentication. Therefore, evaluating the security integrity of the OAuth provider is critical, and only those providers demonstrating adequate security practices should be selected. The NCSC offers Cloud Security guidelines that help determine whether a provider meets your security needs.
Additionally, consider the availability of OAuth providers; if there’s an outage with their authentication server, your service relying on it will also be inaccessible (as shown during the 2021 Facebook outage).
Even with a selection of OAuth providers, some users may prefer not to link an existing account with your new service, necessitating the offer of alternative authentication methods.
Implementing OAuth
The following links outline the implementation of OAuth 2.0 for various major providers:
- Google: Get verification codes with Google Authenticator
- Microsoft: Add sign-in with Microsoft
- Facebook: Facebook Login for the Web with the JavaScript SDK
- Twitter: Log in with Twitter
- Yahoo: Yahoo OAuth 2.0 Guide
- Apple: Sign in with Apple
The following table outlines situations when OAuth implementation may be suitable.
| OAuth is likely to be appropriate when: | OAuth is less likely to be appropriate when: |
| Ease of use is paramount. | Security is crucial, and relying on the OAuth provider’s security is not viable. |
| You have confidence in the OAuth provider’s security posture. | Your security and availability requirements exceed those of the OAuth providers. |
| Your users are indifferent to being tracked or profiled during service usage. | Your users prefer not to have their service usage monitored. |
| Expected downtime for the OAuth providers is acceptable. |
OAuth: A Practical Scenario
As a global hotel chain with numerous properties, many of your customers are booking for the first time and desire a quick login to secure a room without establishing a new account.
To facilitate this, you’ve included OAuth authentication in your booking process. Jack, a new customer without an existing account with you, is able to quickly log in using his Google account, streamlining his booking experience.
FIDO2
FIDO2 encompasses a set of standards that facilitate cryptographic authentication with public-key credentials and protocols, providing stronger alternatives to passwords for online service access. FIDO2 authenticators can range from personal devices like smartphones or laptops with a trusted platform module (TPM) to physical USB keys, usable for password-less logins or as a secondary factor.
The majority of FIDO2 tokens are USB-based (e.g., Yubikeys), available in various options to suit different needs and budgets. Most contemporary smartphone apps support FIDO2, as they incorporate biometrics for user authentication. FIDO2 relies on actions such as a button press, PIN input, or biometric recognition for granting authentication.
Generally, users bear responsibility for purchasing their tokens. If a token is lost, users could lose access to the service, emphasizing the importance of registering a backup token (which entails an additional purchase). Few services currently accept FIDO2, which may deter users from acquiring tokens due to the existence of typically less expensive authentication methods. Users must also revoke any lost tokens by logging into every service with the backup token.
As major hardware vendors introduce FIDO2 compatibility on their devices (allowing automatic token sharing across their platforms), several challenges remain, including usability and upfront costs.
Implementing FIDO2
The FIDO2 website offers resources for developers looking to implement this authentication method. Given that FIDO2 employs public-key cryptography, developers should possess relevant experience in cryptographic protocols, even if lacking direct experience with FIDO2 logins.
The following table outlines scenarios when FIDO2 implementation may be appropriate.
| FIDO2 is likely to be appropriate when: | FIDO2 is less likely to be appropriate when: |
| Security is more important than ease of use. | Security is not a significant concern, and user experience is on par with security. |
| Your user base is security-conscious and recognizes the importance of high security. | Your users do not prioritize account security and may be hesitant about additional factors. |
| You can supply users with an authenticator app or security token instead of relying on users to provide them. | Your users likely do not own smartphones or are unwilling to purchase their own tokens. |
| If a user loses their token, you can take the necessary time to recover their accounts. | If a user loses their token, immediate account recovery is essential. |
FIDO2: A Practical Scenario
As a leading video gaming company operating multiple online games, your customers’ accounts contain tangible value in digital assets (such as virtual goods, levels, and in-game currency). There have been instances where cybercriminals exploited leaked password databases to hijack individual accounts, stealing these digital assets from genuine users and damaging your company’s reputation.
One competitor enhances account security through FIDO2-based authentication. To remain competitive, you opt to incentivize customers logging in with a FIDO USB token or authenticator app through in-game rewards. However, adoption may be low due to the perceived modest value of these rewards. As a solution, you decide to produce branded FIDO2 USB tokens and distribute them free to customers reaching specific high levels within your games.
With these tokens becoming status symbols within your community (prompting your highest-value customers to strive for them), once acquired, they are motivated to use them to log into the site. Consequently, the accounts holding the most valuable digital assets are the least likely to be compromised by password-based attacks.
Magic Links and One-Time Passwords
Magic links facilitate password-less logins, allowing users to access their accounts by clicking a link sent to their email, rather than inputting a username and password. Once the link is clicked, users gain immediate access to the service.
One-time passwords (OTPs) function similarly, enabling users to log in with a temporarily provided password via SMS or email, or generated through an app. Offering users varied options is likely to boost adoption rates.
As seen with MFA, if a criminal obtains access to a user’s phone, they could potentially infiltrate accounts linked to that phone number. However, magic links and OTPs simplify the user experience and eliminate issues associated with forgotten passwords or breaches.
Implementing magic links:
The following table summarizes conditions under which utilizing magic links or OTPs may be appropriate.
| Magic links and OTPs are likely to be appropriate when: | Magic links and OTPs are less likely to be appropriate when: |
| Security is not a top priority, and user experience and throughput are equally crucial. | Security is of utmost importance, and the mobile network or email provider’s security is inadequate. |
| Your users are willing to share an additional contact method (like email or phone number). | Your users are hesitant to provide additional contact information. |
| Your users are generally confident with mobile devices and can recognize unexpected or fraudulent requests. | Your users are not confident with mobile devices and may find authentication messages confusing. |
Magic Links: A Practical Scenario
As the operator of a market comparison site, your customers visit your website a few times each year seeking the best deals on insurance, utilities, or broadband. Due to infrequent visits, you opt to implement magic links to facilitate quick login without the hassle of remembering passwords.
After forgetting her password and growing frustrated with the reset process on a competing comparison site, Meg returns to your platform. She simply needs to enter her email address, and moments later, an email appears in her inbox containing a link. After clicking the link, she is automatically logged into your site.
Based on an article from ncsc.gov.uk: https://www.ncsc.gov.uk/guidance/authentication-methods-choosing-the-right-type
