By: Justin Fimlaid
Authentication is a critical piece of any application. It’s also always the piece of security architecture that is commonly attacked, so it’s important to get it right. When we talk about authentication it’s the act of establishing that someone or some system is authentic and identity claims are correct. In the course of proving the authenticity of authentication, this needs to also include the resistance of impersonation and interception of passwords or other authentication mechanisms.
Authentication based on a username and password combination is the most common form of authentication. As the level of security increases within an application then simple usernames and passwords are no longer acceptable as passwords are often considered pre-breached.
When we start to breakdown authentication requirements, the list per OWASP Verification Standard 4.0, includes:
- Password Requirements
- General Authenticator Requirements
- Authenticator Lifecycle Requirements
- Credential Storage Requirements
- Credential Recovery Requirements
- Look-up Secret Verifiers
- Out of Band Verifiers
- Single or Multi-Factor One-Time Verifiers
- Cryptographic Software and Devices Verifiers
- Service Authentication
Passwords are considered “something you know” and are often considered single factor authenticators. Passwords in 2019 pose a significant challenge to authentication as billions of usernames and passwords have been disclosed and released on the Internet. Most passwords are easily crackable using common penetration testing techniques and with accessible compute horsepower accessible cracking hashes is made easier and the technique made available to more people with either positive or nefarious intent. Many techniques such as multi-factor authentication, re-use tokens such as FIDO, and links to Credential Service Providers (CSPs) providing federation are additional security controls that can be implemented to offset the risk or pre-compromised usernames and passwords. CSPs have an ability to validate a contextual identity not just a single authentication.
General Authenticator Requirements
Authenticator agility is essential to future-proof applications. Refactor application verifiers to allow additional authenticators as per user preferences, as well as allowing retiring deprecated or unsafe authenticators in an orderly fashion.
Authenticator Lifecycle Requirements
Authenticators are passwords, soft tokens, hardware tokens, and biometric devices. The lifecycle of authenticators is critical to the security of an application – if anyone can self-register an account with no evidence of identity, there can be little trust in the identity assertion. For social media sites like Reddit, that’s perfectly okay. For banking systems, a greater focus on the registration and issuance of credentials and devices is critical to the security of the application. Note: Passwords should not have a maximum lifetime or be subject to password rotation. Passwords should be regularly checked for their presence in publicly available breach data repositories. Those discovered, should immediately be replaced.
Credential Storage Requirements
Architects and developers should rigorously follow strong credential storage requirements when building or refactoring code. This section can only be fully verified through source code review or integration testing. NIST 800-63 section 220.127.116.11 contains a list of approved one-way key derivation functions.
Credential Recovery Requirements
This is an easy requirement but sometimes hard in technical execution. Anytime a user is being asked to establish an initial password, changing an existing password, or trying to recover a lost password the current password can’t be exposed. Additionally, any secret questions or hints are not exposed and multi-factor authentication resets must exercise the same rigor required during initial set up.
Look-up Secret Verifier Requirements
This is generally regarded as something you have. This requirement can come in the form of pre-generated secret codes, social media recovery codes, or a grid containing random values.
Out of Band Verifier Requirements
Secure out of band authenticators are physical devices that can communicate with the verifier over a secure secondary channel. Examples include push notifications to mobile devices. This type of authenticator is considered “something you have”. When a user wishes to authenticate, the verifying application sends a message to the out of band authenticator via a connection to the authenticator directly or indirectly through a third party service. The message contains an authentication code (typically a random number or a modal approval dialog). The verifying application waits to receive the authentication code through the primary channel and compares the hash of the received value to the hash of the original authentication code. If they match, the out of band verifier can assume that the user has authenticated.
Single or Multi-Factor One-Time Verifier Requirements
Single factor one time passwords (OTPs) are physical or soft tokens that display a continually changing pseudo-random one time challenge. These devices make phishing (impersonation) difficult, but not impossible. This type of authenticator is considered “something you have”. Multi-factor tokens are similar to single factor OTPs but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing or some additional value (such as transaction signing calculators) to be entered to create the final OTP.
Cryptographic Software and Devices Requirements
Cryptographic security keys are smart cards or FIDO keys, where the user has to plug in or pair the cryptographic device to the computer to complete authentication. Verifiers send a challenge nonce to the cryptographic devices or software, and the device or software calculates a response based upon a securely stored cryptographic key. The requirements for single factor cryptographic devices and software, and multi-factor cryptographic devices and software are the same, as verification of the cryptographic authenticator proves possession of the authentication factor.
Service Authentication Requirements
If your software uses service authenticators then these authenticators should not be stored in clear text. Any integration secrets should not use static API keys or shared privileged accounts. Passwords, integrations with databases, and third-party systems, seeds and internal secrets, and API keys should be managed securely and not included in source code or stored in repositories.