Let’s say you’re tasked with selecting a strong authentication solution for your organization. Where do you begin? This blog functions as an introduction to this topic and provides additional resources for further learning.
Most people assume passwords must be supported as a baseline because we’re so accustomed to using them. Users are expected to somehow memorize or store the plethora of passwords that they’ve collected. The problem is that passwords are vulnerable to credential theft attacks either against the user (such as phishing, keylogging), or by brute force after obtaining bulk credentials from a server.
Multi-factor authentication (MFA) solutions are often considered to provide a higher level of protection against attacks. CIS has produced guidance on strong passwords and there are numerous solutions to choose from. MFA may be a one-time password designed for a proprietary product, biometrics, or hardware storing a private key. There are also solutions that strengthen security compared to passwords alone, but are not considered MFA, including risk-based and knowledge-based authentication. Risk-based authentication evaluates behaviours or the location of the user, while knowledge-based authentication asks questions of the user that include red herrings to aid in identity proofing. When selecting an MFA solution, you should evaluate whether credential theft is possible, and the risk reduction provided by a particular type of authentication or a specific solution.
Now let’s say you’re tasked with selecting the authentication mechanisms an application should support. Where do you begin? You might survey related applications to determine what is supported or survey your user base to determine if a particular MFA solution is predominant. There’s a wide range of possible underlying technologies that may be supported when you consider MFA.
Here’s a sample of authentication technologies and protocols you might consider when exploring MFA.
| Authentication Type | Description | Considerations | Example |
| Password | Password-based authentication, in which a user types a password that may be sent and stored using a hash and may be encrypted for transfer from the client to the server. User: Enters password that matches the password stored on the server. | Passwords are subject to credential theft attacks from both the client and server side through any number of methods, including phishing and brute force. If passwords are in use, ensure the stored passwords are hashed using a salt, and consider either migrating to a password authentication key exchange (PAKE) or a stronger form of authentication that does not involve a password. | HTTP Basic |
| Password Authenticated Key Exchange (PAKE) | A password is used to help two parties agree on a shared key using public key cryptography, in which the information on the wire (between client and server) is not subject to a replay attack and there’s no stored database or file of hashed passwords. User: Enters a password. | If your solution needs a password, this is a solid alternative that minimizes credential theft to keylogging attacks. | To select a PAKE scheme, see the Crypto Forum Research Group (CFRG) evaluation information to ensure the PAKE meets the use case requirements. |
| One-Time Passwords (OTP) and HMAC-based One Time Passwords (HOTP) | A one-time code is generated for every authentication. Algorithms behind the code generation are typically unique to a vendor and may be delivered to an application, a hard token/authenticator, or via an SMS message sent to a phone. User: Enters a password plus enters a challenge response (such as a PIN) that may be generated on an external device, within an app, or sent via a text message. | If SMS is used, OTP may be captured. It is possible to phish OTP codes from several available solutions, not just SMS. Solutions vary between implementations, vendors, or standards. Attacks have occurred against a few of these technologies, but no known attacks are still active today. | SecurID, Duo, Okta |
| Public Key Infrastructure (PKI) | Public/Private key cryptography can be used to verify the user and the server. The private key is used to sign (an encryption operation) some data. The user (or server) holds and protects their private key so when it is used, you have a high assurance on who signed the data and it’s verified using the complementary private key. The process is more complex than that for public key infrastructure, which relies on a certificate hierarchy model and in some cases federation across PKI instances. ‘Planning for PKI’, by Russ Housley and Tim Polk, has a solid explanation on pages 39-41. User: May use a password, biometric, or other type of authentication to gain access to a protected private key for use to generate the authentication interaction. The private key may be stored in a system-protected keystore or on an external device (such as a smart chip) typically connected via USB or a dedicated hardware interface. | Each user is issued one authentication key pair plus associated certificate that is provisioned for use with each application that accepts it as a credential. A revocation process must be in place to help support a ‘path validation process’ (such as RFC 5280) that ensures that a user, their certificate, and associated keys are all okay prior to verifying the cryptography works as expected to validate the user. Overhead can be cumbersome. Use of federation across domains may be complicated. It offers a high-level of security if implemented securely. | Department of Defense (DoD) Common Access Card (CAC) is a smart chip solution using a PKCS #11 (Public-Key Cryptography Standards) interface. PKI may involve keys stored locally or externally in a keystore (such as PKCS #11). It may also be used for server only authentication to provide Transport Layer Security (TLS) encryption in addition to the described ‘mutual authentication’ between end user and application. |
| W3C WebAuthn and Client to Authenticator Protocol (CTAP) | Uses a raw public/private key pair per user, per application. The user stores all their private keys on a hardware-based authenticator or in a system-based cryptographic keystore. User: Enters a password or authenticates to a hardware-based authenticator using another means such as a biometric to gain access to the individual private key needed. | Simplifies the application management for connecting user identity to credentials in that each application issues key pairs. WebAuthn has been integrated into web and mobile clients. Application integration may not yet be as strong. | WebAuthn and CTAP are standardized protocols. You might use any hardware-based authenticator that supports these protocols, such as Yubico and Feitian. For server or application integration, there are several libraries that support WebAuthn. |
| Risk-based Authentication | Risk-based authentication can include a wide range of information about a user or their system. This could include profiled behaviours of a user or their system, including access times and preferred application or browser used. User: Enters password or another authentication type that is coupled with a risk-based authentication solution. Password is the authentication mechanism and risk-based observations are intended to enhance security. | Risk-based authentication is not considered two-factor authentication even though it is stronger than a password used alone. | If a password is used, you may be subject to credential theft or replay attacks. The risk-based information may be attacked more easily than two-factor solutions mentioned (for example, PKI with a smart chip, WebAuthn with a Universal Two-Factor or U2F authenticator, or password with an OTP). |
Table 1 — MFA solutions breakdown.
Once you’ve selected which type of authentication to support, you may also need to pick a specific implementation if it is not a standard. This can potentially complicate the end user’s environment if it’s not a match for other applications in use. This National Security Agency (NSA) guide categorizes specific MFA solutions into the evaluation criteria from the National Institute of Standards and Technology’s (NIST) 800-63 authentication documents and is a very helpful resource for understanding the strength of each solution. If you are less familiar with identity management and all it encompasses, the NIST documentation is an excellent resource to learn more about this complex set of technologies.
Why are there so many options?
Authentication technology has evolved for several reasons, from improving security to meeting specific use cases. This flood of technologies is difficult for someone new to the area tasked with selecting one or more existing authentication protocols to support. On top of that, you may need to support one or more authorization protocols now that you have what’s needed to make an authentication assertion.
Authorization tokens, such as Kerberos, SAML, or OAuth tokens, are predominantly used once authentication has occurred. There are additional options but for simplicity, we’ll keep it to these very popular authorization protocols. We’ll explore single sign-on (SSO), federation, and authorization more deeply in future blog posts.
How to prevent credential theft attacks
If there’s an option to move away from authentication types that can be subject to credential theft and replay attacks, that would help reduce the possible impacts of phishing attacks. The MFA types included in the table (Public Key Infrastructure (PKI), WebAuthN, and One-time password (OTP)) meet that objective, and there are some differences to consider when selecting one or more for support in your organization or for your product. The public/private key pair models of PKI and WebAuthn prevent credential theft and are stronger when your keystore is external to your device.
OTP solutions are very popular, and integration from a user standpoint has been simplified with the use of password stores tied to a user’s OTP solution. OTP helps prevent the successful replay of passwords even when they are in use, since the OTP code is also required. As mentioned in Table 1, OTP codes may be phished. Even with this in mind, OTP offers a significant improvement to your level of protection from a password alone.
PKI and WebAuthN prevent credential theft as the user’s private key encrypts data, providing a signature that demonstrates the user in possession of that key is the only one who could have signed (encrypted) the data. The process is more complex, but this basic explanation helps to illustrate why public/private key pairs provide a good solution to prevent credential theft. The key is never exposed when used on a hardware-based authenticator. A challenge or data is ‘signed’ on the hardware-based authenticator and that signed data is unique for every authentication attempt. The user can be verified because the matching public key can be used to decrypt the data to verify the signature by comparing the challenge data and ensuring it matches the original (the challenge data is new for each authentication attempt). PKI can be difficult and cumbersome to deploy and requires significant management overhead if run at more than a basic assurance level. PKI is well integrated into web and other applications as the supporting encryption libraries have long contained support for this authentication type.
The need for new options that provide protection from credential theft was clear, as was easing management considerations with a public/private key solution. As such, a technology from W3C, called WebAuthN, evolved from a FIDO alliance standard and uses raw public/private key pairs for authentication. Another interesting aspect of WebAuthn is that individual key pairs are generated for every user and application. This reduces some of the infrastructure burden associated with PKI, while also preventing credential theft. Browser and mobile device support are strong for WebAuthN and server-side support is increasing, but could pose an integration challenge for some applications. This is an interesting option since the key pair is individual to each user and application. The user device to store key pairs may be independent of the application as a result and the device manages which key pairs should be used for each application authentication. The server or application also manages each user credential individually as a result. A change to one application may not impact the other applications.
Authentication and authorization series
Authentication and authorization are foundational to any security program. This blog post is the beginning of a multi-part series that will explore authentication and authorization technologies in the context of recent exploits as well as future direction. Authentication and authorization are complex technologies, which creates a hurdle for organizations looking to move to stronger authentication solutions. This series will attempt to break down the key questions and point to solid industry resources that ideally are vendor agnostic.
Authentication and authorization using SSO will be available on the APNIC Blog next week. In the meantime, read this interview with Justin Richer, a recognized OAuth, Identity, and Authorization expert, who shares his expertise on options for both now and the future. Justin is an author on NIST SP800-63.
Kathleen Moriarty is Chief Technology Officer at the Center for Internet Security and the former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy.
Adapted from this post on CIS Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.