PasswordResetView not validating existing emails

[SANYAM MITTAL]

PasswordResetView returns a success message for emails not in database also.

Problems Faced

1. If the user is not Registered but strongly thinks they are registered and have forgotten the password they would keep trying to get Reset email.
2. If they've typed a wrong email in PasswordResetForm. They would be expecting a reset email with reset URL but wouldn't receive any mail nor any Validation Error would be raised that wastes a lot of time of the User

Reference:
​https://github.com/django/django/blob/0f843fdd5b9b2f2307148465cd60f4e1b2befbb4/django/contrib/auth/views.py#L208

As mentioned in documentation​​https://docs.djangoproject.com/en/stable/topics/auth/default/#django.contrib.auth.views.PasswordResetView

This prevents information leaking to potential attackers

Although a potential attacker can easily get these information from Sign-Up/Register page as Validation error is raised when a Duplicate Email Address is entered during sign-up.

If there's not a Unique email Validation during Sign-up there are chances that multiple users get registered with same email (if user mistakenly types someone else's email) and Password Reset email is sent multiple times for different Users which is more risky.

Facebook, Netflix and many more also raises a Validation Error when non registered email is entered

Thanks for your time.

Sorry I don’t know the real necessity of not validating the email but this really causes confusion and wastes the User’s precious time.

[Kye Russell]

This is an intentional protection against enumeration attacks.

Kye Russell

Sent from my iPhone

On 9 Jan 2020, at 9:08 am, SANYAM MITTAL <sanyam1...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5e164f97.1c69fb81.aec39.cb9b%40mx.google.com.

[Fran Hrženjak]

FWIW, for me the question here is why isn't Django applying the same protection agains enumeration attacks on sign-up pages?

[Sanyam Mittal]

Those enumeration attacks can be also be done on Sign-up page as Sign-up page if Sign-up page uses email ID to register. Mostly Sign-up pages contains Email fields in them. Secondly there are many (majority) websites which are keeping these Validators on PasswordReset so why don't we keep that default.

Neither documentation has any suggestions on how to achieve email Validation for beginners

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/06dcb212-a2b9-4e9d-8bb7-a1cca36fc699%40googlegroups.com.

[Kye Russell]

As I recall, and correct me I’d I’m wrong, but Django’s auth package doesn’t contain user registration views. Thus while I understand your point it does not serve as justification to change this functionality in the core auth code.  

It is inherent in the functionality of a typical user registration flow that an enumeration attack be possible. If your business rules require this, there isn’t a 100% fix that doesn’t introduce its own usability issues. Your registration view should have its own rate limiting / automation detection to heavily mitigate enumeration attacks that aren’t targeted to a specific user. 

Furthermore not all web projects with a sign in functionality have public user registration. My day job project does not have registration views as access is granted via invitation only. I imagine that I am not alone. 

I am certain that in our regular external penetration testing, an enumeration attack possible on a password reset view would be flagged as an issue. This should serve as a good indicator that it is a bad idea. 

I appreciate the usability issues inherent in this decision (at work we deal with the resulting support requests almost every day) but I am still a -1 on changing the functionally as the security risk is too large in my use case, and lots of developers may not be aware of the issue at all. 

Perhaps at best it could be included as an opt-in setting. I still feel unsure about that. 

Kye Russell

Sent from my iPhone

On 9 Jan 2020, at 9:32 am, Sanyam Mittal <sanyam1...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADXzAOcwjxDUk5r%3DW0-0vEZfUmOWRWiCqKPDNp8va2pjYBKVSg%40mail.gmail.com.