This question already has an answer here:

I'm doing some research on user account guessing, and wanted to ask a question about some "bad practices".

My thought is generally this is a trade-off between great user functionality/UX and security. For example, I could create a user webservice that checks if an e-mail exists, and when a user is attempting to register, I can (as a convenience) let them know that this account already exists (instead of having to go through the entire process only to find out at the end the account is taken).

In addition for a login form, telling the user 'this username/password is invalid' instead of 'that username does not exist' will help reduce the chances of an attack.

At the end of the day (for registration), my thought was the aforementioned webservice is a bad idea, but there needs to be some way to ensure the user knows that name is taken/available.

What are some techniques people do to secure this? I thought that rate-limiting service requests from a server perspective is a good idea. Is this common? For example I have some sort of means of blasting away at that webservice using a dictionary attack. After enough time, I could have a whole list of e-mail addresses that are valid and now I only need to guess passwords instead of both. But if the service is limited such that after N requests, the response slows down, or asks for a CAPTCHA, it would be harder to pull this off (now I need to use unique IP addresses, etc).

I wanted to see if my thinking was right here or if anyone could add on to this.

By the way, I noticed Microsoft does not do this! When you go to live.com, and you type in some made-up username, it tells you that username does not exist. When you try a valid username but bad password, it tells you that password is wrong! Isn't this a bad practice? What are some reasons they allow this? Because it's a popular service and getting a live e-mail address is pretty easy? Or maybe that coupled with lots of server security?

marked as duplicate by Xander, Rory Alsop Aug 1 '14 at 13:16

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

up vote 1 down vote accepted

Rate limiting is probably the only practical way to mitigate these attacks for most public-facing applications. And you're correct in that it's a security/UX tradeoff.

Given the login form example alone, "your username or password is invalid" is a more secure (exposes less information) way to present info, but most public services have other endpoints to check for usernames anyway.

The attacker can, for example:

  • check for a "user profile url" if implemented in the app (eg. /users/profile/NAME)
  • or hit the "create a new account" endpoint and get "username/email exists" info from there.
  • or create a new account and hit a (for example) "send a message to user NAME" and get info from that response.
  • etc, etc

If you add rate limiting then these attacks will take a lot longer (to the point of being impractical — depending on your user base size and rate limiting details), but in theory it's still almost always possible.


It's possible to leak zero information about accounts, but that will make the experience for actual users much more confusing.

Imagine an existing user tries to create a new account — you have to accept all the info, show an "Account created" page, detect it's a duplicate, and email the user that "you tried to create an account, but already had one".

  • Your zero information example is a little strange. If the existing user is emailed that someone tried to create an account in his/her name, that might confuse and alarm the user. Most site operators don't give away such information. A question would be, why that is. The other possibility: if the newly created user is emailed (assuming the username is the unique part and a different email was selected), then the attacker would have found valid username. This is of course mitigated, because nearly every site uses email addresses as primary keys. – Artjom B. Jul 31 '14 at 19:00
  • @ArtjomB — in this scenario the point is that the attacker would not know if the email address he tried was previously used for an account. He'd simply get the "Please check your inbox to proceed creating your account" message. And if the user himself accidentally tried to create an account, they'd get an email saying "Welcome back, you already had an account". – Joel L Jul 31 '14 at 19:06

Most of your assumptions are correct.
The general idea (as far as the user interface is concerned) is:

  • give the attacker as little information as possible
  • slow down the attacker

If people need to register you cannot avoid the error message 'This user already exists'.

If registered users need to login the generally recommended precautions are indeed:

  • Only report on an invalid combination of id/password
  • Limit the number of login attempts, then block the account. If you don't want to do that:
  • Introduce a longer delay for every attempt. Alternatively: delay every attempt. For a user logging in, 2 seconds extra is no big deal. For an attacker, it is.

You should of course also use the delay for the registration phase.

Not everyone follows recommendations ;-)

First, I'm not entirely sure what the question is, so I'm going to make some guesses.

  • Is there a trade off between security and UX? Yes. Just like the trade off between security and performance, and the trade off between performance and UX, and the trade off between any set of requirements for a system. That is the nature of requirements. If they were innately harmonious, then we'd all be paid a lot less.

You discuss a couple of potential webservices to offer different compromises for the UX/security requirements. I think you've got a couple of false premises.

  • You can completely resolve the tension through the use of federated ID. If I use a federated identity to log into your website, then you don't need to worry about duplicate names and passwords; the name is guaranteed unique, and you never see the password. You trust the identity manager/token manager to do the authentication and you rely on that.

  • You may wish to look at SQRL. You don't need to like the scheme, but I think the requirements and arguments he sets out will help you to think about the problem.

  • Security isn't a thing; you cannot measure it. Security is like beauty and exists in the eye of the beholder. You've postulated a couple of attack models based on one pattern of brute force password guessing. Is that a realistic model for the problem you're trying to solve? Take a step back and consider what you are trying to protect, the potential threat models, and do the risk analysis. Risk analysis will get you to a far better security model and security implementation.

Not the answer you're looking for? Browse other questions tagged or ask your own question.