Authentication is a critical piece of any application. It’s also a commonly attacked piece of security architecture, so it’s important to get it right. When we talk about authentication, we’re referring to the act of establishing that someone or some system is authentic and identity claims are correct. Authentication also needs to include the resistance of impersonation and interception of passwords or other authentication mechanisms.
The most common form of authentication is based on a username and password combination. As the level of security increases within an application, simple usernames and passwords are no longer acceptable as passwords are often considered pre-breached.
Authentication requirements are important because they help to fulfill many compliance requirements, including PCI DSS 3.2, NIST 800-53, and NIST 800-63.
When we start to break down 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 Multifactor One-Time Verifiers
- Cryptographic Software and Devices Verifiers
- Service Authentication
Password Requirements
Passwords are considered “something you know” and are often single-factor authenticators. Today, passwords pose a significant challenge to authentication as billions of usernames and passwords have been disclosed and released on the internet. Most passwords can be easily cracked using common penetration testing techniques. With widely accessible compute horsepower, cracking hashes is made easier, and the technique made available to more people with either positive or nefarious intent. Additional security controls can be implemented to offset the risk of pre-compromised usernames and passwords, including techniques like multifactor authentication, reuse tokens (e.g., FIDO), and links to credential service providers (CSPs) providing federation. CSPs can validate a contextual identity, not just a single authentication.
General Authenticator Requirements
Authenticator agility is essential for future-proofing applications. Be sure to refactor application verifiers to allow additional authenticators as per user preferences, and the retiring of 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 5.1.1.2 contains a list of approved one-way key derivation functions.
Credential Recovery Requirements
This is an easy requirement, but sometimes difficult in technical execution. Any time a user is being asked to establish an initial password, change an existing password, or recover a lost password, the current password can’t be exposed. Additionally, any secret questions or hints are not exposed, and multifactor authentication resets must exercise the same rigor required during initial setup.
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 (e.g., 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 direct or indirect connection to the authenticator 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 Multifactor, One-Time Verifier Requirements
Single-factor one-time passwords (OTPs) are physical or soft tokens that display a continually changing pseudorandom one-time challenge. These devices make phishing (i.e., impersonation) difficult, but not impossible. This type of authenticator is considered “something you have.” Multifactor tokens are similar to single factor OTPs but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing, or some additional value (e.g., 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 in which the user must plug in or pair the cryptographic device to the computer to complete authentication. Verifiers send a challenge once 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 multifactor 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, they should not be stored in clear text. Any integration secrets should not use static API keys or shared privileged accounts. Passwords, database integrations, third-party systems, seeds and internal secrets, and API keys should be managed securely and not included in source code or stored in repositories.
If you’re looking for support with application security or are looking for web application penetration testing, dynamic code reviews, or static code reviews, contact us today.
