fix(core): case-fold the username before consulting the ceremony rate limiter

[wolpert]

Closes finding 3 of the full-project security audit.

The problem

UserLookup implementations resolve usernames case-insensitively — DynamoDbUserLookup lower-cases the identity key — but rateLimitedBucket passed the raw request string to CeremonyRateLimiter.tryAcquireForUsername:

if (username != null && !rateLimiter.tryAcquireForUsername(username)) {

So alice, Alice, and ALICE drew on three independent per-username budgets against one account. An 8-character username yields 256 of them, turning the 10/min allowance into roughly 2560/min.

The per-IP bucket does not compensate. It caps a single source at 30/min, but the per-username bucket exists precisely for the distributed case — many sources, one victim — and that is exactly the case the split defeated.

The fix

Case-fold (toLowerCase(Locale.ROOT)) at the call site, not inside InMemoryCeremonyRateLimiter. That way every implementation inherits the fix — including a host's shared Redis limiter, which had the same bug and no way to know it. The SPI now documents that the argument arrives folded and must be used as given rather than re-derived from a differently-cased source.

Why folding is safe even on a case-sensitive backend

Worst case, two genuinely distinct accounts share one throttle bucket — stricter, not weaker. (#5 in this series makes the JDBI backend case-insensitive too, at which point the question is moot.)

Testing

usernameBucketKeyIsCaseFoldedSoVariantsShareOneBudget() drives Alice / ALICE / aLiCe through both start ceremonies and asserts all three land on the single key alice. ./gradlew :pk-auth-core:check passes.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud