Brute Force Protection

[JuKu]

Add Brute Force Protection like Fail2Ban.

https://github.com/nextcloud/server/pull/479

[PascalReintjens]

My proposal:

• Maybe we should connect the air-brake (#132) and brute-force protection, since both could use the same login queue
• There should be a minimum login time which is a little bit higher that the time than the time needed for password_hash, so that an attacker cannot guess which account names / emails exist and which not (for example PASSWORD_BCRYPT cost 12, and a minimum login time of 1000ms)
• Every failed login try from a not whitelisted ip should result in an increasing airbrake time, for example:
  • 50ms first try, 100ms second try, 200ms, 400ms, 800ms, 1600ms, 3200ms, 6400ms, 12800ms
  • every try adds former_ms*2)
  • maximum 28000ms
• The airbrake should bei implemented per subnet (to slow down large subnet bruteforce attacks)
• Login queue fields older than 30 minutes get deleted, to limit the amount of data to search through and store IPs not longer than absolutely necessary

Whenever a user tries to log in:

• Case 1: IP or subnet whitelisted
  • Account exists: password_hash user entry -> check password
  • Password okay -> Wait till minimum login time is reached: usleep() -> Login
  • Password wrong -> Wait till minimum login time is reached: usleep() -> Reply with "User or password wrong"
  • Account does not exist -> Wait till minimum login time is reached: usleep() -> Reply with "User or password wrong"
• Case 2: IP and subnet not whitelisted
  • Check in login queue whether IP exeeded login limits
  • IP hard-blocked (maximum login tries - for example 9): instantly return a "Please try later" reply
  • IP soft-blocked (multiple login tries - for example more than 3 and captcha feature activated): require captcha
    • Login try has filled out captcha -> continue
    • Login try has not filled out captcha -> return a "Please prove that you are not a bot"
  • IP not blocked or soft-blocked
    • Look into queue wether there are more tries from the same IP subnet waiting before this request in the login queue
    • While yes: usleep(1000)
    • No:
      • Account exists: password_hash user entry -> check password
      • Password okay -> Wait till minimum login time is reached: usleep() -> additionally wait full airbrake time: usleep() -> clear every queue entry from this IP for this account -> Login
      • Password wrong ->Wait till minimum login time is reached: usleep() -> additionally wait full airbrake time: usleep() -> mark try in queue as failed -> Reply with "User or password wrong"
      • Account does not exist: Wait till minimum login time is reached: usleep() -> additionally wait full airbrake time: usleep() -> mark try in queue as failed -> Reply with "User or password wrong"

This proposal theoretically allows a maximum of 432 wrong login tries per IP per day (and only 144 per IP per day without answering captchas), and immensely slows subnets trying with lots of IPs to bruteforce an account, while still managing to keep the login trouble-free and don't store large amounts of data for a longer period of time.

Whether a brute force protection similar to this can be implemented for sessions (without the airbrake part) depends on issue #136 (where we need to decide whether to use php sessions or cookie sessions)