Fulfilling more OWASP requirements

Suggested Timeouts

The following timeouts are suggested, but any value will do as long as it severely impacts both vertical and horizontal brute force attacks.

• One failed attempt: At least 5 seconds
• Two failed attempts: At least 15 seconds
• Three failed attempts: At least 45 seconds

This would require the datetime of the last (failed?) login attempt to be in the RequestCounts record.

IMHO this does not add much security: when blocking duration for 15 minutes after 10 attempts per ip address one cam make a failed attempt every 90 seconds. So it will only help to slow down the first 10 attempts.

Distributed Brute Force

If in case of a distributed brute force, the application should monitor the total number of failed authentication attempts per minute, and have a configurable threshold above which the authentication system automatically injects a configurable 45+ second delay between authentication attempts. This will make all but the largest distributed brute force attempt infeasible, even when looking for a single account with a well known password.

Shoud this be done for all login from anywhere? Or per ip address? (that is already covered under "Suggested timeouts").

Lockouts

Lockouts are counter-productive if implemented badly.

In general, the threshold governor (see above) should be implemented to prevent any one IP address monopolizing authentication CPU, network, and IO resources. If necessary, such as for compliance with a national security standard, a configurable soft lockout of approximately 15-30 minutes should apply, with an error message stating the reason and when the account will become active again.

The default for username lockout has been adapted (v0.1).

Ensure any lockout mechanism protects against both same username, many passwords and many usernames and same password attacks. This can only be done using the threshold governor approach as shown above.

This would require another kind of RequestCounts. A problem is that one should not store unhashed passwords. For password hashing nowadays substantial hash calculation times are required and each hash shoult have a different salt, rendering it useless for lookup without the user name. A solution may be to weaken the hashing requirements but only store passwords from invalid logins for a short time and remove them when the next attempt succeeded, or move them to long term storage but then the password may never be used again. But some users may already be using it, and we can not find them by the password or its weak hash only.

Guarding more Paths

Applications implementing their own authentication systems should consider a threshold governor to prevent the over-use of the following paths:

• Account registration processes (if any)
• Primary authentication path
• Step up authentication (such as two factor tokens)
• Password change**
• Password resets**

(**Low value systems only - Most medium and all high value systems should not be using passwords, and thus do not possess password reset capabilities)

Quotations are from https://www.owasp.org/index.php/Guide_to_Authentication