Harden login endpoint against brute force attacks

[quentinovega]

Description

The login endpoint currently returns an error after a fixed 3-second delay on failed attempts. While this slows down sequential attacks, it remains exploitable through parallel requests.

Problem

• The fixed delay does not scale against parallel brute force attempts
• No mechanism tracks repeated failures per account
• An attacker can bypass the fixed delay by sending concurrent requests

Proposed solution

Exponential backoff per account (Daikoku)

Track failed login attempts per user in PostgreSQL (two fields on the user entity):

• failed_login_attempts (Int)
• last_failed_login (Timestamp)

On failed login, increment the counter and compute the delay: 3s * 2^(attempts - 1) (3s, 6s, 12s, 24s...). Reset both fields on successful login.

PostgreSQL is already the datastore, so this is naturally shared across all Daikoku instances — no additional infrastructure needed.

Rate limiting per account

Using last_failed_login, reject any new login attempt on the same account if the previous failed attempt was less than the computed delay ago. This way, even parallel requests are blocked — the first failure sets the timestamp, and all subsequent attempts within the delay window are immediately rejected without even checking the password.

PostgreSQL is already the datastore, so this is naturally shared across all Daikoku instances — no additional infrastructure needed.

Action plan

1. Add failed_login_attempts and last_failed_login fields to the user model
2. On failed login: increment counter, store timestamp, compute and apply exponential delay
3. On successful login: reset counter and timestamp
4. Document the recommendation to configure rate limiting at the proxy level