#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 by , 16 years ago
| milestone: | → post-1.0 |
|---|---|
| Triage Stage: | Unreviewed → Design decision needed |
comment:2 by , 16 years ago
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 by , 16 years ago
| milestone: | post-1.0 → 1.0 |
|---|
Sounds like a bug to me, which makes it 1.0 material.
comment:4 by , 16 years ago
| Owner: | set to |
|---|
comment:5 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
follow-up: 7 comment:6 by , 16 years ago
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 by , 16 years ago
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