Currently an attacker can try to break an account password by trying
to login over and over again. It would be nice to implement a
mechanism that can make guessing a user's password more difficult/take
longer to accomplish.

While a web server that fronts Roundup can be configured to limit the
number of requests per ip, But this applies to all requests not just
login requests.

Problems: rate limiting can be used as a DOS mechanism for the account

Ideas: after some number of failed attempts (settable in the tracker
config) require a captcha/problem to be solved. E.G the login
page could display (example generated using figlet -W hello):

  _              _   _         
 | |__     ___  | | | |   ___  
 | '_ \   / _ \ | | | |  / _ \ 
 | | | | |  __/ | | | | | (_) |
 |_| |_|  \___| |_| |_|  \___/ 

and request that the user type it in along with their password.

Another idea is the user enters a password and there is a delay
before the server responds if the password is a failure. Maybe

   max(delay 3*(#failure - 3) * (#failures < 3), 30)

so under 3 failures no delay, over 3 failures increasing response
delay in 3 second increments to a max of 30s. This will slow down
1000 parallel connections to crack a user account so they get 1000/30s
rather than tens/hundreds of thousands/millions in 30s. It doesn't
have the accessibility issues of a capcha like mitigation.

Questions:

Can we update a failed_login counter in the user object and use that
to trigger mitigation. When the user finally logs in should this
notify the user that there have been N failed login attempts and then
reset the counter? Do we need more than a counter, e.g. record of
attempt and time stamp??

Need to make sure that an invalid username doesn't cause an issue.

Should we send the user to the password reset page automatically upon
exceeding the threshold?

What is the result of loss of accessibility? Maybe a randomly
generated question that is screen reader accessible would work
better. E.G: "Please enter the product of 10 and 11".

Should accounts with admin access have a more aggressive policy?
Could this allow the attacker to know that they have a powerful
account?

How to handle distributed brute force where attacker tries one
password against all user accounts? See (1) for ideas.


Other notes/resources:

https://timoh6.github.io/2015/05/07/Rate-limiting-web-application-login-attempts.html

https://www.drupal.org/node/485974 - discusses using rate limiting/ip.
But also some other discussion about problems/lockouts ...

https://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication
- see parts 6 and 7 - This recommends that delay not be in delaying the
  result of the check but in the ability to trigger a check. However I
  don't see how to do this without recording source ip and throttling/
  backing off based on the source of the request.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

https://stackoverflow.com/questions/479233/what-is-the-best-distributed-brute-force-countermeasure
(1)