Home / Knowledge hub / Account enumeration
Knowledge hub
Account enumeration
Learning which emails have accounts because your app answers differently.
What it means
Account enumeration is when an outsider can tell which usernames or email addresses have accounts on your service, because the app behaves differently for ones that exist. The difference may be a message, a status code, the length of the reply or the time it takes.
It is a form of [[enumeration]] aimed at identities. The tester does not need to sign in. They send a list of addresses to a sign-in, sign-up or reset form and read which ones got a different answer. A long list can be checked in minutes.
Why it matters
A list of valid accounts makes every other attack cheaper. Credential stuffing and brute force need only try real users, and phishing can be aimed at people who definitely use you. For some services, the list is sensitive in itself, such as a health or finance product.
It is also a privacy matter. Confirming that a named person has an account can reveal something about them. Regulators and security reviewers treat it as a low to medium issue, but it often sits at the start of a bigger chain.
How it shows up
It appears in three places: sign-in ("no such user" against "wrong password"), password reset ("we sent a link" against "unknown email") and sign-up ("email already taken"). It can also appear in response time, since checking a real password hash takes longer than rejecting an unknown name.
The fix is one answer for both cases: "incorrect email or password", and "if an account exists, we have sent a link". For sign-up, say the same on the page and tell the real owner by email. Make timing match, and add rate limits and bot checks to all three forms.
Questions people ask
Account enumeration, answered
Is account enumeration always a vulnerability?
It depends on what the account list exposes. OWASP lists it as a weakness to test, and the risk is higher for sensitive services. The fix is cheap, so most teams close it anyway.
Do we have to hide it on sign-up too?
Sign-up is the hard one, because the user needs to know the address is taken. The safe pattern is to show a neutral message and send an email either way.
Can timing reveal accounts?
Yes. If the app hashes a password only when the account exists, the reply is slower for real accounts. Hash a dummy value or equalise the work.
Does a CAPTCHA fix it?
It slows automation but does not remove the difference in answers. Fix the answers first, then add limits and bot controls.
How do we test for it?
Compare responses for a known address and an unknown one on sign-in, reset and sign-up. Compare status, body, headers and timing over many tries.
Related
Terms that sit next to this one
Enumeration
Working out what exists by asking repeatedly and watching the answers.
Credential stuffing
Trying passwords leaked elsewhere, because people reuse them.
Password reset flaw
A weak reset link or code that lets someone else take over the account.
Rate limiting
Capping how often something can be attempted, per user or per address.
Password spraying
Trying a few common passwords across many accounts to stay under lockout limits.
Does your app answer everyone the same?
We compare how your sign-in, sign-up and reset forms answer known and unknown accounts, and report what we measured. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.