Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A secure authentication system is built by matching controls to what a compromised account would let an attacker do, then holding every route into that account to the same standard. The current technical baseline is NIST SP 800-63B-4 (Revision 4, finalized July 2025) for credential verification, MFA, and session behavior, supported by OWASP’s A07 Authentication Failures category in the OWASP Top 10:2025 and the OWASP Developer Guide’s digital identity guidance for application-level defenses. In practice that comes down to five decisions: set the assurance level from risk, verify passwords under NIST’s rules, offer phishing-resistant MFA, protect login, registration, recovery, and administrative paths alike, and treat sessions and authenticators as state you can revoke.
Authentication proves control; authorization decides what that control may do
Authentication answers one question: is this request being made by the holder of a particular account or authenticator? Authorization answers the next one: what may that authenticated party do? A login system can work perfectly and still expose data because an endpoint skips its permission check. Keep the two designs separate. Authentication determines how confidently you establish a session and how strong that establishment was. Authorization must be checked again for each action. This article covers the first.
Know which rules bind you and which are advice
NIST SP 800-63B-4 is written for digital identity services that interact with government information systems. Its normative requirements bind systems inside that scope. Outside it, treat them as a current technical baseline rather than a legal obligation, unless a contract, sector rule, or data-protection law says otherwise. OWASP’s Top 10 and Developer Guide are application-security guidance, not a compliance standard. Where an organizational, jurisdictional, or regulatory obligation is stricter than either source, the stricter rule governs. Record which control comes from which source so engineers and auditors can trace it. The recommendations here are standards and practitioner guidance, not measured breach statistics, so none of them should be read as a claimed reduction in breach rates.
Set the assurance level from risk
Start with a threat model. For each account type, document what a takeover would expose (personal data, money, administrative control), which recovery paths exist, and what impersonation would cost the business and the user. Use that assessment to choose an assurance level. NIST defines three Authenticator Assurance Levels (AAL1, AAL2, and AAL3) with progressively stronger authenticator requirements. A single login policy for every user and action is the most common design error. A read-only account and a billing administrator should not share the same controls.
#1 Best Overall
| Assurance level | Factor requirement | Phishing-resistance requirement |
|---|---|---|
| AAL1 | Single-factor authentication permitted | Not stated (NIST SP 800-63B-4) |
| AAL2 | Multi-factor authentication | The verifier must offer at least one phishing-resistant option |
| AAL3 | Multi-factor, using a cryptographic authenticator | A phishing-resistant authenticator is required, and its private key must be non-exportable |
Source for the table: NIST SP 800-63B-4, Revision 4.
Prefer a centralized, well-tested authentication service or framework over custom credential and session code. Keep authentication logic on a trusted server component, and make it fail securely. If the MFA service, the rate-limit store, or a risk check cannot complete, deny access rather than skipping the check.
Passwords: one credential path, built to current rules
A password remains a useful first factor, but it is not phishing-resistant. NIST says so directly: “Passwords are not phishing-resistant.” Design the password path to resist guessing, reuse of breached passwords, and offline cracking of a stolen database. Do not assume it will stop a convincing fake login page.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Minimum length
| How the password is used | Minimum length under NIST SP 800-63B-4 |
|---|---|
| Single factor (the password is the only authenticator) | 15 characters |
| Part of MFA (the password is one factor of several) | 8 characters |
- Check any chosen password against a blocklist of common, expected, or compromised values. If it appears on the list, require a different choice.
- Do not impose additional composition rules, such as mandatory symbol or digit mixes. NIST prohibits them.
Storage
Store only a salted hash produced by a password-hashing function designed to resist offline attack. Give every password its own unique salt. Set the cost factor as high as practical without making legitimate logins unacceptably slow. Adaptive, memory-hard functions such as Argon2id, scrypt, or bcrypt are common choices. If you are moving from an older hash, rehash each password on the user’s next successful login instead of forcing a reset of every account.
Never store plaintext passwords. Keep them out of logs, URLs, analytics events, error messages, and client-side storage. Transmit them only over an encrypted, authenticated channel such as TLS.
MFA: choose methods by the attacks they stop
Describe each MFA method by the attack it defeats and the attack it does not. A numeric code that a user types into a page can be relayed to the real site in real time by a phishing proxy, which is why NIST does not treat manually entered OTP outputs as phishing-resistant. The difference is in how the credential is bound to the destination.
What counts as phishing-resistant
| Method | Phishing-resistant under NIST SP 800-63B-4? | Reason |
|---|---|---|
| Password alone | No | NIST states that passwords are not phishing-resistant. |
| Manually entered OTP (a code typed into a login page) | No | An impostor can relay the code to the real verifier. |
| WebAuthn-based FIDO2 authenticator (security key or platform authenticator) | Yes, if the implementation meets the required protocol and user-verification behavior | Verifier-name binding ties the authentication to the verifier’s domain. |
Security keys as one option
A FIDO2/WebAuthn-compatible security key is one way to meet the phishing-resistant requirement, and it is an optional example rather than a requirement. A key alone does not make a system AAL3-compliant. The verifier, the protocol flow, user verification, and the key’s non-exportable private key all matter. Before rollout, confirm that the device models you support and your implementation both handle the required protocol and user-verification behavior. Offer a platform authenticator path for users who will not carry a separate key, and plan a backup route for users who lose theirs (covered under recovery below).
Defend login, registration, and recovery
Attackers rarely go through the most visible door. Every path that can establish or change a credential belongs to the authentication boundary: login, registration, password change, MFA enrollment and removal, account recovery, and administrative account management. A strong login form does not compensate for a weak recovery flow or an admin console that accepts a password alone.
Stop account enumeration
Return the same generic response from login, registration, and recovery whether or not the account exists. Match response timing as well, because a slower path can reveal existence even when the wording is identical.
Rank #4
Throttle without creating a lockout weapon
Apply rate limits or increasing delays to repeated failures, tracking both the account and the source. Avoid hard lockouts after a few failed attempts, because they let an attacker lock a victim out of their own account. Prefer delays, step-up verification, or temporary challenges that the legitimate user can clear.
Detect automated abuse
Log authentication failures with the time, source, account, outcome, and which factor failed, but never log passwords or codes. Alert on the two common patterns: credential stuffing, where many accounts each see a few attempts from varied sources, and brute force, where many attempts target one account.
Recovery is an authentication flow in its own right
Recovery is designed to bypass normal factors, so attackers target it. Require proof at least as strong as the account’s normal login. Practical controls include:
- Require a fresh authentication before changing the email address, removing an MFA factor, or changing the password.
- Notify the user through existing contact points when a significant account change occurs.
- Issue one-time recovery codes at MFA enrollment, and show users how to store them offline.
- Route lost-authenticator reports into the invalidation process described in the lifecycle section below.
Administrative and privileged accounts
Administrative and account-management functions must be at least as secure as the primary login path. For privileged roles, assign the highest assurance level in your model, require a phishing-resistant method, and make sure no legacy endpoint accepts a password alone for the same actions.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Sessions: treat them as revocable server-side state
After login, the session is the credential the rest of the application trusts. Build it so you can end it at any time.
Session lifecycle
- Verify the password and any second factor completely before creating a session.
- Generate a new, unpredictable session identifier at login, and discard any identifier that existed before authentication. This blocks session fixation.
- Store session state on the server. Set the session cookie with the Secure and HttpOnly attributes and an appropriate SameSite value. Never place the session identifier in a URL.
- Enforce an inactivity timeout and an absolute timeout chosen for the assurance level and application risk (see the table below).
- Use CSRF protection on every state-changing request.
- On logout, invalidate the server-side session. Deleting the cookie in the browser is not enough.
- When account authorization ends, such as a role removal, account disablement, or password change, revoke every session bound to that account.
- Give users and administrators a way to list active sessions and terminate them.
Timeout values by assurance level
| Assurance level | Overall timeout | Inactivity timeout |
|---|---|---|
| AAL2 | Recommended no more than 24 hours | Recommended no more than 1 hour |
| AAL3 | Maximum 12 hours | Recommended no more than 15 minutes |
These are NIST SP 800-63B-4 values. This article does not reproduce AAL1 session values, so check the standard’s session section for them. Treat the figures as ceilings to test against, not defaults to copy, and adjust them for the application’s own risk.
Operate and test the authentication lifecycle
Authentication changes over time as authenticators are added, lost, and reset. Operating it well means knowing what is bound to each account and being able to cut those bindings off quickly.
- Keep an authenticator record for each account: type, when it was bound, when it was last used, and each significant event (enrollment, removal, reset, recovery).
- Provide an immediate invalidation path for reported loss, theft, or compromise, reachable without the lost factor.
- Protect authenticator binding and recovery settings against unauthorized change. An attacker holding a session often targets these first.
- Keep audit logs of authentication and account-management events, and restrict who can alter them.
End-to-end test checklist
- Registration, including the duplicate-account response
- Login with each supported factor, a wrong password, and a wrong second factor, plus throttling behavior
- MFA enrollment and removal, confirming that removal requires fresh authentication
- Password change and reset, confirming that other sessions are revoked afterward
- Each recovery route you offer, including the one for a lost security key
- Session rotation at login, both timeouts, logout, and revocation from a second device
- Administrative account-management paths, tested against the same controls as the main login
Choosing a framework or managed identity service
Whether you build on a framework or adopt a managed identity service, compare candidates on these axes:
- Assurance-level support: can it enforce AAL2 and AAL3 requirements, including the phishing-resistant options?
- Phishing-resistant methods: which are supported, and how is verifier-name binding handled?
- Password storage and migration: which hashing scheme is used, and can it rehash on login?
- Recovery and authenticator lifecycle: recovery flows, immediate revocation, and audit records
- Session control: rotation, server-side invalidation, and user and administrator termination
- Rate limiting and abuse detection, including whether lockouts can be weaponized
- Federation and protocol support
- Auditability and deployment or data-residency constraints
- Accessibility and the user recovery experience
- Total operational burden over the life of the system
The NIST and OWASP guidance does not establish a single best vendor or product. Match the choice to your assurance targets and test it against the checklist above.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
