Password reset token safety

[Alex Toussaint]

Hello,

I'd like to discuss about Django's password reset token functionality.

I've been able, with a simple Python script, from having read-only access to my Django webserver to a full read-write by crafting a reset token.

Isn't it one of the main goals of hashing passwords ? Protecting from attackers having read only access to the database ?

The only "Unpredictable" data that can be needed if the attacker's  last database access is old is the last_login, which can be very easily bypassed with a simple script bruteforce (as I did here)

I would like to know, is there an other way the password reset mechanism could work that wouldn't enable such problem ? I haven't found one alone.

[Florian Apolloner]

Hi there,

On Wednesday, November 7, 2018 at 10:22:06 PM UTC+1, Alex Toussaint wrote:

I've been able, with a simple Python script, from having read-only access to my Django webserver to a full read-write by crafting a reset token.

To be honest that script is weird at best; if you have access to the password hash, you will most likely also have access to the last_login -- so why bruteforce it at all? And yes it is absolutely expected to be able to generate password reset tokens if you know the SECRET_KEY (!!!), the password hash, last_login & id.

Isn't it one of the main goals of hashing passwords ? Protecting from attackers having read only access to the database ?

No, the main goal of hashing passwords is not leaking the __original__ password. It also protects against attackers with read only access to the database as long as the hash functions are sufficiently good (you can always try to bruteforce the password).

Cheers,

Florian

[Tom Forbes]

Would you consider the secret key to not be unpredictable?

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/96fd4144-450e-4d9a-ab7d-eb308339056c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Bennett]

SECRET_KEY is the closest thing Django has to a “root password”. That’s why we emphasize keeping it secret — someone who knows your SECRET_KEY can effectively do anything to your site anyway. For example, they could produce valid session cookies for any user, and then just hop in the admin interface.

So any attack based on “assume you know the SECRET_KEY” is already going to be able to do anything, just like anything that says “assume you know the server’s root password” can do anything. 

[Alex Toussaint]

The attacker can have access to the password hash but no longer to the last login. if that same attacker is exploiting a vulnerability that gets patched just after (ex. Heartbleed) or has view on past data (ex. backups)

But if you can anyway craft a valid session cookie with the secret key (Which I didn't knew), this is totally useless.

Thanks you for the clarification !

Alex

[Florian Apolloner]

Hi,

On Thursday, November 8, 2018 at 8:12:51 AM UTC+1, Alex Toussaint wrote:

The attacker can have access to the password hash but no longer to the last login. if that same attacker is exploiting a vulnerability that gets patched just after (ex. Heartbleed) or has view on past data (ex. backups)

After patching a vulernability like Heartbleed one needs to rotate all leaked secrets (if in doubt, that means all); this includes the SECRET_KEY which immediately invalidates all tokens and logs out all users.

Cheers,

Florian