Preventing account enumeration in login, registration and reset forms

What it is

The OWASP Authentication Cheat Sheet (cited) calls any observable difference between "user exists" and "user does not exist" a discrepancy factor. It asks that login, password reset and password recovery respond with a generic error message and the same HTTP response, whether the user ID or password was wrong, the account does not exist, or it is locked. Registration is the hard case: "this user ID is already in use" is the most common leak, and the cheat sheet's replacement is a message such as "a link to activate your account has been emailed to the address provided", with the real outcome delivered in that email (a welcome for new addresses, a notice for existing ones).

Why it matters

A confirmed list of accounts turns blind guessing into credential stuffing and password spraying against known targets, and lets an attacker phish exactly the people who have an account. The leak often sits in a detail nobody reviewed: a 200 for one path and a 403 for the other, a different redirect target, or the "quick exit" pattern in which the server skips the password hash for unknown users and returns visibly faster.

How to apply

• Write one message per form and one HTTP status; test both branches with a proxy and compare bodies, headers, cookies and status codes, not just the visible text.
• Avoid the quick exit: compute a password hash against a dummy hash for unknown users so both branches cost the same, and keep other side effects identical.
• For registration and reset, move the distinguishing outcome into email or another channel the account owner controls.
• Throttle and add CAPTCHA where the generic message is unacceptable for usability; the cheat sheet notes that brute-force protection also stops enumeration at scale.
• Check other endpoints that touch usernames: profile URLs, "invite a colleague", API error codes, and OAuth or SSO error pages.

Pitfalls

Generic messages confuse legitimate users; the cheat sheet leaves the trade-off to the application's criticality and suggests routing failures to a support page in critical applications. Server-side timing differences remain measurable over many samples even after removing the obvious ones. A sign-up flow that requires a unique username has to leak by design; make the leak expensive rather than pretending it is gone.