10

We're developing a new login screen for our system, we have a couple of million users and we're thinking about what to disclose to the user.

We currently:

  • Let the user know that the email or password was wrong, basically by saying: "Username or password did not match"
  • If they tried to login on an email that exists with wrong password 5 times, we lock them out for 60 minutes.
  • On the registration page however, we "leak" user data by letting user know if email already is registered.

We're thinking about letting the user know if the email did not exist, because "Google and Microsoft does the same". We're already leaking user data on registration page, so why not help users on login screen?

Feels like answer is ambiguous, this old thread basically says Google does this because everyone has Google. How should be handle it, with a couple of million users?

petur
  • 201
  • 1
  • 5
  • 2
    Google and Microsoft use their own IdP for user authentication that use many parameters to detect fraudulent sign-in attempts and account theft. If you can implement that level of detection, revealing the existence of the user will become safer for you as well. – defalt Feb 17 '23 at 15:40
  • 8
    Side question: for the five wrong attempts, lock _who_ out? Just that particular connection/session? Anybody from accessing/logging in as that user? Note that in the latter case, it makes it trivial for attackers to perform a denial of service attack on your users. – Clockwork-Muse Feb 18 '23 at 05:06
  • 3
    Don't lock them out after only 5 attempts. That is just annoying, and many legitimate users could want to try a lot more attempts than that. Brute forcing a login requires millions/trillions of attempts, so you could do something like lock users out for an hour after 100 attempts, and that would be just as secure while not annoying anyone. Or preferably, you could have login wait time increase by 100 milliseconds or something with each failed login attempt and never actually lock anyone out entirely. – kloddant Feb 18 '23 at 17:19
  • 2
    Does this answer your question? ["Username and/or Password Invalid" - Why do websites show this kind of message instead of informing the user which one was wrong?](https://security.stackexchange.com/questions/17816/username-and-or-password-invalid-why-do-websites-show-this-kind-of-message-i) Also, https://security.stackexchange.com/questions/32411 and https://security.stackexchange.com/questions/115299 and https://security.stackexchange.com/questions/177586 and probably many others. – IMSoP Feb 18 '23 at 17:48
  • 2
    You could change the registration form to not disclose information, say by letting users complete the form and give them feedback as for a new mail-address through the web site, but then send them a mail saying they already have an account and pointing them to the password reset page. – Nobody Feb 18 '23 at 19:58
  • @kloddant Another common option is to require a CAPTCHA for every attempt after 3-5 failed logins. – user71659 Feb 18 '23 at 21:15
  • @Nobody Im agreed with this - also doubles as email verification at the same time, and you can word it as such on the “success page”. Zero information leaked. Facebook does this - they briefly switched to a very lax alternative, before switching back again. – Moo Feb 19 '23 at 03:57

2 Answers2

8

I work for a medium size financial company with close to a hundred thousand clients and we decided a long time ago that trying to hide the fact that an email is already in our database futile and counterproductive. As you said, the registration page says it all. It's pointless to have a different part of your UI behave as if it's not the case.

As a bare minimum you could add a CAPTCHA prompt for registration and logging in, so that hackers couldn't enumerate all the users automatically. This is what most serious companies nowadays do.

Artem S. Tashkinov
  • 2,217
  • 6
  • 17
5

Usually, the less information you give the attacker, the better. Having a generic "username or password incorrect" gives the lowest amount of information while still informing the user that something is wrong, and he can figure out which one.

Pairing this with rate-limiting reduces the amount of usernames the attackers can try before being throttled (or just receiving an "username or password incorrect" without your system even looking at the password). If they don't currently have a list of users, they will have to build it from the registration page on your site, and it takes more time than just trying to login and being informed that the email isn't registered. Pair the registration page with a CAPTCHA and you make their job even harder.

The idea is not to be bullet proof, but to increase the attacker cost. Using generic messages, rate limit and CAPTCHA puts three speed bumps on the way, and may discourage some attackers from even beginning to attack your server. It surely won't stop an attacker dedicated to breach your server, but will make his life harder.

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
  • 5
    What you write is all true but it is missing the counter point. Giving the user less information makes it harder and more annoying for a legitimate user who misstyped or forgot their password to figure out what went wrong. You need to balance the two requirements against each other. – quarague Feb 18 '23 at 15:55
  • 1
    "receiving an 'username or password incorrect' without your system even looking at the password" - Please don't do this. Use a different error message. – 9072997 Feb 18 '23 at 19:51
  • @9072997 I agree. Pretending that being locked out means the password is wrong won't have much impact on an attacker, who can easily test for that, but it is going to significantly confuse and alienate legitimate users. Don't do that. – Solomon Ucko Feb 18 '23 at 21:05
  • You don't want a user that are sending 10 or more requests *per second* to have any clue if he is having the correct password or not. That behavior is expected from bots, not users mistyping passwords. – ThoriumBR Feb 19 '23 at 00:52
  • @quarague the amount of users that may mistype their email on a non-masked field is way less than users mistyping its password on a masked field, and less than the number of attackers bruteforcing a password. So the balance is well on the "give less information" side. – ThoriumBR Feb 19 '23 at 00:54