Applications of all sorts—whether you use them as part of your job or in other day-to-day activities—give users access to a service through authentication. Depending on the sensitivity of the information filtering through the app, different authentication methods are required, each corresponding to different risk levels.
In an era of ever-increasing data breaches, username and password credentials are no longer sufficient for authenticating access. Instead, organisations should stack multiple authentication factors together while understanding that each element has its unique strengths and weaknesses.
In this section, we'll talk about how you can prevent some of the vulnerabilities we've discussed from occurring in your authentication mechanisms.
Authentication is a complex topic, and, as we have demonstrated, it is unfortunately all too easy for weaknesses and flaws to creep in. Outlining every possible measure you can take to protect your websites is not possible. However, there are several general principles that you should always follow.
Types Of Authentication Factors
Each kind of authentication is called a factor. They’re used to verify a user’s identity and block access to anyone who isn’t who they claim they are. These factors are divided into three groups, ranging from those with the lowest to those with the most excellent assurance level.
- Knowledge factors: These are things the user knows, such as passwords or answers to security questions.
- Possession factors: These are things the user has in their possession or can act on. This includes SMS codes sent to mobile devices, one-time passwords (OTPs) sent via email, and push notifications.
- Biometric factors: These are things the user is. Biometrics include fingerprint scanning or facial authentication.
While these factors may feel like they’re secure enough on their own, there are security considerations that must be understood before deciding which to use to secure your organisation’s resources and data.
Secure Authentication Across Factors
When implementing a tool for verifying user identity, it’s essential to understand that some authentication factors are more potent than others—and the ones you think are the most secure may be easy to compromise. Security questions, for instance, are used in applications ranging from email to online government portals. A large study on account recovery at Google showed that answers to security questions are easy for attackers to guess and difficult for users to remember.
Sending an SMS code is another factor that isn’t as secure as it appears. The National Institution of Standards and Technology no longer endorses SMS codes as an authentication tool because attackers can quickly intercept a message meant for someone else’s phone. Physical USB keys or mobile devices with an authenticator app can be lost or stolen. Once an attacker has access to a possession factor, the resource’s identity verification is compromised.
Though they’re considered the strongest, even biometric factors like fingerprints and facial verification also have weaknesses. We’ve all seen the trick to lift fingerprints using a piece of tape, and other biometrics can also be replicated to trick applications to verify a user’s identity.
Adaptive Multi-factor Authentication (Mfa)
Part of deploying a secure authentication method means understanding the risks posed by each factor and combining them effectively to mitigate those risks. An adaptive approach that evaluates varying circumstances like network, geography, IP zone, and others can help align potential authentication factors to the risk level.
For instance, if your organisation’s internal database receives an authentication request from a user that is on your network and located within your organisation’s city and zip code, a password and medium-to-high assurance authentication factors like a physical key or biometric characteristic are probably all you need to verify that user’s identity. However, if the request comes from an unknown network or from a city that’s new for that user, you might consider adding a mobile push request to help prove their identity.
Even though they may sit at different points of the assurance scale, all authentication factors have weaknesses. Organisations looking to secure their data better—and that of their workforce and customers—need to implement an Adaptive MFA approach that assesses the risk of each unique login request and selects authentication factors accordingly.
The best thing you can say about using a password for authentication is better than nothing. High-profile breaches like Equifax, however, have exposed millions of passwords and user IDs, calling into question even that faint praise. If consumers don’t assume that some of their passwords have been compromised, they only create a dangerously false sense of security.
Companies that still rely on password authentication to access critical customer and corporate data are doing the same. Password-only protection is permanently broken, and any organisation relying on it is placing its business and reputation at risk. Even if they avoid a breach, awareness of the shortcomings of password protection is much higher now, thanks to Equifax. If that’s how you protect customers’ data, they will think twice about trusting you with it.
Take Care With User Credentials.
Even the most robust authentication mechanisms are ineffective if you unwittingly disclose a valid set of login credentials to an attacker. It should go without saying that you should never send any login data over unencrypted connections. Although you may have implemented HTTPS for your login requests, make sure that you enforce this by redirecting any attempted HTTP requests to HTTPS as well.
You should also audit your website to ensure that no username or email addresses are disclosed either through publicly accessible profiles or reflected in HTTP responses, for example.
Don't Count On Users For Security.
Strict authentication measures often require some additional effort from your users. Human nature makes it all but inevitable that some users will find ways to save themselves this effort. Therefore, you need to enforce specific behaviour wherever possible.
Prevent Username Enumeration
It is considerably easier for an attacker to break your authentication mechanisms if you reveal that a user exists on the system. There are even certain situations where, due to the nature of the website, the knowledge that a particular person has an account is sensitive information in itself.
Whether an attempted username is valid, it is essential to use identical, generic error messages and make sure they are similar. You should always return the same HTTP status code with each login request and, finally, make the response times in different scenarios as indistinguishable as possible.
Implement Robust Brute-force Protection
Given how simple constructing a brute-force attack can be, it is vital to ensure that you take steps to prevent, or at least disrupt, any attempts to brute-force logins.
One of the more effective methods is to implement strict, IP-based user rate limiting. This should involve measures to prevent attackers from manipulating their apparent IP address. Ideally, you should require the user to complete a CAPTCHA test with every login attempt after a specific limit is reached.
Keep in mind that this is not guaranteed to eliminate the threat of brute-forcing. However, making the process as tedious and manual as possible increases the likelihood that any would-be attacker gives up and goes in search of a softer target instead.
Triple-check Your Verification Logic
As demonstrated by our labs, it is easy for superficial logic flaws to creep into code which, in the case of authentication, have the potential to compromise your website and users ultimately. Auditing any verification or validation logic thoroughly to eliminate flaws is key to robust authentication. A check that can be bypassed is, finally, not much better than no check at all.
Don't Forget Additional Functionality.
Be sure not to focus on the main login pages and overlook additional functionality related to authentication. This is particularly important when the attacker is free to register their account and explore this functionality. Remember that a password reset or change is just as valid an attack surface as the primary login mechanism and, consequently, must be equally as robust.
Implement Proper Multi-factor Authentication
While multi-factor authentication may not be practical for every website, when done correctly, it is much more secure than password-based login alone. Remember that verifying multiple instances of the same factor is not accurate multi-factor authentication. Sending verification codes via email is essentially just a more wordy form of single-factor authentication.
SMS-based 2FA is technically verifying two factors (something you know and something you have). However, the potential for abuse through SIM swapping, for example, means that this system can be unreliable.
Ideally, 2FA should be implemented using a dedicated device or app that generates the verification code directly. As they are purpose-built to provide security, these are typically more secure.
Finally, just as with the main authentication logic, make sure that the reason in your 2FA checks is sound so that it cannot be easily bypassed.
Both Online And Offline Authentication Mechanisms Have A Standard Set Of Requirements
To protect the person asserting their identity and offer sufficient assurance to the identity consumer (a service, person, or relying party). In general, an authentication mechanism should:
- Respond only with a “yes” or “no” depending on the result of the authentication, rather than sharing and exposing PII, except for exceptional circumstances—such as complying with anti-money laundering (AML) regulations for customer due diligence (CDD)—subject to a person’s informed consent and comprehensive information security measures.
- Have known and easily accessible exception handling and grievance redress protocols if the authentication mechanism fails (e.g., a false negative biometric result). A person should never be denied a right, service, or entitlement (or their access made more complex) due to a fault of the ID system.
- Facilitate the auditability of transactions, including tamper-proof logs, certifying authentication devices, and identifying relying parties and potentially the individual operator within those organisations.
- Eliminate opportunities for the ID authority or other actors to use transaction metadata to track or profile the ID holder (e.g. through encryption, hashing, anonymisation of data, decentralisation of such data etc.).
- When identity data is shared by the ID system and stored by the relying party as part of the authentication mechanism, ensure that information is secured to prevent loss or compromise.
- Implement security controls to reduce threats such as guessing, eavesdropping, replay or manipulation of communication by an attacker that could subvert the authentication mechanism.
- Be mandated by relevant laws and regulations. The specific relationship between the ID system and the relying party can be governed by a legal agreement (e.g., a memorandum of understanding) setting out respective responsibilities.
This section describes some offline and online authentication mechanisms that are commonly used in foundational ID systems. The choice of which tools to adapt is closely tied to the types of credentials issued by the ID system and should be appropriate to the intended use cases for the system and country-specific constraints such as connectivity and digital literacy.
Offline authentication—used for in-person transactions when connectivity is unavailable or unnecessary—must provide a means of verifying that the person asserting their identity is who they claim to be without referring to other systems (e.g. remote identity databases, online services, etc.) and, if possible, that the credentials they present are genuine. In general, there are three primary options for offline authentication (summarised in Table 33):
- Manual (non-digital) comparison (i.e., taking an ID card at face value): Traditionally, authentication processes have involved the manual inspection of credentials (commonly ID cards) in determining that they are genuine (e.g., via embedded security features) and assess whether the person or their physical signature resembles the photo or signature included on the credential. While this method is intuitive and requires less infrastructure (beyond providing the credentials themselves), it provides a lower level of assurance and more opportunities for corruption than digital authentication due to the potential for human error and discretion in applying the procedure. At the same time, this may be appropriate for certain low-risk transactions and the only viable solution in areas with no connectivity or electricity. If security features are a possible method of improving the reliability of authentication, relying on parties need to be aware and appropriately equipped—e.g. In the case of level 2 (covert) security features, this might require a UV light.
- Digital authentication against data stored on a smartcard: Smartcards can authenticate a person offline with a higher level of assurance. In combination with a card reader (or receiver, in the case of a contactless card) equipped with text input and a biometric scanner (e.g., fingerprint or iris), a comparison can be made between the presented authenticators (e.g., a PIN or fingerprint) and the data stored in the chip of the card. Matching can be done by the card’s microprocessor itself or by the reader and associated software on the connected computer or device (e.g., a tablet or smartphone).
- Despite these benefits, however, smartcards can be expensive and also require purchasing, distributing, and training operators on the use of card readers (e.g., POS devices). Some smartcards are being developed with their embedded fingerprint scanner and power source, but these are very expensive. Smartcards used exclusively offline are also not necessarily much more secure than a non-smart card, as they could have been invalidated but continue functioning in isolation from the ID system.
Furthermore, the security and integrity of data on a smartcard cannot be guaranteed after being issued (e.g., in 2018, recall and reissue a significant proportion of smartcards in circulation because of a security flaw related to the private key stored on the chip). Indeed, many countries have issued smartcards without implementing this infrastructure, in which case they offer little benefit over “non-smart” cards.
- Digital authentication via a 2D barcode: Cards, certificates, or mobile apps with 2D barcodes (e.g., QR codes) also offer the possibility of digital, offline authentication when they are combined with readers and software that can match authenticators (e.g., PIN, fingerprint, photo) to those stored in the barcode itself or in a record in a local database that the QR code points to.
- In India, for example, the printed Aadhaar registration letters (“cards”) now include a secure barcode that contains biographic information and a low-resolution facial image of the order to facilitate a manual comparison. Although QR-code documents may be cheaper than smartcards, they are less secure. For example, a photo can be taken of a QR code, which would compromise it. Likewise, they cannot store as much data and are limited to how much physical space they are allotted on the card. The higher the density of the barcode, the more likely it is that scratches or other damage will affect the ability of the data to be read without errors.
- Storing a fingerprint template on a QR code, for example, is likely to result in a very dense QR code and exposes the template to being replicated (e.g., printed on other cards). Another significant challenge with barcodes for authentication factors in offline environments is the management of decryption keys. If a decryption key is widely available, an attacker can reverse engineer an applicable barcode to generate a fraudulent credential.
Where relying parties and users have access to the internet and mobile network connections, online authentication can be used for in-person and remote transactions.
The ability to refer to other systems—such as remote servers, data stored in the cloud, web- and mobile-based applications, etc.—increases the variety of potential online authentication mechanisms, as shown in Table 34, and the ability to check the validity of a credential.
Ultimately, online authentication provides a higher level of assurance because it offers more potential authentication factors and a “live” source. At the same time, it may also bring more excellent data protection and cybersecurity risks.
The authentication level of assurance provided by online mechanisms varies according to the credentials, authenticators, and protocols used. In addition to choosing authentication methods with levels of commitment appropriate to the transaction, practitioners must consider their accessibility and convenience, particularly for vulnerable persons (e.g., low literacy, the elderly, and people with disabilities) and those with unreliable internet or mobile connections.
For example, card-based authentication for remote transactions (e.g., e-services) would require the purchase and distribution of card and biometric readers to each person, which may be a barrier to adoption.