Authentication Failure Classification and Anti-Enumeration Automation: Your Password Was Never the Problem

Mapping every possible failure from an external, third-party dependency into a single, fixed, user-facing message is a common and often deliberately protective simplification — for a login screen specifically, it also serves a real security purpose: never confirming to an outside caller exactly why an attempt failed, so a wrong password and a nonexistent account cannot be told apart by probing. The tradeoff sits underneath that simplification: an external authentication provider can fail for reasons that have nothing to do with the credential submitted at all — an outage, a timeout, a rate limit reached — and folding every one of those into a sentence specifically shaped like "your credential was wrong" tells the person nothing true about what actually happened, at exactly the moment they most need an accurate signal for what to do next.

Centriu Vértice's login flow reads a fixed piece of code that, before this fix, handled every possible outcome from the underlying authentication call the identical way: any error at all — regardless of its actual cause — produced the exact sentence "Email ou senha incorretos" (email or password incorrect). Measured directly against a real, slow authentication attempt: a login took 11.5 seconds, and the authentication provider itself reported a timeout — `context deadline exceeded`, surfaced through the transport layer as an HTTP `504`. The person attempting to log in was told their password was wrong. Their password was correct; the provider itself had simply failed to respond in time.

The fix replaces that one fixed mapping with a dedicated classification function that reads the most reliable signal available FIRST, specifically because different failure modes surface their true nature through different, sometimes-absent signals: an HTTP status code is checked before a provider-specific error code, and a code is checked before any free-form text, because a rate-limit response can arrive with no distinct error code attached at all, and a genuine service failure can arrive carrying wording that, read on its own, sounds exactly like a rejected credential. Reading signals in the wrong order, or trusting free text as if it reliably named the true cause, would reproduce a version of the same original problem in a more complicated form.

Four distinct outcomes now exist where one used to. An actually-invalid credential, an unrecognized account, or an unconfirmed email address all still produce the same, deliberately unchanged message — "Email or password incorrect" — preserving exactly the ambiguity a login screen needs for this specific case. A rate limit produces its own distinct message naming the actual situation (too many attempts in a short time). Any other authentication-related error with no clear match produces a generic, honest "could not complete login right now" rather than being folded into the credential-shaped message by default. And a genuine service failure or timeout — the exact case measured at 11.5 seconds — now produces a message stating PLAINLY that the password was not rejected, and to try again shortly: the one specific fact the previous single sentence never communicated, which had been quietly sending people who had done nothing wrong toward changing a password that was never actually the problem.

The fix's own account is explicit that the pre-existing anti-enumeration protection was a deliberate design constraint carried through this change, not an incidental side effect: an email address that has never been registered on the platform and an email address that exists but was paired with an incorrect password produce the exact same message under the new classification, exactly as they did before — so an outside party attempting to learn which email addresses are registered by observing which produce a different response gains nothing at all from the more detailed classification now available for OTHER failure types. A dedicated, specific test exists whose only purpose is to fail if a future change to this code accidentally breaks that one invariant.

A structured, internal log now records each authentication attempt's outcome with a correlation identifier, the measured latency, and the classified failure type — deliberately never the raw, provider-supplied error message itself, specifically because that raw text can echo back exactly what the caller submitted in the original request, which would turn an operational diagnostic log into an unintended record of submitted, potentially sensitive input.

Before the fix, a real, measured login attempt against Centriu Vértice took 11.5 seconds before the authentication provider itself gave up and reported a timeout — and the person attempting to log in saw the exact same message a genuinely wrong password would have produced: "Email or password incorrect." Their password was correct. After the fix, the identical kind of failure — a provider-side timeout or service disruption — produces a distinct, honest message stating specifically that the password was not rejected and inviting a retry, while an actually-wrong password, or an unrecognized email address, both continue to produce the original, deliberately ambiguous message that gives an outside observer no way to tell the two apart.

Centriu Vértice's login flow now classifies authentication failures into four honest, distinct outcomes instead of one fixed, credential-shaped message for every failure — explicitly telling someone affected by a genuine service failure or timeout that their password was not rejected — while deliberately preserving the pre-existing anti-enumeration protection that keeps a wrong password and a nonexistent account indistinguishable, and while excluding raw provider error text from internal logs.

This automation governs how Centriu Vértice's own login flow classifies and communicates authentication failures — it does not change how credentials themselves are validated, does not weaken the anti-enumeration protection for the two cases (wrong password, unrecognized account) that must stay indistinguishable by design, and is specific to a product that authenticates through an external provider capable of failing independently of the credential submitted.

Mapping every authentication failure into one fixed message is the simplest possible design and, for exactly two specific cases (a wrong password and a nonexistent account), is also the CORRECT design — those two genuinely need to stay indistinguishable. The gap is in applying that same fixed mapping to every OTHER kind of failure too, where the identical message actively misleads whoever is trying to figure out what to do next. A classification that reads the most reliable signal first, and is deliberately, testably scoped to preserve the two cases that must remain identical while being honest everywhere else, keeps the real protection without paying for it with every other kind of failure.