11

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?

7
  • 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
    Commented Feb 17, 2023 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. Commented Feb 18, 2023 at 5: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.
    – tklodd
    Commented Feb 18, 2023 at 17:19
  • 2
  • 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
    Commented Feb 18, 2023 at 19:58

2 Answers 2

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.

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.

5
  • 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
    Commented Feb 18, 2023 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
    Commented Feb 18, 2023 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. Commented Feb 18, 2023 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
    Commented Feb 19, 2023 at 0: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
    Commented Feb 19, 2023 at 0:54

Not the answer you're looking for? Browse other questions tagged .