Dealing with violating privacy of registered users during failed authentication

Question

We are forth and back discussing how to deal with privacy issues during failed authentication, password reset and account creation on a web application.

Let's say I am in the process of creating an account on an application and I am using an email that is already in use. If sending user feedback directly to the end-user saying "this email is already registered" the application might expose privacy sensitive information for the account using that particular email. I could for example check whether a certain person has an account on the application simply by using his/her email address during this process.

This for sure is a problem when it concerns applications dealing with sensitive content (like for example websites similar as second love or tinder).

Similar issues occur when resetting passwords or trying to log in with the wrong password. Useful user feedback seems like a must, but could be used by others to violate privacy of the already registered users.

For registering an account the problem could easily be solved by sending feedback in the line of "further instructions are sent to your email". This does not necessarily mean the account already exists. In the email could then be written that "the email has already been linked to another account" including instructions how to proceed or when the email is not yet in use we simply send a link to activate the new account that allows the user to finalize the account registration process.

Similar could be done for password reset: "further instructions are sent to the email address". This doesn't expose anything.

But for failed login attempts such solution is not particularly user friendly: "this email password combination is not recognized".

The user might wonder, did I use the wrong email address or wrong password!?

Lot's of websites simply send feedback in the line of: "we cannot find an account with that email address" or "wrong password provided".

With privacy rules/laws getting stricter every day after many scandals I wonder whether the above response is acceptable for any web application, but it seems like even the big ones (Google, Amazon, Facebook, etc) don't seem to mind and simply show that the email used is recognized.

Am I exaggerating the care for the privacy of the applications registered users? Is there some best practice or useful read on this particular topic?

EDIT: Older questions on stack-exchange and other blog posts are mostly discussing the topic of exposing user information from a security point of view. But the General Data Protection Regulation (GDPR) is kicking in soon and I am particularly interested in the privacy issue related with revealing account specific information.

Answer 1

I like how the GDPR states: "implement appropriate technical and organisational measures". Now you should take a risk based approach to define appropriate. In sensitive cases like second love this would be totally different then for a more generic service like social media. So no you are not persee exaggerating, but it does depends on the risk context, and or if the data is already available publicly. For example my github account shows my email in the commits.

The Privacy by Design principle Full Functionality – Positive-Sum, not Zero-Sum states:

Privacy is often positioned in a zero-sum manner as having to compete with other legitimate interests, design objectives, and technical capabilities, in a given domain. Privacy by Design rejects taking such an approach – it embraces legitimate non-privacy objectives and accommodates them, in an innovative positive-sum manner.

So, I like how you are trying to find a way to be both user-friendly, secure, but also respect privacy. Sounds like you might find a new innovative way, be sure to share your findings.

To be on the safe-side you could always send out the same reply that does not expose anything. You could do usability testing to see if this really an issue. Personally I think if I cannot login and immediately a reset password link is shown, that that is more user-friendly. Since this often the next step I take. If the reply is the reset password link has been sent, but if the account does not exist you send a registration email instead, that would also feel user-friendly. As I can now just signup instead. Without exposing if I already have an account to the public.

Similar you could always handle the registration process by email, this way you know the owner is the only one to know his account already existed. An email like: Hi, your email address already has an account, do you want to reset your password instead?

Now if all fails, you could ask existing users to give consent to expose that they are using the system, for the purpose to make it more user friendly. Pretty sure this is not a good idea though...

Answer 2

It's an interesting question, because I never thought of this problem, but it is indeed a privacy issue. The problem is that certain procedures actually leak information, which can even be sensitive information. To avoid this, your application would have to appear to behave in exactly the same way in every case where sensitive information might be leaked. This means that if you let the users register freely by entering an email and a password for example, then the registration process must appear to behave in the same way, whether it is successful or not. You can't have a "Thanks for registering" behavior and also a "There was some problem" behavior. You would have to consider the registration process to be always successful.

Thanks for registering! An email has been sent to you for activation, etc.

If the user is already registered, you will not actually send an activation link but you might send them a warning like "You are already registered, did you forget your password? If you didn't try to register on our website again, then somebody else might have entered your email by mistake during the registration and you can ignore this email, etc."

For logins it's not really a problem as long as for a failed login you warn the user that "the email OR the password is incorrect, please make sure both are typed correctly". I think this approach is commonly used, I've seen it around, and it's not confusing for the user.

Resetting the password after providing an email address should work in the same way: same behaviour, so you always reply with "An email with reset instructions has been sent", whether the email was actually registered or not.

WARNING. Since this is an INFOSEC community, for completeness I must warn you that "same apparent behavior" usually also includes prevention of timing attacks. Suppose somebody tries to register using a new email, and the page for successful registration takes 3 seconds to appear. Now suppose somebody tries to register using an email that already exists, and the page for successful registration (same apparent behavior) takes only 1 second to appear, because internally your application has performed different tasks (different database lookups, different kind of email sent, etc). This difference in time can actually be exploited because it leaks information. Not always timing attacks are feasible, because the difference in time might be too small or might require lots of attempts before the difference is statistically significant, and it might not be easy to mitigate. Nevertheless, I think it was worth mentioning in this case. I might be wrong, but you probably shouldn't worry about timing attacks in your specific case (might be overkill), unless the time delay is really easily noticeable without repeated attempts and you deal with very sensitive information.