MFA, Passkeys, and Modern Password Policy (NIST SP 800-63B-4)

Step 1: Adopt NIST's password rules

For passwords used as the only factor, NIST requires a minimum length of 15 characters. A password used only as one part of multi-factor authentication may be shorter, with a minimum of 8. Systems should accept passwords of at least 64 characters and allow printing ASCII, spaces, and Unicode. They must not impose composition rules such as requiring a mix of character types, and must not force periodic password changes, except when there is evidence of compromise. Knowledge-based questions and password hints are not allowed.

Step 2: Block bad passwords and limit guessing

When a password is created or changed, check the whole password against a blocklist of breached, common, and context-specific values such as the username or service name, and tell the user why a password was rejected. Allow password managers, autofill, and pasting. Limit consecutive failed attempts, with NIST capping them at no more than 100, and use stronger throttling in practice. Store passwords with a salted, slow hash as described in the previous lesson.

Password policy checklist (NIST-aligned)
[x] Minimum 15 characters (8 if only used with MFA)
[x] Accept up to at least 64 characters, including spaces and Unicode
[x] No composition rules, no forced periodic rotation
[x] Check against breached/common-password blocklist
[x] Allow paste and password managers
[x] Rate-limit failed attempts; log failures
[x] No security questions or password hints

Step 3: Understand authentication assurance levels

NIST defines three levels of confidence. AAL1 gives basic confidence and allows a single factor. AAL2 gives high confidence, requires two distinct factors, and requires that a phishing-resistant option be offered. AAL3 gives very high confidence, requires a phishing-resistant authenticator with a non-exportable cryptographic key, and uses two factors. Higher levels also shorten how long a session may last before reauthentication. Choose the level by the risk of what the account can do.

Step 4: Prefer phishing-resistant authenticators

Codes that a user types in, such as SMS or app one-time passwords, can be handed to an attacker on a fake site. NIST classes the use of the telephone network for out-of-band authentication as a restricted authenticator: services must offer an alternative, warn users about the risk, and plan to move off it. Phishing-resistant methods use cryptography bound to the real website, and WebAuthn, the standard behind FIDO2 security keys and passkeys, is the main example.

Step 5: Learn how passkeys work

A passkey is a FIDO credential: your device holds a private key, and the website stores only the matching public key. You approve sign-in with a biometric or PIN. Because the credential is tied to the site's origin, a fake site cannot use it, which removes most phishing, and a stolen server database contains no secrets to reuse. Passkeys can be device-bound, or synced across a user's devices by a cloud service. NIST allows synced passkeys at AAL2, but not at AAL3, because syncing makes the key exportable. On the web, the browser exposes the WebAuthn API, and servers must verify the responses with a maintained library, never custom code.

// Browser: register a passkey (options come from your server)
const credential = await navigator.credentials.create({ publicKey: options });
// send the result to the server for verification

// Browser: sign in with a passkey
const assertion = await navigator.credentials.get({ publicKey: requestOptions });
// the server checks the signature, challenge, and origin