4.6 is questionable

[viniciusmarangoni]

The item 4.6 has the following recommendation:

"The remote endpoint implements an exponential back-off, or temporarily locks the user account, when incorrect authentication credentials are submitted an excessive number of times."

But note that if the server locks the user account after excessive attempts, it could be used as a weapon to DoS the user account. A better solution could be block only the "attacker" (maybe by its IP address), but this have the constraint that can't avoid distributed attacks. This solution is not perfect, but seems that is better than offering attackers a built-in DoS.

Maybe a better description of this item could be something like the following: "The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times."

[sushi2k]

Hi, thanks for the feedback. The problem with blocking IP addresses is that maybe a proxy/gateway might be blacklisted therefore not allowing a lot of users not to connect (e.g. external ip address of a company). An exponential delay or temporary lock out is still a good way, as you can bind it to the username and that is the only trustful peace of information you can validate on serverside. Everything else like for example an IP can be spoofed. At the end of the day it also depends on the applicaiton team and what kind of risk the business wants to accept or not. It's always about balancing convenience and security. The MASVS is therefore only a recommendation so the projects are aware of it. What they are doing with the recommendation is their decision.

[viniciusmarangoni]

Hi @sushi2k , thanks for your reply.

About the blocking by IP, it was just an example. By the way, spoofing the IP in the majority of cases will note be able because of the TCP three way handshake.

But I still conviced that blocking by will prevent a bruteforce attack, but will allow an attacker to block any user he wants. Imagine if you just cant login in your Github account because someone keeps running a bruteforce tool in Github's website. To avoid these kind of attacks, mechanisms like CAPTCHA are used.

Since the technical details of the implementation will be discussed by the team that will implement the feature, lets remember that this document will be used as a Standard. So many people will reference this document when implementing features. Maybe a more generic recommendation will avoid future problems like people saying "We are blocking the users because it is an OWASP recommendation".

[sushi2k]

Hi.

This is exactly what OWASP recommends in their cheat sheet also:

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Prevent_Brute-Force_Attacks

You are right, blocking an account is creating the risk of creating a DoS against specific user account, but still better than being open to brute force attacks. That's why it should be temporarily and not permanent (even though some banking applications do sometimes a permanent lockout after several failed login attempts, so a general approach is never working for everybody).

If temporarily account lockout is not enough, you should go for 2FA anyway, which is requirement 4.9 (and Level 2 of the MASVS). I wouldn't recommend CAPTCHAS for mobile and most of the time business doesn't want them anyway as they are painful, besides Googles reCAPTCHA.

[viniciusmarangoni]

There is a page in OWASP site that talks exaclty about blocking Brute Force attacks, and it talks about the problem of blocking an account. Look at here:

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

This page presents other countermeasures to avoid bruteforce attacks. In fact, each case shoud be handled in a different way, but I think that just recommend "blocking accounts" in a document that will be used as a Standard could be problematic. Maybe a more generic recommendation will make the reader to search for the best solution to its needs.

[sushi2k]

Ok. Can you propose a change of requirement 4.6 as Pull Request? Then we can take it from there and try to redefine. Thanks for your support.

[viniciusmarangoni]

Sure. As soon as possible I will make the pull request. Thanks.