Django-allauth: Users' email addresses can be leaked

[Flimm]

If you attempt to sign up with an email address that has already been associated with a user, you get this error message:

A user is already registered with this e-mail address.

This is a privacy leak. It is now possible for me to verify if a user is signed up to a website just by attempting to sign up with their email address. In theory, it also is possible for me to get a list of many of the email addresses of signed up users, by attempting to enumerate email addresses.

A better practise is to show a message similar to this to the user:

We have sent an email to [email protected] with further instructions.

If the user is new, then the email will contain the validation link. If not, it can contain a message like this:

Someone attempted to register a new user account on bar.com with the email address [email protected]. If this was you, and you are attempting to change your password, then please follow this link to the password reset form. If not, then you can ignore this email.

---

Another vector where users' email addresses can be leaked is through the password reset form. If you enter an invalid email address in the password reset form, you get this message:

The e-mail address is not assigned to any user account

This is a privacy leak. Again, it is now possible for to me verify if a user is signed up to a website, just by attempting to reset their password with this form.

A better practise is to show a message similar to this to the user:

We have sent an email to [email protected] with further instructions.

If the email address is valid, then the usual email is sent. If not, an email like this one should be sent:

You (or someone else) entered this email address [email protected] when trying to change the password of an account at foobar.com. However, this email address is not on our database of registered users and therefore the attempted password change has failed.

If this was not you, please ignore this email.

---

Troy Hunt has a good article on this subject, look for the subheading Username enumeration and the impact on anonymity.

[pennersr]

While this is indeed a privacy leak, it is actually common practice. For example, Dropbox and Airbnb also leak in exactly the same way.

I am afraid this is a matter where one has to outweigh privacy against usability. If you always force users to check their mailbox, your signup conversion rate is likely to drop, as these mails end up in spam boxes or users simply forget about it and move away.

So, it in fact depends on the nature of the site whether or not is okay to leak this information. For a site like AshleyMadison.com it would definitely not be okay to leak. For many other sites it may be very well acceptable.

As for allauth, I do think it is worthwhile to add support for a non-leaking strategy. But, that will have to be something configurable ...

[pennersr]

Just to add: the leak occurs in the signup page as well, depending on the settings. So to avoid that, you would need to disable unique email or allow users to signup with a username instead. So the impact is not just on the password reset page.

[ghost]

@pennersr pre-existing practice should not compromise the employment of good security practices.

Furthermore, I do not see why we need to weight privacy against usability. The change proposed by @Flimm would, in the case of sign-up, only effect those that included a typo in their e-mail that happened to conflict with an existing user. They would be led to believe an e-mail has been sent. If the e-mail had already been registered, then obviously a validation e-mail would not have been sent to the typo'd e-mail. I find the likelihood of someone entering a typo to be minimal. Therefore the usability impact is, to begin with, minimal. Furthermore, the e-mail is re-printed to the screen. That provides another opportunity for the user to validate their input. Even fewer users would miss that typo. While the alternative is to expose everyone that belongs to that website.

[pennersr]

Don't get me wrong here, I am not advocating against your reasoning or security practices. I am mainly indicating that the decisions made on this point may vary from project to project, even if that comes at the cost of security. For example, allauth offers a flow where email verification is not mandatory. Dropping support for that can make things less usable, and possibly introduce a drop in the signup conversion rate.

The fact that many major websites do leak simply shows that people are making different judgements. I don't want allauth to be too opinionated on this matter, I definitely don't want to drop the non-mandatory email verification flow.

Having said that, I do want to support a secure & leak free flow, which is why I labeled this issue as a feature request. The suggestions from @Flimm are sound ...

[pennersr]

For reference: https://uxplanet.org/most-common-log-in-problems-and-solutions-163a6209c0eb#.ew2yiyj43 -- touches on the usability vs security issue as well.

[mjnaderi]

Is this leak-free flow going to be implemented soon?

[stantond]

This would be great where an email address really is sensitive information, AshleyMadison being a clear example, but in the majority of cases the usability value gained is greater than the security value lost with the current implementation, so an explicit setting to prevent feedback on the email field feels like the right way to go, rather than changing the current default behaviour.

[koriaf]

Password reset email leakage has been already fixed (recently), but some problems are still persist:

• explanatory message is outdated now. Proposal: "The email has been sent, please check your inbox. If you didn't receive it - please check your email address and contact support" (optional about support)

About sign in page the same behaviour proposed:

• if emails must be unique and email verification is on:
  
  
  
  • if email already exists - fail silently, do not send any email to first user
  
  
  • change message from "email sent" to "email sent, if you didn't receive it please check it's correctness"
  
  
  • so if user owns the email and don't have account then it just continues the registration, if user owns this email and have account - nothing happens, if user misstyped the email - it doesn't receive anything and try again (with correct value this time), and if user tries to harvest emails - he have no information about account.
  
  
• if emails may be not unique - what to do this way? spam user by new registration request? or do nothing?
• if emails may be not unique and no email validation required - just create account and doesn't complain?
• if emails must be unique and no email validation is required - do we create account or not? I think yes: it doesn't leak any existing user's information, and if you don't require email validation then you won't trust email field anyway.

[bittner]

Should we try a PR to fix the remaining issues of this topic? Opinions may have changed on the "usability vs. security" topic, huh?

[stantond]

Allauth is hardly enabling you to access a list of registered email addresses via some unexpected means. It only allows you to confirm that an email address _that you already know_ is registered, and there are other, sensible best practice measures to take to ensure this isn't abused.

On the other hand, there really are some use cases where knowing a given email address is registered to an account is sensitive information.

Also, putting security measures in place to ensure this functionality isn't abused is not trivial for small and/or inexperienced teams.

So, could this be implemented as a configuration option, allowing the allauth users to decide if they choose slightly better UX or slightly better privacy?

[Flimm]

@pennersr is right, there is a usability/security trade-off here.

If users understand that their email address is public, (for example, if it is clearly and publicly displayed on their profile page), then there is no longer any security concerns of leaking email addresses. However, I think most websites don't publicly display their users' email addresses, and therefore most users expect their email addresses to be kept private, and therefore this behaviour is insecure in most cases. What's more, I think that many developers are not aware of this type of security vulnerability, and would choose to close the security vulnerability if it was a conscious choice. Because of all of this, I think the best way forward is to make the secure behaviour the default in django-allauth, and then allow developers to opt-in to the more usable behaviour, allowing them to make the judgement call on the security implications. I realise that this takes careful work.

[Flimm]

@stantond You said that this vulnerability only allows you to check whether an email address you already know is registered. As you say, this is in itself a security vulnerability, but it is actually worse than that. You could easily find a list of known email addresses, and iterate through that list one by one to find the users that are registered on the website. I don't know if dango-allauth's rate-limiting through ACCOUNT_LOGIN_ATTEMPTS_LIMIT applies not just to logins, but also to signups and password resets, but hopeful that would mitigate this escalated attack.

[9mido]

2342 This PR seems to address the password reset email leaks but does not address the signup email leaks. Maybe someone could add to this PR / make a separate one and follow the same type of approach for signups? However, this PR does not use a configurable setting like ACCOUNT_EMAIL_LEAK = True|False for example to give users the option to enable/disable email leaking. Like pennersr said, creating a setting to enable/disable email leaks in both the signups and password resets would be ideal. But a PR should keep in mind everything else people said above.