In the previous article, I described a PKCS#12 container bug on Windows. During the audit of the same authentication service, we found something more subtle: a timing oracle on the login endpoint.

The principle is simple. Send a POST to /login with an email that doesn't exist: response in 2ms. Send the same POST with an email that exists but a wrong password: response in 55ms. Same status code, same body. But 53ms difference.

An attacker sending 50 requests per candidate email gets a perfectly readable bimodal histogram. No need to crack anything: they know which accounts exist.

Why the gap exists

Argon2id is a KDF (Key Derivation Function) designed to be slow. That's its job. With standard parameters — time=1, memory=64MiB, threads=4 — a call to argon2.CompareHashAndPassword takes 40 to 80ms depending on the machine.

The login handler does this:

func (h *LoginHandler) Handle(email, password string) error {
    user, err := h.repo.FindByEmail(email)
    if err != nil {
        return ErrInvalidCredentials // 1-2ms
    }

    if !argon2.CompareHashAndPassword(user.PasswordHash, password) {
        return ErrInvalidCredentials // 50-80ms
    }

    return nil
}

The problem is mechanical: if the user doesn't exist, we return immediately. If the user exists, we go through Argon2. Response time leaks account existence.

This is a classic pattern, referenced in OWASP ASVS (V2.2.1), and still present in a majority of codebases I've audited.

The fix: the dummy hash

The idea is simple: if the user doesn't exist, perform a CompareHashAndPassword anyway — against a pre-computed hash that matches nothing. The result is ignored, but the CPU time is consumed.

type LoginHandler struct {
    repo      UserRepository
    dummyHash []byte // pre-computed at startup
}

func NewLoginHandler(repo UserRepository) *LoginHandler {
    // Generate a dummy hash with the same params as the real hasher
    dummy, _ := argon2.GenerateFromPassword(
        []byte("dummy-password-never-matches"),
        argon2.DefaultParams(),
    )
    return &LoginHandler{repo: repo, dummyHash: dummy}
}

func (h *LoginHandler) Handle(email, password string) error {
    user, err := h.repo.FindByEmail(email)
    if err != nil {
        // Unknown user: still do the crypto work
        argon2.CompareHashAndPassword(h.dummyHash, []byte(password))
        return ErrInvalidCredentials
    }

    if !argon2.CompareHashAndPassword(user.PasswordHash, []byte(password)) {
        return ErrInvalidCredentials
    }

    return nil
}

Three lines added to the handler. Latency is now normalized: ~55ms whether the user exists or not. The attacker can no longer distinguish the two cases.

The param bump trap

Six months later, you follow updated OWASP recommendations. You bump memory from 64 to 128 MiB. The hasher uses the new params for the next passwords. Everything seems to work.

Except the dummy hash was computed at startup with the old params. CompareHashAndPassword on the dummy takes ~30ms (old params). On a real recent hash: ~90ms (new params). The oracle is back, subtly.

The coupling is implicit: the dummy and the hasher must use the same parameters, but nothing in the code enforces this synchronization. This is the kind of regression that passes unit tests and requires timing measurement to detect.

The robust solution

Don't hard-code the dummy params. Read them from the same config as the hasher:

func NewLoginHandler(repo UserRepository, params argon2.Params) *LoginHandler {
    dummy, _ := argon2.GenerateFromPassword(
        []byte("dummy-password-never-matches"),
        params, // same params as the real hasher
    )
    return &LoginHandler{repo: repo, dummyHash: dummy}
}

The dummy is recomputed at each service startup with the current params. If you bump params, you restart the service, the dummy follows.

For hot-reload without restart, you can use a sync.Once that resets when config changes. But in practice, changing Argon2 params requires a restart anyway (old hashes need progressive migration).

The regression test

You can write a timing test. It will be flaky by nature — timing depends on machine load. But with a wide threshold and enough iterations, it catches gross regressions:

func TestLoginTimingConsistency(t *testing.T) {
    handler := NewLoginHandler(repo, argon2.DefaultParams())

    const N = 20
    var knownDurations, unknownDurations []time.Duration

    for i := 0; i < N; i++ {
        start := time.Now()
        handler.Handle("exists@example.com", "wrong-password")
        knownDurations = append(knownDurations, time.Since(start))

        start = time.Now()
        handler.Handle("doesnotexist@example.com", "wrong-password")
        unknownDurations = append(unknownDurations, time.Since(start))
    }

    knownAvg := average(knownDurations)
    unknownAvg := average(unknownDurations)
    diff := abs(knownAvg - unknownAvg)

    // 20% threshold - wide enough to avoid flaking,
    // strict enough to catch 30ms+ deltas
    threshold := knownAvg / 5
    if diff > threshold {
        t.Fatalf("timing leak: known=%v unknown=%v diff=%v threshold=%v",
            knownAvg, unknownAvg, diff, threshold)
    }
}

Even better: a structural test that verifies the dummy hash uses the same params as the hasher. No timing, no flakiness:

func TestDummyHashUsesCurrentParams(t *testing.T) {
    params := argon2.Params{Time: 1, Memory: 128 * 1024, Threads: 4}
    handler := NewLoginHandler(repo, params)

    decoded := argon2.DecodeHash(handler.dummyHash)
    if decoded.Memory != params.Memory {
        t.Fatalf("dummy hash memory=%d, expected=%d", decoded.Memory, params.Memory)
    }
    if decoded.Time != params.Time {
        t.Fatalf("dummy hash time=%d, expected=%d", decoded.Time, params.Time)
    }
}

Conclusion

The dummy hash is a simple but fragile pattern. Its fragility comes from the implicit coupling between two configurations that must stay synchronized. Make that coupling explicit — a single source of truth for params — or it will betray you at the next bump.

The takeaway: a login endpoint's security isn't measured solely by status code and response body. Time is part of the attack surface.

Now that the login is solid — no enumeration, no timing leak — the brute force question remains. How do you handle lockout without leaking account existence? That's the subject of the next article.