Authentication

NIST SP 800-63-4 (final in 2025) gives the standard vocabulary. A claimant proves control of one or more authenticators to a verifier; once bound to a subscriber account by a credential service provider, the authenticator becomes the thing checked at each login. Strength is graded as authenticator assurance levels in SP 800-63B-4: AAL1 permits a single factor, AAL2 requires two distinct factors, and AAL3 requires a phishing-resistant authenticator with a non-exportable private key. The same document sets reauthentication limits: at AAL2 the session should last no more than 24 hours overall and 1 hour of inactivity, and at AAL3 no more than 12 hours overall, with inactivity limited to 15 minutes.

The factors (knowledge, possession, inherence) are not equally robust against today's main attack, adversary-in-the-middle phishing, in which a proxy such as Evilginx relays the password and one-time code or push approval to the real site in real time and keeps the resulting session cookie. SP 800-63B-4 §3.2.5 defines phishing resistance as preventing disclosure of authenticator outputs to an impostor verifier, achieved either by channel binding (tying the output to the TLS channel, as with client certificates) or verifier-name binding (tying it to the relying party's identifier, as WebAuthn does with the origin and RP ID). Other hard rules in the same document: verifiers must stop an authenticator after at most 100 consecutive failed attempts on an account (§3.2.2), must not use knowledge-based security questions, and PSTN-delivered codes (SMS, voice) are a "restricted" authenticator (§3.1.3.3).

Underneath, most protocols are challenge-response: the verifier sends a fresh nonce and the claimant returns a value only the authenticator holder could compute, which defeats simple replay. Kerberos (RFC 4120) issues tickets from a key distribution centre so services never see the password, while NTLM's use of the password hash as the key is what makes pass-the-hash possible. Mutual authentication, where the server also proves its identity, is what TLS server certificates provide. Machines authenticate with mutual TLS, signed JWT client assertions (RFC 7523) or platform-issued workload identities rather than passwords.

Common misconceptions: authentication is not identity proofing, which happens once at enrolment (identity assurance levels in SP 800-63A); the weakest path is often account recovery or a help-desk reset rather than the login page; and an authentication result is a point-in-time event whose value is carried forward by a session, so session theft bypasses even strong MFA. Authentication answers who is asking; authorization, evaluated afterwards, decides what they may do.