Opened 7 years ago

Closed 7 years ago

Last modified 4 years ago

#7723 closed (fixed)

DoS possible with django.contrib.auth.views.password_reset

Reported by: mafr Owned by: lukeplant
Component: contrib.auth Version: master
Severity: Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

The password_reset view creates a new password overwriting the existing one. Any user who knows your email address can trigger this process as often as he likes. The effect is that you can't log into your account until you changed your password.

I think the existing password should remain valid even if a reset email has been triggered. The mail should contain a token that can be used to change the password; even if multiple password reset mails are sent, any token should be usable for password reset in a certain time window.

Change History (8)

comment:1 Changed 7 years ago by garcia_marc

  • milestone set to post-1.0
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

+1 on it

comment:2 Changed 7 years ago by julien

Note that a discussion has been going on on this topic at the dev-list [1]. Those wanting to write a patch should have a look there, there's plenty of good ideas for implementation.

[1] http://groups.google.com/group/django-developers/browse_thread/thread/d478dd9079bc448c/030e5cc02fbd2522?lnk=gst&q=salt#030e5cc02fbd2522

comment:3 Changed 7 years ago by gwilson

  • milestone changed from post-1.0 to 1.0

Sounds like a bug to me, which makes it 1.0 material.

comment:4 Changed 7 years ago by lukeplant

  • Owner set to lukeplant

comment:5 Changed 7 years ago by lukeplant

  • Resolution set to fixed
  • Status changed from new to closed

(In [8162]) Fixed #7723 - implemented a secure password reset form that uses a token and prompts user for new password.

comment:6 follow-up: Changed 7 years ago by omat@…

wouldn't it be better not to use the plain user id in the url?

i don't see a security problem there but just a slight bad taste for revealing user ids.

comment:7 in reply to: ↑ 6 Changed 7 years ago by lukeplant

Replying to omat@gezgin.com:

wouldn't it be better not to use the plain user id in the url?

i don't see a security problem there but just a slight bad taste for revealing user ids.

Well:

  • It's in base36, so it's not obviously anything at all. Even if they do know that it is a user id, what could they do with that information?
  • The only person who ever sees that URL is the user themselves -- it is never public.
  • The main problem with exposing ids is if you want to migrate your data to a different system in which the primary keys are different, because you are then stuck with supporting old URLs. But in this case, the URLs are intrinsically 'use once'.
  • What is your alternative? (I'm not saying there aren't any, just that they have more problems)

comment:8 Changed 4 years ago by jacob

  • milestone 1.0 deleted

Milestone 1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top