Password standards: 2024 requirements

The requirements set by online services for user verification — whether it’s password length, a mandatory phone number, or biometric checks with blinking — are often governed by industry standards. One of the most important documents in this field are the NIST SP 800-63 Digital Identity Guidelines, developed by the US National Institute of Standards and Technology (NIST). This standard is mandatory for all US government agencies and their contractors; in practice, this means that all the world’s largest IT companies adhere to this standard, with consequences reaching far beyond the borders of the United States.

Even organizations that aren’t strictly required to comply with NIST SP 800-63 would still benefit from familiarizing themselves with these updated guidelines, as they often serve as a blueprint for regulators in other countries and industries. The recent update, developed through four rounds of public revisions with industry experts, reflects the latest understanding of digital identification and authentication. It covers security and privacy requirements, and considers a possible distributed (federated) approach. The standard is practical, and factors in human considerations — how users respond to various authentication requirements.

This new edition formalizes concepts, and outlines requirements for:

• passkeys (referred to in the standard as “syncable authenticators”);
• phishing-resistant authentication;
• user storage of passwords and accesses (“attribute bundles”);
• regular re-authentication;
• session tokens.

So — how to authenticate users in 2024?

Password authentication

The standard defines three Authentication Assurance Levels (AALs). AAL1 allows the least restrictions and minimal confidence that the user is indeed who they claim to be, while AAL3 offers the strongest guarantees and requires more stringent authentication. Only AAL1 permits single-factor authentication — such as just a single password.

The requirements for passwords are as follows:

• Only centrally verified secrets sent by the user to the server over a secure channel qualify as passwords. Passwords that are stored and verified locally are termed “activation secrets” and have different requirements.
• Passwords shorter than eight characters are prohibited, with a minimum of 15 characters recommended.
• Scheduled, mandatory password rotation is considered an outdated practice and therefore prohibited.
• It’s also prohibited to impose requirements on password composition (such as “your password must contain a letter, a number, and a symbol”).
• It’s recommended to allow using any visible ASCII characters, spaces, and most Unicode symbols (such as emojis).
• Maximum password length, if enforced, must be at least 64 characters.
• Truncating passwords during verification is prohibited, but trimming leading/trailing whitespace is allowed if it interferes with authentication.
• Using and storing password hints or security questions (such as “your mother’s maiden name”) is prohibited.
• Commonly used passwords must be eliminated through the use of a stop-list of popular or leaked passwords.
• Compromised passwords (for example, appearing in data breaches) must be reset immediately.
• Login attempts must be limited in both rate and number of unsuccessful attempts.

Activation secrets

These are PINs and local passwords that restrict access to the on-device key storage. They can be numeric, with a recommended minimum length of six digits— though four digits are permissible. For AAL3, the primary cryptographic secret (for example, a passkey) must be stored in a tamper-resistant chip, and decrypted using the activation secret. For AAL1 and AAL2, it’s enough that the key restricts access from outsiders, with a limit on input attempts — no more than 10 tries. After exceeding the limit, the storage is locked, requiring an alternative authentication method.

Multi-factor authentication (MFA)

It’s recommended to implement MFA at all AAL levels, but while this is only a suggestion for AAL1, it’s mandatory for AAL2, and only phishing-resistant MFA methods are acceptable for AAL3.

Only cryptographic authentication methods are considered phishing-resistant: USB tokens, passkeys, and cryptographic keys stored in digital wallets conforming to SP 800-63C (distributed identification and authentication services). All cryptographic secrets must be stored in tamper-resistant systems (such as TPM or Secure Enclave). Synchronizing keys across devices and storing them in the cloud is permitted, provided each device meets the standard’s requirements. These provisions enable the use of passkeys across Android and iOS ecosystems.

To ensure resistance to phishing, authentication must be tied to the communication channel (channel binding) or verifier service name (verifier name binding). Examples of these approaches include client-authenticated TLS connections and the WebAuthn protocol from the FIDO2 specification. In simple terms, the client uses cryptography to confirm they’re connecting with the legitimate server rather than a fake one set up for AitM attacks.

Time-based one-time passwords (TOTP) from authenticator apps, SMS codes, and one-time codes from scratch cards or envelopes are not phishing-resistant but are permitted for AAL1 and AAL2 services. The standard specifies which methods for handling one-time codes don’t qualify as MFA and must be avoided. One-time codes should not be sent through email or VoIP — they must be delivered over a communication channel that’s separate from the primary authentication process. OTPs sent through SMS and traditional telephone lines are acceptable — even if both connections (for example, internet and SMS) are on the same device.

Use of biometrics

The standard restricts the use of biometrics — they may serve as an authentication factor, but are prohibited for identification. Biometric checks must be used only as a supplemental factor combined with proof of possession (for example, a smartphone or token — something you physically possess).

Biometric equipment and algorithms must ensure a false match rate (FMR) no greater than 1 in 10,000, and a false non-match rate (FNMR) no greater than 5%. These accuracy rates must be consistent across all demographics. The verification algorithm must also be resistant to presentation attacks in which the sensor is shown a photo or video instead of a live person.

After generating and verifying a cryptographic “fingerprint” from biometric data, the standard mandates immediate deletion (zeroing out) of collected biometric data.

Like other authentication methods, biometric checks must include limits on input rate and the number of unsuccessful attempts.