This question already has an answer here:

It seems that most sites or systems will just state

Invalid username or password

As a means to not reveal usernames for use in brute force (and other) attacks. Seems like a good idea as a general rule. However, many of them you can follow the forgotten password? link and quite often you can get

This email address / username isn't registered

Should this not follow the same process and not reveal this information?

Is it just bad design practice that has become the norm?

Edit to add; I'm thinking about a secure system where the users aren't able to self register, nor should the general public have access. So it should be secured to those who have access and that's all.

marked as duplicate by D.W., SilverlightFox, Steve, WhiteWinterWolf, Xander May 30 '15 at 14: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.

  • 5
    OK, slight difference. My question is about a secure system where the general public can't register, not like Facebook et al who allow and want all and sundry on there! I'll edit to reflect this – RemarkLima May 29 '15 at 7:00
  • Arguments for systems where users ARE able to self-register: blog.codinghorror.com/the-god-login/… – user11153 May 29 '15 at 11:02
  • 1
    @RemarkLima Let's say there's a user named BobA with the password foo, and a user named BibA with the password bar. BobA wants to log in, and enters his username and password, but makes a typo when entering his username and enters BibA instead of BobA. Are you going to tell him that he entered his username incorrectly, or his password? – Ajedi32 May 29 '15 at 13:41
  • 1
    @user11153: The linked article's main point seems to be that it can be problematic to remember "which of my 10 email addresses did I use to sign up here?" I respectfully submit that that's simply a symptom of a bigger problem: why in the world do you have 10 email addresses?!? I have 3: my personal email, my work email, and a Gmail account I got back in the early beta days because a friend worked for Google, which I never use. I find it difficult to imagine why anyone would need or want 10. – Mason Wheeler May 29 '15 at 14:14
  • 1
    Related: ux.stackexchange.com/a/13523/22773 – Ajedi32 May 29 '15 at 14:17
up vote 33 down vote accepted

Yes, it is bad security practice indeed.

When using the Forgotten Password feature, the site should respond with a message: "An email has just been sent to the specified email address, if it exists and is registered within our system. Please read the email and follow the instructions."

Or simply: "Please check your email inbox for instructions on how to proceed to reset your password", since it's a safe assumption that the account reset procedure was initiated by the legitimate account owner.

EDIT: It has been pointed out that an attacker might find out whether an email address is registered in the system by trying to open an account with that address. To thwart this attack, the registration procedure must be changed too; the user should be allowed to register only after he/she verified his/her email address, as follows.

Upon entering an email address for a new registration, the site should respond with the message "An email has been sent to the email address you provided. Please read the email and follow the instructions to complete the registration, if necessary". Then the email message would contain the steps to follow to complete the registration, or a simple warning to the user if the email address was already registered.

  • 2
    I prefer the first, since most times I use this feature is not just because I can't remember my password, but I'm not 100% sure I even have an account - The first message subtly reminds you that if its not received you don't have an account, whereas the second sort of implies that the account exists and the email was sent. – Numeron May 29 '15 at 7:13
  • Thanks. Now, how about if there's a set of questions and answers to reset the password, no email involved? Do you still take them through the process on the basis that they think it's all valid? In the context that anyone trying this absolutely will have an account – RemarkLima May 29 '15 at 7:17
  • 5
    +1: I agree with this answer, however I should point out that it is often possible to determine the same/similar info by attempting to create a new account, and having the process fail or succeed. – Numeron May 29 '15 at 7:20
  • 1
    I think the safest way to do this is to bring the user towards the whole process of answering all questions and only at the end tell him/her if the procedure was successful. However, this approach 1) is not exactly user-friendly and 2) will introduce a security hole in your system if the answers, from the point of view of an attacker, are easier to guess than the password. – dr01 May 29 '15 at 7:25
  • @Numeron: good point, edited my answer to take this into account. – dr01 May 29 '15 at 7:40

There's a reason few websites follow that "security" measure: you lose usability (and users) without gaining any security.

Any website with even the smallest hint of security will enforce a limit on the amount of times you can "guess" a password OR a username, to prevent people iterating over all of the existing usernames. This limit needs to be imposed on all facets; registration, login, and password recovery.

You may be asking: "If it's so bad to give a generic error message, why do people do it?". The answer comes from the distant past, when security was young and underdeveloped. Authentication was often done offline or on a local network, which allowed attackers to brute force as fast as their processor would allow. With an unlimited number of guesses happening at a rapid pace, it was trivial to iterate over every username in existence, if the system reported that a username existed or not.

Bigger companies (Facebook, for instance) tend to have UI/UX divisions who run usability tests, showing just how many users are lost due to anti-usability security theater. But many smaller companies don't have UI/UX resources, and end up following "best practices" like this, and even stupider things like "security images".

Related reading: Disclose to user if account exists?

There are a number of issues here which need to be considered and some too often quoted misleading statement of security through obscurity.

To address the security through obscurity statements. Making something obscure does not automatically imply security through obscurity. The notion of security through obscurity refers to the practice of relying solely on the obscurity for the security. It is perfectly acceptable and in some cases even good practice to incorporate obscurity into a security control.

As an example of the differences. Consider telnet, which is inherently insecure because it sends passwords in plain text. Moving the telnet service from its standard port to some other port and believing this has addressed the security issue is security through obscurity. It has not addressed the underlying problem of plain text passwords being transmitted and relies on nobody sniffing traffic destined to that non-standard port to maintain security.

On the other hand, you might decide to move your ssh service to a non-standard port. This decision might be because you have a system which only you log into and you have noticed lots of attempts to brute force access via ssh. Moving this service to another non-standard port will reduce the number of brute force attempts against your ssh service. As you are the only one using it, it doesn't represent significant inconvenience and while it has made that service more obscure, it isn't classified as security through obscurity because moving it to another port is not the sole security protection. You have reduced your threat exposure, but you are still using all the other standard good practice you would have for an ssh service.

Obscurity in security is a common control and perfectly acceptable provided it is not the only control you are relying on.

With respect to the original question as to indicating whether email or username is valid when performing a recover password operation is a good idea, it really depends on a lot of other factors. Security controls need to be evaluated within the context they are being applied to. We have general 'best practice' guidelines, but these are just that, guidelines, not rules. In general, we do not want to provide information to attackers which they can use to assist them in their attack. However, we also need to consider the value of the resource we are protecting.

For example, I use a RSS feed reader service. For me, this is a low risk application. There is not a lot of value there for an attacker. If I forget my password and try to use the forgotten password feature and it just tells me it failed rather than telling me I had the wrong email address, then it will likely be more frustrating than necessary. It could be I had a typo in the address I entered and being told the address was wrong would really help. I know then that the problem is with what I entered. Telling me something too generic prevents me from trying to diagnose what was wrong - was it something wrong I entered, is it a problem with their server, what?

On the other hand, I probably don't want my bank using a forgotten password feature which will give additional information, such as my account name to an attacker. In this case, perhaps a message stating that the forgotten password functionality has failed and asking me to contact phone support would be more appropriate. If on the other hand, the problem is with my gmail account, I'm probably not that concerned because it is trivial to determine valid and invalid email addresses just using basic SMTP commands to the server.

The basic point is, you need to balance user experience and security. You need to understand what the threat vectors are and what the appropriate controls are for the resource being protected. There is no always should be this or that - it all comes down to the context.

Yes, it is bad practice, exactly for the reasons you state.

When I write this kind of thing, I give a generic message along the lines of "An email has been sent to this address" regardless of whether the account existed or not.

There is a mitigating factor, however, in that a hacker trying to use a form like this find out what addresses are registered will trigger emails to be sent to users whose addresses he finds. This could serve as a warning to the user. Indeed, some sites include warning messages in their emails for users to beware of a potential attack if they didn't request the reset.

This could be sufficient to dissuade hackers from trying to use the reset form to harvest addresses.

As @Ahueahuehauehua said, @dr01 answer is not user experience friendly in my opinion too.

Always remember that security through obscurity IS NOT a valid approach.

Invalid username or password simply says that username and password doesn't match, I mean, either username or password (or both) are incorrect. So, in any case, just show a message like Invalid username or password, not because of security (which is not secure at all), but because username or password or both of them, are incorrect.

The best way is to increase signin security, by best practices, and not by obscurity. Try limiting signin/signup/forgotten password re-tries. For example, limit them to 5 tries/IP/hour and also 5 tries/username/hours. Also, set a maximum tries for 24 hours (for example, 10 tries/IP/24 hours and 10 tries/username/24 hours). So, nobody can guess more that 3650 password in a year for each username.

I just want to say it again that security through obscurity is not a valid approach.

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