On my website I have a password reset page that users can use if they have forgotten their password. On this page they can enter their username or their email address and hit "reset" which will send them a link to reset their password.

If they have entered an incorrect username or email, should I let them know that it does not exist in our system, or is that a security risk?

  • 10
    You may find many of the aspects helpful that were discussed in answering the question Generic error message for wrong password or username - is this really helpful?.
    – user27909
    Jul 11, 2014 at 11:49
  • 1
    do NOT let them know which was entered incorrectly, it allows an attacker find out whether the username exists or not.
    – micb
    Jul 11, 2014 at 13:30
  • @micb Read the linked message above. An attacker could just attempt to create an account with the username, and easily learn if it has already been used.
    – apnorton
    Jul 12, 2014 at 19:27

5 Answers 5


The answer is generally it depends. This is really based on the security of your system.

Users can create new accounts without restriction

If so, it is kind of meaningless to not tell them. You can't have intersecting usernames or email addresses, so you have to inform a new user if their username or email has already been used. An attacker would then be able to obtain the usernames and emails by attacking the new user registration system. Giving them a similar venue to attack in the forgot password section does not harm your security any because the method just exists elsewhere. Just make sure that the restrictions you use in the registration system are the same as the restrictions for requesting a password (that is whatever anti-spam system you use).

Users cannot create new accounts without restriction

Consider an invite only system. The only way you are allowed to register is if someone has authorized it. This could be an instance where an administrator sets your initial username, email, and password (potentially manually). This system would allow you to gain security by not telling users if their entered information is correct or not. Usernames and emails could then be treated as a weakly guarded secret.


Note that this is a hit to usability. If someone mistypes their email address, they may not notice that they did. Emails from websites don't always come through immediately, so a user could be waiting for an email that never comes.


There is an old tradition of not distinguishing between "that username does not exist" and "that username exists but the password is wrong". It comes from older times, when both attackers and defenders were new at the job, and the context was different. At that time, the attacker was "outside" and he wanted to guess a username+password pair in order to enter the mainframe. At that time, passwords were even poorer than nowadays, and it was believed that keeping user names secret would substantially help ("the attacker will never guess that we have a user named 'smith' !").

An interesting reading is this description of the 1988 "Morris" worm. That beast took down the whole Internet (it was smaller than nowadays) by the sheer bandwidth consumed by all the worm instances madly replicating without control. The worm could enter systems through various methods, one of which being password cracking. Interestingly, the worm first collects account names from various sources, including ".forward" files, then (and only then) tries a dictionary of 432 words. This illustrates two points:

  • Account names are not secret. They don't exist only on the target system; they can also be inferred from various data elements on other machines, including (in modern times) SSH config files, address books,...

  • Back in 1988 they were really bad at choosing strong passwords.

Times have changed. In particular, as others have pointed out, many modern systems allow for automatic registration: anybody can try to log in, and see for himself whether a given account name is "free" or not. A lot of other target systems allow for account name collection (e.g. Web forums may use the contributor's pseudo as account name). This makes reliance on the secrecy of user names flimsier than ever. On the other hand, one may hope that average users now choose stronger passwords (thinking otherwise would be too depressing). The net effect is a change of balance: the tradition of keeping account names secret has lost most of its relevance.

However, traditions are strong forces. If your system returns the error "that username does not exist" and a different message for "your password is incorrect", then chances are that some users will feel nervous, and scandalized, and will bug you with complaints about your irresponsibility in divulging to the world at large that the name of Joe is Joe. You may argue and offer rational reasons why this is not a problem (see above); some will remain unconvinced. This is not a good thing when the users are customers; and, in any case, this consumes too much time. It is easier to maintain the old Tradition, even if it does not make actual sense; you can view it as a way to cope with the basic irrationality of human users.

  • Which one is the most likely to cause losses to your sales: the occasional paranoid user who actually wants their ID to be secret (guesses are they used a throwaway ID and email address anyway, and if they're paranoid would they even buy you anything?), or the user who isn't yet addicted to your platform, hasn't come by for a while and still can't login after trying 10 different combinations of username and password? ;) Jul 12, 2014 at 3:08
  • 4
    @SteveDL: Whichever of the two tells his friends about his poor experience.
    – Ben Voigt
    Jul 12, 2014 at 16:12
  • I've run interactive sites with a ton of user accounts and, although I've had users complain about lax security policies, this concern has not been among them. However, what has happened much more frequently is users complaining about having trouble accessing their accounts, usually when typing in the wrong email and/or username when trying to access a password reset link. Password reset is confusing even if designed to favor user experience over paranoia. IMHO there is never any reason to obscure usernames in this context. Emails are more concern because they are usually more private.
    – cazort
    Nov 18, 2021 at 20:19

No, you should not let them know if the username doesn't exist as it would let an attacker discover account names which they could then attempt to crack. If you send a generic "A reset email has been sent, please check your inbox." even when the account doesn't exist an attacker gains gives nothing from trying.

  • Couldn't an attacker just find out if the username exists by going to the "sign up" page? Signup validation would fail if an account with the same email already exists. If so, why not just be up front on the password reset page?
    – Turgs
    Jul 18, 2014 at 12:47
  • 2
    Why should it fail? The system should say "Thank you! A verification link will be sent to this address, we hope you enjoy our site." The system will send an account activation link to the email address if it doesn't exist, and a warning/re-activation link if it does.
    – GdD
    Jul 18, 2014 at 12:51
  • Maybe I'm missing something. So following a signup.. you'd always have to have an activation link! Going down this line, you wouldn't be able to allow the user to start using the system immediately. For a "genuine" user, they'd signup and have to confirm their genuineness before they can start doing anything with the site. This is a pretty big consideration and trade-off between user experience and user privacy.
    – Turgs
    Jul 18, 2014 at 13:18
  • 1
    It's a pretty standard practice to send an activation link these days, if the user is legit it takes an extra minute. Of course it may not be necessary depending on your risk appetite.
    – GdD
    Jul 18, 2014 at 13:28

What matters the most in terms of security is what does an attacker gain from knowing whether a specific ID or email address has an account with your site?

For instance, if you're doing any kind of business that can be seen as a privacy issue, or whether accounts on your site can be used to spend money or have any intrinsic value (in other words whether I can gain something from phishing your site). Some sites don't have this kind of issue, for instance a micro-blogging platform or OSN would display your ID on your page anyway, so letting a user know they typed an unexisting ID can be useful.

From a usability perspective, not telling your user if their ID exists is disastrous. Any website that uses IDs should at least confirm an ID (IDs are specific to your site so they don't provide spammers much information). Not telling your user the email address also is a terrible idea: they need to retype every possible password they've used for each of their email addresses.

Ask yourself how often your users visit your website. A low frequency of visits will greatly amplify usability issues, to the point where you might want to enable one-time passwords sent via text or email instead of a traditional login form, for anyone connecting only a few times a year.

For instance, I have two different addresses at work, multiple passwords for different subsystems and an idiotic password reset policy, on top of which I have my personal email address and a ton of different passwords. It can take tens of attempts to find the right email/password combination for a site I don't often go to.

As pointed out by @William Forcier, you can gain knowledge of whether an email is in use by several means:

  • account creation form
  • login form
  • forgotten password form

You could still deploy different defenses for each form though. If you decide that you should absolutely hide email addresses, then you can just block/complicate (CAPTCHAs) account creation to a specific IP address after a too large number of creations. You'll probably need a mechanism to protect against spammy accounts anyway (but remember not to ruin the life of your actual users by unusable solutions, for instance systematically serving CAPTCHAs).

  • You can also consider emailing clients when someone tries to connect to their account or to create an account with their email address, to let them know something happened and warn them to be particularly wary of phishing emails in the near future. Jul 11, 2014 at 19:39
  • Excellent answer. This really details the usability-security struggle that goes on depending on the expected security level of the system. Not sure about the email thing though. It seems like it would allow attacker to use your server to spam your users with warning messages. Jul 11, 2014 at 19:57
  • Not necessarily. Firstly you should have blocked the person who attempts to connect on the user's account, so there'd be a bound on the amount of daily email. You could then look into sending only digests (i.e. if you have failed connection attempts, wait until blocking an IP before you send the first email). It's less of a problem / more interesting when your site uses user IDs that can be changed (but that's not the norm any more is it?). Jul 12, 2014 at 3:02

One aspect I have not seen mentioned is the fact that many login difficulties arise because a user's preferred name was taken before he tried to register for a given site. If "JSmith" tries to log in and can't, what he really wants to know is not whether the site has an account named "JSmith", but rather whether the site has an account for him named JSmith. If the site has some public information associated with users (e.g. an avatar picture), and allows such information to be freely queried, then it may be helpful to not only indicate whether an account exists for JSmith, but also show some information associated with it. If Jack Smith always uses a cat as an avatar, and when he tries to log in under JSmith he is shown a dog, he would know that the problem isn't a forgotten password, and he should thus try one of his "fallback" user names rather than a "forgot password" link.

You must log in to answer this question.

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