A secure authentication system starts with a risk decision, not a login form. Decide how much proof of identity each account, role, and transaction needs. Then protect every route into the account, including the password, the second factor, account recovery, and administrative tools, and treat sessions and authenticators as state you can revoke.
The current technical baseline is NIST Special Publication 800-63B, Revision 4, finalized in July 2025, for credential verification and authenticator management. For application-level controls, use the OWASP Top 10:2025 (category A07, Authentication Failures) and the OWASP Developer Guide’s section on implementing digital identity.
As an Amazon Associate I earn from qualifying purchases.
Authentication answers one question: is this session controlled by the holder of a registered authenticator? It does not decide what that person may do. Roles, permissions, and resource checks belong to authorization, which needs its own design and tests. Every control below assumes authorization is enforced on each request after authentication succeeds.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Which requirements are binding, and where they stop
NIST SP 800-63B is written for digital identity services that interact with government information systems. Its “requires” and “must” statements are normative for services in that scope. Outside that scope, treat them as a current baseline rather than a legal duty, and document the decision to adopt or depart from them.
Keep three layers of obligation separate when you write your requirements:
- NIST normative requirements set the assurance levels, password rules, MFA rules, and session timeouts discussed below.
- OWASP guidance is practitioner advice for application builders. It is widely used and specific, but it is not a standard you certify against.
- Organizational, sector, and jurisdictional rules can add obligations, such as payment-card or health-data requirements, mandatory MFA for staff, log retention, or breach-notification timing. These can be stricter than either source, so record them separately from the technical baseline.
Step 1: Set the assurance target from risk
Begin with a threat model. For each account type and each high-value action, ask what compromise would expose (personal data, money, administrative control, other users’ data), which recovery channels exist and whether an attacker could reach them, and what impersonating this user would let someone do. The answers determine the assurance level for that account or action.
NIST defines three Authenticator Assurance Levels (AALs). The table below lists the requirements this guide relies on. Where a cell says “Not covered here,” consult SP 800-63B-4 directly before relying on a value.
| Requirement | AAL1 | AAL2 | AAL3 |
|---|---|---|---|
| Authentication factors | Single-factor permitted | Multi-factor | Multi-factor |
| Phishing resistance | Not required | Verifier must offer at least one phishing-resistant option | Phishing-resistant cryptographic authenticator required |
| Private key handling | Not covered here | Not covered here | Private key must be non-exportable |
| Maximum overall session timeout (NIST recommendation) | Not covered here | 24 hours | 12 hours |
| Maximum inactivity timeout (NIST recommendation) | Not covered here | 1 hour | 15 minutes |
The timeout values are upper limits from NIST’s recommendations for each level, not defaults to copy. Apply them to the level that actually governs the session, and shorten them where the workflow or the role’s risk calls for it.
Set the level per action rather than per application. One workable pattern is a single-factor-compatible login for low-risk browsing, AAL2 for changes to account details or payment methods, and AAL3 for administrative functions that touch sensitive data.
Build on a tested authentication core
Prefer a centralized, well-tested authentication service or framework over custom credential and session protocols. Keep authentication logic on a trusted server, make failures close securely (a verification error should deny access, not grant it), and make administrative and account-management functions at least as strong as the primary login path.
Step 2: Verify passwords to current NIST rules
Length, blocklists, and composition
- Single-factor passwords: at least 15 characters. A password used only as one part of MFA may be as short as 8 characters.
- Blocklist: check new and changed passwords against lists of common, expected, or compromised values. If a choice is on a list, require a different one.
- No composition rules: NIST prohibits mandatory composition rules such as requiring a symbol, a digit, and an uppercase letter. Length and blocklisting do more useful work.
These are NIST requirements for in-scope services. Teams outside that scope can adopt them as their baseline and then check any sector or contractual policy that sets a different minimum.
Storage
Store a salted hash produced by a password-hashing function designed to be slow and costly to attack offline. Use a unique salt for each password. Set the cost factor as high as your login latency and server capacity allow. Commonly used options include Argon2id, scrypt, and bcrypt; confirm your choice is acceptable under any compliance regime you operate under. Bcrypt ignores input beyond 72 bytes, so long passphrases need either a pre-hashing step or a length check at creation.
Never store plaintext passwords or reversible encryption of them.
Handling in transit and in the system
- Submit passwords only over an authenticated, encrypted channel (TLS in practice).
- Never place credentials in URLs, query strings, or client-side storage.
- Keep passwords out of application logs, error traces, analytics events, and support tooling.
Step 3: Add phishing-resistant MFA
NIST’s SP 800-63B-4 states: “Passwords are not phishing-resistant.” A correct password is therefore not enough at any level where phishing is a realistic threat. NIST also does not treat manually entered one-time codes as phishing-resistant, because an impostor can relay the code to the real verifier before it expires.
Compare the authenticator types
| Authenticator | Phishing-resistant under NIST? | What it means in practice |
|---|---|---|
| Password alone | No | Anyone who obtains the password can attempt a login from anywhere. |
| Manually entered one-time code (app or text-message code typed into a form) | No | A code still raises the bar against password-only theft, but a relay site can pass the code to the real service. |
| FIDO2/WebAuthn authenticator (physical security key or device-built-in platform authenticator) | Yes, when used as a WebAuthn ceremony | The credential is bound to the verifier’s domain, so a lookalike site cannot obtain a usable response. |
Meet the AAL2 and AAL3 requirements
- AAL2: offer at least one phishing-resistant option. Users can keep other MFA methods, but the phishing-resistant path must exist.
- AAL3: require a phishing-resistant cryptographic authenticator whose private key is non-exportable, and meet the verifier requirements that go with it.
- A hardware key does not make a system compliant by itself. Confirm the model and your service support the required WebAuthn protocol and user-verification behavior, and offer a platform authenticator or another enrollment route for users who do not carry a key.
Step 4: Defend login, registration, and recovery
Attackers rarely target only the password form. Protect every entry point that changes or proves account state.
Don’t reveal which accounts exist
Return the same generic message for a wrong username and a wrong password, and make responses to recovery requests consistent whether or not the account exists. Keep response timing similar across the two cases as well, since timing differences can reveal account existence.
Throttle without creating a lockout weapon
Apply rate limits or increasing delays to repeated failures, tracked per account and per source. Avoid permanent lockouts triggered by failures alone, because an attacker can use them to lock a victim out. Prefer short, escalating delays and step-up verification over hard locks.
Detect credential stuffing and brute force
- Log authentication failures with enough context to spot patterns: many accounts from one source, many sources against one account, and unusual success after failures.
- Alert on suspected credential stuffing or brute-force activity, and feed those alerts into the same process that handles reported compromises.
- Screen passwords against breached-password lists at creation and at change.
- Remove default credentials from every service, including staging and internal tools.
Harden every alternate route
Registration, password change, MFA enrollment and removal, account recovery, and administrative account management are all part of the authentication boundary. A strong login form does not compensate for a weak recovery flow or an admin console that accepts a single factor. Require reauthentication before critical operations, and notify users of significant account changes such as a new authenticator, a changed recovery address, or a password change.
Step 5: Manage sessions as revocable state
Create and rotate session identifiers
- When a user authenticates, discard any session that existed before login and issue a new session identifier generated from a cryptographically secure random source.
- Store session state on the server. The browser holds only the opaque identifier.
- Never place session identifiers in URLs.
- Set session cookies with
Secure,HttpOnly, and an explicitSameSitevalue that fits your login and cross-site flows. - Issue a new identifier again when privileges rise, such as after an MFA step-up or entry into an administrative area.
Set timeouts from the assurance level
Use the AAL table in Step 1 as the starting ceiling for overall and inactivity timeouts. Shorten them for roles with broad access, for sessions on shared or unmanaged devices, and for flows that move money or change credentials. Do not copy a timeout from another system without checking the AAL it was designed for.
Recommended Free Tools
Logout, revocation, and CSRF
- Invalidate the server-side session at logout, not only the browser cookie.
- Invalidate sessions when a password changes, an authenticator is removed, or the account’s authorization is withdrawn.
- Give users a list of active sessions with the ability to end any of them, and give administrators the same capability for accounts they manage.
- Use CSRF protection on every state-changing request, because a valid session cookie is otherwise enough for a forged request to succeed.
Step 6: Make recovery and lost authenticators secure
Recovery is usually the weakest path in an authentication system. If recovery skips MFA, the MFA is decorative, so design recovery at the same assurance level as the account it protects.
Best Value
Design recovery paths
- Recovery codes: issue single-use codes at MFA enrollment, show them once, and store them as salted hashes like passwords.
- Enrollment of a second authenticator: allow recovery through another enrolled phishing-resistant authenticator where one exists.
- Support-desk recovery: require a documented identity-verification procedure, log every exception, and avoid using knowledge-based questions alone.
- Notification and delay: notify the account’s existing contact points when recovery begins, and consider a waiting period before newly recovered authenticators can change sensitive settings.
Invalidate lost or compromised authenticators
Provide a reporting channel that works without first logging in, and invalidate the reported authenticator immediately. End the active sessions tied to that authenticator, and record who reported the loss, when, and what changed afterward. Protect the binding between an account and its authenticators from unauthorized changes, since an attacker who can add a new authenticator needs no password at all.
Keep an authenticator inventory
Maintain a record of the authenticators bound to each account and each lifecycle event: enrollment, replacement, removal, recovery, and invalidation. This record is what lets support staff and incident responders answer “what could log in to this account, and when did that change?”
Step 7: Test and operate the full lifecycle
Test every flow end to end, including the failure branches, before release and after each change to authentication code. At minimum, cover these:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Registration, including password blocklist rejection and generic error responses.
- Login with correct, incorrect, and unknown accounts, confirming identical messages and rate-limit behavior.
- MFA enrollment, use, and removal, including the requirement to reauthenticate.
- Password change, confirming that other sessions end and that users receive notification.
- Account recovery through each route, with and without MFA available.
- Session rotation after login and after privilege elevation.
- Logout, session listing, and revocation by the user and by an administrator.
- Authenticator invalidation after a reported loss, and the resulting session termination.
Monitor the same flows in production. Dashboards for failure rates, lockout and throttling events, recovery requests, and new authenticator enrollments show abuse that tests cannot predict.
Choosing a framework or managed identity service
If you buy or adopt an authentication framework or managed identity service instead of building one, compare the options on the same axes:
- Support for each AAL you need, and for phishing-resistant methods specifically
- Password storage behavior, and how existing hashes migrate when the algorithm or cost factor changes
- Recovery design and the authenticator lifecycle, including audit trails for changes
- Session control: rotation, timeouts, listing, and revocation
- Rate limiting and abuse detection
- Federation and protocol support, such as the standards your partners already use
- Auditability and log export
- Deployment location and data-residency constraints
- Accessibility and the recovery experience for users with limited device access
- Total operational burden, including on-call load and upgrade responsibility
NIST and OWASP do not rank vendors, and no single product is established here as the right choice for every system. Use the axes above to test each candidate against your Step 1 assurance target.
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.
