#7723 closed (fixed)
DoS possible with django.contrib.auth.views.password_reset
| Reported by: | mafr | Owned by: | Luke Plant |
|---|---|---|---|
| Component: | contrib.auth | Version: | dev |
| Severity: | Keywords: | ||
| Cc: | Triage Stage: | Design decision needed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
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 15 years ago by
| milestone: | → post-1.0 |
|---|---|
| Triage Stage: | Unreviewed → Design decision needed |
comment:2 Changed 15 years ago by
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 15 years ago by
| milestone: | post-1.0 → 1.0 |
|---|
Sounds like a bug to me, which makes it 1.0 material.
comment:4 Changed 15 years ago by
| Owner: | set to Luke Plant |
|---|
comment:5 Changed 15 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:6 follow-up: 7 Changed 15 years ago by
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 Changed 15 years ago by
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)
+1 on it