Keep Sign-In Responses Identical
Security & Access · authentication, security, microcopy
Updated 2026-08-04
- Never let the interface reveal whether an account exists, which is called account enumeration. No account with that email confirms which addresses are registered with your product, which is exactly what someone building a target list needs.
- Use one message for both failures. That email and password do not match is the standard, and it costs a small amount of clarity for a large amount of safety.
- Make the timing identical too. A timing attack measures the response that comes back faster for an unknown address and leaks the same fact the wording was hiding.
- Apply the rule to every surface that touches an account, not just sign-in:
- Password reset, which should confirm the email was sent either way.
- Sign-up, where "already registered" is the same disclosure in reverse.
- Invitations to an existing account.
- Any lookup by email, phone, or username.
- Say what happens next in the neutral case. "If that address has an account, a reset link is on its way." is honest, unambiguous, and reveals nothing.
- Pay back the clarity elsewhere. Autofill support, a visible caps lock warning, and a show password control help the honest user without helping the attacker.
- Handle the genuinely stuck user through a path that verifies them first. Support can confirm an account exists once identity is established, which the login form cannot do.
- Do not undo it in the analytics. An event named "unknown email attempted" exported to a third party recreates the leak you removed from the screen.
Helpfulness and safety genuinely conflict on the sign-in screen, and this is one of the few places where safety has to win.
Related guides
UX Handbook