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?