For context, my web app will be used by users who don't have a strong technical background. What are the pros or cons for displaying a message like this?
Something like:
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this communityFor context, my web app will be used by users who don't have a strong technical background. What are the pros or cons for displaying a message like this?
Something like:
Possible pros:
Possible cons:
In conclusion, from a security point of view it doesn't matter whether you show that message or not. From a UX (user experience) point of view though, it might be a better idea to hide it, and maybe raise the limit to 5 or more (depending on your needs, statistics about locked users, etc.).
This looks like my bank. If I mistype the password, they warn me that my card will be blocked if I don't get it correct in the next 2 trials. And that increases my stress. I don't like that message.
I would not add that kind of message because it does not helps the user remember its password. If the user mistyped the password, they will hopefully get it correct on the next try, and if they forgot it they will get it wrong again on the next try.
For an attacker, it won't change much. Assuming they can create a user on your site, they can test themselves how many passwords they can try until they get blocked.
Most large web applications lock accounts based off of a variety of metadata, not just number of recent failed login attempts. This is because the login procedure is really about minimizing false positives (users logging as others) and false negatives (users not being able to get into their account). This can include historical login data, attacker IP and location, user agents, and even user behavior.
You might not need to spend that amount of time building an auth portal, but you are effectively building a policy that manages the same goal. In order to find out how to make the tradeoff between those two things, you have to consider:
What would be the cost of a user account compromise? What would be the cost of a user getting locked out of their account?
Then think about your lockout policy and try to determine whether any given property is making the proper tradeoff. In your case, you'll have to think about how many of your users will trigger the block with vs. without the message, and how many attackers will do the same. Personally, I doubt that with a simple trigger like "number of recent attempts" you are really going to stop any targeted attacker from learning when the threshold is. The first thing I would do if I was starting to try massive amounts of logins on a website would be to attempt it on an account I own and see if anything happened.