Best practice for identity management methods with regards to confirming user existence

Question

I'm working on a new site that uses asp.net identity to register users. I'm making use of email addresses as usernames and the email address has to be confirmed before the user can log in.

I've been working according to the spec and our organisational Password Management policy. The combination of the 2 would have me give various detailed messages to a user when performing account related actions e.g.:

• When selecting "Forgotten password" for a non existing username display the message: This username does not exist.

I've been thinking that the better practice would be not to confirm nor deny whether the email address exists. For this reason I want to show the success message: "Instructions on how to proceed was sent to the email address provided" even when the user provided does not exist.

Applying this principle to other account related actions is a bit tricky, though. For instance; according to the spec when selecting Resend confirmation email for an account that is already confirmed I should show the message: "This account is already activated". That right there shows any other anonymous user that the account exists. Now, if I show the success message, then the user might sit and wait for the email, which means that I should actually send him an email. Should this email then be the usual activation email, or one that states: "Your account is already activated. Please open the site and log in."

Another issue is when registering. If I show a generic "Invalid registration attempt" message when registering with an existing account, my service desk could be flooded with calls from angry users. (OK, probably not flooded, but after the first one the service desk discovers that the user contacted them due to a generic error message for a specific and identified issue, they will request me, or any developer, to amend the error message to show the user what the problem is) Once again, though, if I show the user a message stating that the account already exists, then then we're back where we started.

Also, when a user logs in 5 times incorrectly, I'm to lock out his account. If I tell him his account is locked out, this is yet another means by which an anonymous individual can confirm whether the username exists or not.

I've looked for some literature online with guidelines regarding these interactions, but have not found much.

Answer 1

I've been thinking that the better practice would be not to confirm nor deny whether the email address exists. For this reason I want to show the success message: "Instructions on how to proceed was sent to the email address provided" even when the user provided does not exist.

Yes, this is the proper way to do it. A better message would be "If this email address exists, instructions on how to proceed was sent to the email address provided". It is more user-friendly without giving to an intruder the information whether the account exists.

Should this email then be the usual activation email, or one that states: "Your account is already activated. Please open the site and log in."

The latter.

If I show a generic "Invalid registration attempt" message when registering with an existing account, my service desk could be flooded with calls from angry users.

In this case, you should show onscreen a message "Information has been sent to the email address provided. Please follow instructions." and email to the user "Someone (perhaps you) has tried to register with this email account, but an account bound to this email address already exists."

Also, when a user logs in 5 times incorrectly, I'm to lock out his account.

This is trickier as could be used for a DoS (although, since the attacker doesn't know whether the account exists or not, he can only try email addresses at random). You need to have a second authentication method (e.g. a mobile phone number or a second email address) where you can notify the user "Your account has been locked due to 5 authentication attempts failed" and allow him to reauthenticate in some other way, perhaps with a nonce. EDIT: This should also be used for password reset.

A softer way to mitigate incorrect logins would be to deny access for 24 hours, instead of locking out the account.

Answer 2

Yes, you are correct. You could send an email in each case to the entered address detailing any success/failure and a generic response could be shown the user on the response page.

This is known as communicating via an "out of bound" channel. So you always send the email, but it is the email itself that explains the situation at hand, and the HTML page asks the user to check their email account.

See my other answer here for some more insight on this and how you could combine any user registration with forgotten password functionality.

One thing to bear in mind is that you should send the exact same response from the application, whether the account exists or not. This means the exact same HTTP headers and HTML body - not merely a response that appears the same on first glance.

Also, when a user logs in 5 times incorrectly, I'm to lock out his account.

You must also give the same response if an attacker manages to "lockout" a non-existent account. i.e. pretend access to the account with the non-existent email address has been locked.

A better approach that would also prevent any DoS attacks on a user (by another user denying access by purposefully locking an account) would be response throttling. i.e. the HTTP response is increasingly delayed, which would halt any automated password guessing attacks, but would not lock out the user.

e.g. First incorrect attempt on a username gives a one second delay. Second incorrect attempt gives two seconds. Expand this to a reasonable value for your application. e.g. a maximum of 16 seconds. Implement this across threads to prevent any parallel attacks and you will have significantly slowed an attacker without any risk of DoS on the valid user.

but after the first one the service desk discovers that the user contacted them due to a generic error message for a specific and identified issue, they will request me, or any developer, to amend the error message to show the user what the problem is

You should use a case management system (if you're not already). Simply mark these bugs as "won't implement" because they have implications on security.