Account existence is privacy-sensitive metadata

Account existence should be treated as sensitive metadata, not a harmless bit of UI feedback. Someone can enter a partner’s, coworker’s, or public figure’s email address into signup and recovery forms across services and gradually build a map of where that person has an account. No password is needed, and the target may never know it happened.

OWASP recommends generic responses for login, registration, and recovery, including a deliberately ambiguous “If an account exists, we’ll email you” message, with consistent timing as well. That seems like the right privacy default, but it makes legitimate troubleshooting harder: did I mistype the address, hit a rate limit, trigger a recovery delay, or simply lose access to the inbox? Should hiding account existence be treated as a basic privacy feature or an unacceptable usability cost?

The distinction between “can happen” and “often happens” matters here. The guidance establishes enumeration as a recognized risk and recommends non-enumerating responses; it does not establish how common cross-service account mapping is. That is still enough to justify a privacy-preserving default, in my view.

The timing point is easy to miss. Returning the same sentence while taking noticeably longer for real accounts still leaks the answer. Uniform response time and throttling are part of the design, not polish added afterward.

From a product perspective, the generic message is honest but not very helpful. “Check your inbox” can mean nothing arrived, the address was wrong, delivery is delayed, or the flow is throttled. I’d accept the privacy tradeoff, but the surrounding recovery experience has to explain those possibilities without confirming which one applies.

The ordinary threat model is stronger than the dramatic one. Enumeration can support harassment, unwanted discovery, or social targeting without anyone breaking into an account. You do not need to claim mass abuse to say that exposing the bit is unnecessary.

There’s a wording problem as well as a protocol problem. Users want a clear answer because they are trying to complete a task, while privacy requires withholding exactly that answer. The interface should acknowledge uncertainty plainly rather than pretending the generic message is equally useful to everyone.

Support teams will absorb some of this ambiguity. People will report that recovery mail never came, and the operator cannot always tell them whether the address was mistyped or the request was delayed. That cost is real, even if it is hard to quantify from the security guidance alone.

I’m not fully convinced this belongs everywhere. For a low-sensitivity service, making signup and recovery opaque may create enough failed attempts and duplicate accounts to outweigh a fairly speculative privacy benefit. The threat model should be service-specific, not a universal rule.

Implementation-wise, teams often fix the message and forget every other observable: status codes, response length, timing, and side effects like mail behavior. An ambiguous string over an otherwise distinguishable endpoint is security theater.

The email dependency is the practical failure mode. If someone has lost access to the inbox, the generic response gives them no confirmation that trying again will help. I still prefer non-enumeration, but recovery needs a separate path rather than pretending email solves identity.

A little confusion is cheaper than publishing everyone’s account list one form submission at a time.

NIST’s position is useful here: recovery is expected to be less convenient than ordinary login and may involve waiting, notifications, and throttling. That supports accepting some friction, but it does not prove that every ambiguous flow has a positive net effect.

For a small service, I’d make the message generic and put the operational effort into a clear recovery status page and good mail delivery. Customers can tolerate waiting better than being told something that confirms their address is registered.