Account-Enumeration

Account enumeration is the under-appreciated cousin of credential stuffing. The attacker doesn't break in — they map who is in. Armed with a confirmed list of valid user emails, every subsequent attack is more efficient: targeted phishing where 'we noticed unusual activity on your account' actually lands, credential stuffing scoped to known users (so 99% of the rate-limit budget isn't wasted on non-existent accounts), and OSINT-grade customer lists for sale to competitors. The bug usually feels harmless to developers ('but the password was wrong, we didn't leak anything'), which is why it persists. Privacy regulators in the EU disagree — confirming somebody has an account on a service is a personal-data disclosure on its own.

Account enumeration appears when login, signup, reset, or invitation flows reveal whether a specific account exists. That signal helps attackers target credential stuffing and social engineering.

Spear-phishing list construction at scale — the attacker confirms which emails on a leaked list are users of your service, then crafts service-specific phishing. Credential stuffing target list, where each attempt is now meaningful instead of guesswork. GDPR / CCPA exposure: confirming someone has an account is a personal-data disclosure when the service is sensitive (healthcare, dating apps, financial services). Brand damage when 'your service can be enumerated' shows up in security write-ups.

Return identical responses for 'no user' and 'wrong password' on the login flow. Render the same template, the same status code, the same body. For signup, return a generic 'we will send a confirmation if this email is new' regardless of whether the email already exists; send the confirmation only when it actually is new (and send a different email — 'someone tried to sign up with your address' — when it isn't). For password reset, use the same response shape: 'if this email exists, we have sent a link.' Send a different email under the hood (no email at all if the address isn't registered, vs the reset link if it is). Make response timing constant by always running the password-hashing path even when the user doesn't exist (verify against a dummy hash). Add per-IP and per-email rate limits to the auth endpoints so even if the responses leak, the attacker's enumeration speed is throttled. As a final layer, monitor for high-volume requests against auth endpoints with non-existent emails — that pattern is enumeration in progress.