Limit failed login attempts

[Mateusz-Dobrzynski]

As of now, we don't have any limits on failed login attempts recommended by OWASP A07:2021 – Identification and Authentication Failures. We should implement them to prevent brute force attacks.

TO-DO:

• Create a new database table for logging failed login attempts including:
  • Username,
  • Failed login timestamp.
• On a login attempt, make a query for failed login attempts within the last 60 seconds. If there were more than 5 failed attempts, automatically discard the request returning 429 (Too Many Requests) with a Retry-After header indicating a delay of 60 seconds.

[jakubmanczak]

Storing them is one way to do it, but this could also be done with an in-memory store, e.g. a VecDeque, that would keep a rolling window of requests without adding to the database's size. The question is whether we have the need to store all such attempts; this might become a problem for smaller disk servers (imagine the smallest DigitalOcean Droplet).

This would of course reset the window each time the server goes down, but such occurances aren't a planned part of its operation, and we're supposed to be quite resistant to that, what with all the Rust and everything.

The rolling window could hold requests of age twice as big as the cooldown request delay, since we'd need to also keep track of whether or not the delay has passed, or we could keep a separate list of clients facing temporary delay.

And rate-limiting could also be expanded to all requests, with that same rolling window for decreasing database load associated with authentication and authorization; although this time it would need to be associated with IPs, not users.

And we need to consider if we even want to associate them with users in the first place, since this could potentially be used to block accounts from re-logging in during tournaments. Maybe they need to be associated with both?

Since logging in is supposed to be rare, we could increase the work factor for logging in, in order to slow down brute-forcers (but also our own services).