I've unassigned this since I don't think Ken is actively working on it atm. :)

Now is there risk of DoS-type attacks here by people continuously resetting another user's password? I mean clearly we need something like this but most systems seem to just mail you your password hint so it doesn't actually reset your password. Maybe we need to email a URL that the user can go to that will reset their password and that causes a second email to be sent with a new password. That way nothing actually gets reset by anyone except the registered email holder.

Thoughts?

You could do it like Yahoo Groups. To reset a password you need to enter your birthday, zip code & country and then either your Yahoo Id to get your password, or your e-mail address to get your yahoo id mailed to you.

You could make the user input their userid and email address before emailing the new password.

edited on: 10-22 17:27

yes, we could do that. I always hate those because I can't remember which email address I gave the site in the first place but it would be a familiar solution. Plus, many sites will have settings set such that a user's email address is displayed as a link every time their user name shows up so it wouldn't exactly be hard to come by.

Reminder sent to jfitzell

Is anyone working on this request? This is probably my number one wishlist item for mantis right now. If nobody is working on it, I may try to hack together a solution, but I would prefer that someone who is more familiar with Mantis internals do it honestly...

No, nobody is actively working on it. I do think it's a good idea but the concerns raised in the bugnotes need to be addressed.

Ideally, the user would have to fail a login first, then be presented with a "Your password was incorrect. Did you forget your password?" (Update: I originally tried to make 'forgotten_password.php' an href link here, as an example of what it would look like, and Mantis ate the href link itself, another bug?)

From there, a ONE TIME (expiring) password would get emailed to their email address stored in the already-created account. If they are the valid owner of that account, they'd get the email, log in with the one-time password, and be prompted to change it (back?) to something they know and can remember.

It is VERY important that you do NOT allow the user to enter any personal information (ESPECIALLY their email address) on the Forgotten Password form, because that presents all kinds of password hijack possibilities.

In order to do this, you'll need to have a separate column to store the secondary passwords though, because if the person trying to log in was NOT the intended user, the password should still work for the valid user. Example: If I try to log in as jfitzell here, and fail, and say "Yes, email me a new password", it should go to jfitzell's account. BUT, jfitzell still remembers his password, so his ORIGINAL password should still continue to work as before. After a period of time (the standard is something like 30 minutes), the one-time password is no longer valid, and can't be used to log in.

You'll need to adapt the schema a bit to include a field for the password, and an expiry time as well. It might be useful if you're going this far, to notify the valid user that someone tried to log into their account on $date and $time as well, like some online systems do.

I'd be happy to go over any designs you'd like to implement to audit them for any potential security issues that could be introduced.

edited on: 04-09-03 14:47

This still has the problem that someone can keep sending you password change emails. shrug

That's possible with any system of this design. I get those kinds of emails all the time from my 'hacker' account at Slashdot (yes, I'm really the user 'hacker' at slashdot). I feel much more comfortable knowing that I'm getting the emails about the passwords than someone else. I can ignore them though, of course.

If someone wanted to try this 10,000 times a day, to log in as you, then you probably have bigger problems than having more email than you want. You can always find the IP of the attacking host, and block it. I'd say it happens so minimally, that it's probably not worth designing around.

hacker,
a as short period time seems to be problematic, because it might be a problem to get the mail inside this short time (account not reachable i.e.), but what do you think about to - hold the secondary password as long as the first successful login with one of the mentioned passwords?
In case of using the original password, the secondary might be hack attack.
In case of using the secondary one, it has its - one time usage - and the user gets asked to change it immediately after login.

So sounds like the implementation should be:

1. iff you fail a login attempt you get a link to send a once-only password
2. when you next try to login you get a warning something like "failed login attempted: <datetime> a once-only password was sent to you email account"
3. if you fail the login again you should not get the once-only password link (NB: the once_only link will need to have specific access checks to prevent manual URL attempts) instead you will be instructed to use either your original password, the once-only or to contact the admin. This should deal with:
   • the DoS attack scenario - you can't keeping do it
   • the worst case scenario of a a user who has forgotton original and then lost the once-only - admittedly with some inconvenience :-)
4. if you successfully login with your orignal password then the once-only is discarded
5. if you use the once-only then you are forced to enter a new password

   edited on: 04-20-03 02:59

I really need this guys.... I have users who just create another account rather than ask someone to reset the password, causing confusion and account-space pollution. I suppose I'll include instruction on the login page to email admin if they forget their password for now, maybe a hacked button if it's straightforward (since DOS isn't a concern in our private system).

As for bevindarkgun's suggestions though, I have to take exception. The major problem with once-only email would be if the message was eaten by a poorly configured SPAM filter or accidentally deleted for some reason. I think the original suggestion by jfitzell of a 2-pass method is the best for DOS prevention but again, I'm not that concerned with DOS in particular.

I hacked together my own solution to this problem ages ago. A "forgot your password?" link goes to a page which asks for username and email. If both are entered and they match an account on file then I call reset_user() on the account. Works fine and doesn't require admin intervention. I suppose a malicious user could reset somebody's password but that's not a huge concern for me as my install is not internet-accessible and I (mostly) trust my users.

This whole thing is such a common feature on various web-based apps, that I'm really surpised this bug hasn't been closed by now. Luckily I remembered my password here, otherwise I would have needed the feature just to add this comment! :/

ptelford, I don't see your patch or attached fix for this issue. Its admirable that you've fixed it, but I'm sure many of us would like to see your implementation.

(Oops, sorry about that, just testing a new button ;)

The consensus seemed to be in favor of a much more complicated solution, so I didn't offer mine. I'll try to create a diff and post it sometime tomorrow for anyone who does want to make use of my no frills solution (no time to do it right now, sorry).

Attatched (forgot_pwd.tar.gz) is the solution I hacked up at work (redone to work with CVS version). For an internal site, I didn't need to worry about DOS attacks. Also, for a company, people only have one email address, so I keyed off of the email. Basically, it works like so:

1.) User clicks on [Forgot your password?] link from login_page.php
2.) User has opportuinity to enter email address.
3.) If a matching email is found, a new password is generated, and sent to that email address.

Simple as that.

The attached archive contains a diff and two new files. I also added a new config variable to allow someone to turn the whole thing off...

edited on: 07-19-04 20:20

Is the patch from Marcello available somewhere? The attached files from his message at sourceforge are removed and it would help me a lot to have that patch :)

Thanks!

I also am interested in the "marcello-patch", sounds promising!

Fixed in CVS.