User Login for Web Apps: Passwords, MFA and Passkeys

The references worth following

Three free references cover almost every login decision. NIST's SP 800-63B is written for US federal systems, but its rules on passwords, factors and sessions are a sound model for any business app. The OWASP Authentication Cheat Sheet and its companions turn those rules into implementation advice. The FIDO Alliance maintains the standards behind passkeys. If you are planning a whole portal, our guide to planning a customer portal covers roles, permissions and logging; this guide stays on the sign-in itself.

The password form

NIST revision 4 changed several habits that many sites still follow. For the form itself it says:

• Length, not complexity. A password used as the only factor must be at least 15 characters; one used as part of multi-factor authentication at least eight. Allow at least 64 characters, accept spaces and Unicode, and impose no other composition rules "(e.g., requiring mixtures of different character types)".
• Check a blocklist. Reject passwords on a list of "commonly used, expected, or compromised values" and ask for a different one.
• No scheduled changes. Do not make users change passwords periodically, but force a change when there is evidence of compromise.
• Help people type it. Allow password managers and autofill, permit paste, and offer an option to show the password while it is typed.
• No hints or security questions. NIST forbids password hints that can be read without signing in and prompting users to use security questions, and requires the full password to be checked, never a few selected characters.

Behind the form, NIST requires passwords to be "salted and hashed using a suitable password hashing scheme", with a cost factor that rises over time. They are never stored in readable form.

Error messages matter too. OWASP says the login, reset and recovery responses should be generic, the same whether "the user ID or password was incorrect", "the account does not exist" or the account is locked. Otherwise the login page tells an attacker which email addresses have accounts.

Stopping password guessing

NIST requires the verifier to limit consecutive failed attempts on one account to no more than 100. That is a ceiling, not a target. OWASP's cheat sheet lists what to decide for an account lockout: the number of failed attempts before the lock, the time window they must fall in, and how long the lock lasts. Some apps use an exponential delay instead of a fixed lock. OWASP also says the failure counter should belong to the account, not the IP address, so an attacker cannot simply spread attempts across many addresses. Log failures and lockouts and review them; OWASP lists this under logging and monitoring.

Second factors: which ones

Multi-factor authentication (MFA) means proving two different things, such as a password and a code from an app. The OWASP MFA Cheat Sheet compares the options:

• Authenticator app codes (TOTP). The user scans a QR code into an app that generates a new code every 30 seconds by default. Most websites use the standard format, so any compatible authenticator app works.
• SMS and phone-call codes. OWASP notes that NIST SP 800-63B-4 designates them "a restricted authenticator because of SS7 interception, SIM-swap, and number-porting attacks", and advises not to use SMS for high-value applications or ones that handle personal data.
• Email. NIST says email "SHALL NOT be used for out-of-band authentication". Email confirmation and recovery codes are a separate matter.
• Passkeys and security keys. These are the phishing-resistant options, covered below.

At NIST's AAL2, the level that requires two factors, verifiers "SHALL offer at least one phishing-resistant authentication option". A sensible plan is to require MFA for staff and administrators, offer it to every user, and require it where the app holds sensitive data or moves money.

Passkeys

The FIDO Alliance describes passkeys as FIDO credentials that "replace passwords with cryptographic key pairs for phishing-resistant sign-in". The user approves the sign-in "with the same biometric or PIN or on-device password" they use to unlock their phone, computer or security key. Passkeys "can be securely synced across a user's devices, or bound to a particular device".

Because the key pair is tied to your site, a fake login page cannot collect anything useful. OWASP adds one implementation detail: when a passkey is used as MFA, the server should require user verification and check the returned flag, since "a touch confirming user presence alone is not a second factor". Offering passkeys alongside a password lets users switch at their own pace.

Sessions and time-outs

After sign-in, the session cookie is the key to the account. OWASP's Session Management Cheat Sheet says:

• Issue a new session ID at login and after any change in privilege, such as a password change.
• Mark the cookie Secure (sent only over HTTPS) and HttpOnly (not readable by scripts), and set SameSite=Strict or Lax explicitly.
• Use both an idle timeout and an absolute timeout, so a forgotten session closes.

NIST gives concrete limits. At AAL1 the overall timeout should be no more than 30 days. At AAL2 it should be no more than 24 hours, with an inactivity timeout of no more than one hour. OWASP also recommends asking for the current password or another bound factor again before sensitive changes, such as a new password, a new email address or shipping to a new address. HTTPS on every page is the foundation; see our guide to SSL certificates and HTTPS.

Password reset and account recovery

The reset flow is often the weakest part of a login system. OWASP's Forgot Password Cheat Sheet says to return the same message for existing and non-existing accounts, in the same time, and to use tokens that are random, long enough, stored securely, "single use and expire after an appropriate period". Do not change the account, for example by locking it, until a valid token is presented.

Losing a second factor is harder. NIST recognises four classes of account recovery: saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing. It requires that a recovery event "always causes one or more notifications" to the user, so a fraudulent recovery gets noticed. Saved recovery codes must be stored hashed and replaced after use. Decide how your support team will handle a user who has lost everything before launch, because OWASP warns that MFA reset must not become "a way to bypass MFA".

A login checklist

• Minimum length, no composition rules, a blocklist, paste and password managers allowed.
• Passwords hashed with a proper password hashing scheme.
• Generic error messages on login, reset and sign-up.
• Per-account limits on failed attempts, logged and reviewed.
• MFA with an authenticator app or passkey; required for staff and administrators.
• Secure, HttpOnly, SameSite session cookies, a new session ID at login, idle and absolute timeouts.
• Re-authentication before changing the password, email address or other sensitive details.
• Single-use, expiring reset tokens and a written recovery procedure with notifications.

Mobile apps add their own concerns, such as storing tokens on the device; see our guide to mobile app security basics. If you are still deciding whether you need accounts at all, start with web app vs website.

Frequently asked questions

Should we still make users change passwords every 90 days?

No. NIST SP 800-63B says verifiers shall not require subscribers to change passwords periodically, but shall force a change if there is evidence the password has been compromised.

Is an SMS code good enough as a second factor?

It is better than a password alone, but NIST treats SMS and phone codes as a restricted authenticator, and OWASP advises against SMS for high-value applications or ones handling personal data. An authenticator app or a passkey is a stronger choice.

Can passkeys replace passwords completely?

The FIDO Alliance describes passkeys as a replacement for passwords. In practice, plan the recovery route first: a user who loses every device needs a safe way back in, such as saved recovery codes, which NIST recognises as one of four recovery methods.

How long should users stay logged in?

It depends on what the app protects. NIST suggests an overall limit of no more than 30 days for its lowest assurance level, and no more than 24 hours with a one-hour inactivity timeout where two factors are required.

Building a portal or web app with user accounts? We store passwords with modern hashing and protect sign-in against guessing. See our web app development service and all our services, or email [email protected].