Implement login throttling against brute force attacks

[dboehmer]

Web clients shouldn't be able to probe many passwords fast.

• maybe slow down login attempts by waiting before sending the reply to the client
• maybe have a timeout period when requests are replied to but the login form isn't shown and login always fails

Timeouts could be a fixed 1 seconds for every login and an increasing timeout for failed logins.

Accounting could consider the following factors:

• browser identified by User Agent string or by session cookie (probably useless against attackers)
• probed username (enables DoS attacks against user, often bypassed by probing different usernames with a common bad password)
• source IP address/network

[dboehmer]

I’d be glad to implement this but the task is more complex than it looks. How should we even attempt to implement brute-force protection?

Maybe take ½ hour to watch About Bruteforce Protection and why it isn’t easy at all on YouTube (German, automatic translation available) from MRMCD2019 conference.

@MarkusLeupold Do you have a suggestion what to do?

[MarkusLeupold]

The talk about bruteforce protection gives a very good understanding of how hard it is to really protect a system against such attacks. But it also gives us a few ideas of how to solve the problem.

CAPTCHAs are annoying for the user as well as delays and two-factor authentication. One shouldn't be required to spend a higher efford on logging in, only to make Coocook accounts safe. These techniques should only be optional for users with higher security claims.

That's why, in my opinion, the solution using device cookies seems to be the most appropriate one for our needs. Users would never come in touch with it nor feel any major delays.

[dboehmer]

We were having a real life conversation about this right now.

Current state:

• before POST /login browser needs to
  • have session cookie
  • have visited GET /login (equals CSRF token)
• device cookie
  • client gets long-living device cookie with ID as soon as it GET /login
  • successful login(s) links device cookie to username(s) in database
• login with valid device cookie for user
  • is always legitimate→can login with correct password
  • immediate response for success on first try
  • sleep( 0 + failed_24h(device cookie) )
• login requests without valid device cookie
  • limit login attempts per user
  • limit login attempts per request IP
  • limit login attempts per device cookie (attackers might discard device cookie but who knows …)
  • per default deferred response time
  • response time increases for each failed login attempt
  • sleep( 1 + failed_24h(username) + failed_24h(ip) + failed_24h(device cookie) )
  • absolute maximum per user/ip/device_cookie or sum (see formula above)→blocking
  • shadow blocking: attempts with correct password for blocked users/IPs same as wrong password

Open questions:

• problem with deferring only: long living HTTP connection for server, resource hogging
• problem with absolute blocking: overblocking, DoS chance inside (provider) NAT networks
• problem with mixed approach:
  • (increase of) response time reveals information about blocking state