forgot password issue

[Nibbler]

As far as I can tell, this allows anyone to arbitrarily reset the password of anyone they want if they know their email address. Is this intended behaviour ?

[Joachim Müller]

Not in the first place, that's just the drawback of the feature together with md5-encryption. We should add a switch to config that says "enable 'forgot my password'" feature, with a help icon saying that the drawback of this helpfull feature is that some stupid kid might reset your password. I'll volunteer to add this switch if you agree (I thought we already had it).

Joachim

[nol33t]

just some thoughts: there could be an extra step which would be to send a mail to the email adress specified asking to confirm if you want to reset the password?
with a link which would really do the reset then
I didn't test that feature in 1.4, so i don't know exactly what the cinematic is & what i'm talkin' about, i'm just figuring it's not the way it actually works if Nibbler pointed the actual feature as an issue

-matt-

[Nibbler]

The conventional way would be to send an email to the user and get them to confirm the reset, but that would involve more work.

[Tranz]

I agree with sending the confirmation to reset.

The helpdesk application I use at work resets the password so easily that we get support tickets from people wondering who reset their account password. Without the confirmation feature, the support request will be directed at us when someone gets their password reset.

[kegobeer]

We definitely need the confirmation email, and I also suggest a username/email combination instead of just an email address.  Makes it harder for someone to just come along and request a password reset.

[nol33t]

I think the forgot_passwd.php attached ( + english.php updated ) would be a good start :

- random confirmation link and ip adress of user asking the new pass stored in ecard table
- mail sent to the email adress with the link in it
- temp entry in ecard table deleted once the new pass has been displayed to the user

if the ip adress of the user who asked for the mail and the one who try to use the confirmation link are different, it won't work ( brute force prevention )

-matt-

--edit attachement updated

[Tranz]

hmm... what if someone is on dialup and gets disconnected and get a new IP? Or many scenarios that would delay the activation of the confirmation link. I guess you could have it say that the link expired and they would have to do it again in one sitting.

[nol33t]

hmm... what if someone is on dialup and gets disconnected and get a new IP? Or many scenarios that would delay the activation of the confirmation link. I guess you could have it say that the link expired and they would have to do it again in one sitting.

if a dialup user get disconnected and IP's are different, then you would have to ask for a new confirmation link?

or just remove the ip check

--edit: just understood the expiration concept you talked about a couple of more lines would do it yea

[Tranz]

And aol users change IP addresses within the same browsing session. They make a mess of our stats.

I personally don't mind banning aol addresses but not everyone has that luxury.

[omniscientdeveloper]

Yea, I thought about what nibbler was saying. I just didn't pay it much attention, because someone would have to get into your email account to actually gain access. I guess it could be annoying though, if someone reset your password.

I guess the only real way to fix it would be to add another field in the users table, unless there is one available already, that would store the time the password reset request was made. With that and the client id, from the session, it should prevent what you guys are worried about, if it only sent a confirmation link. This way it's not tied to the user's actual ip address.

[nol33t]

I guess the only real way to fix it would be to add another field in the users table, unless there is one available already, that would store the time the password reset request was made. With that and the client id, from the session, it should prevent what you guys are worried about, if it only sent a confirmation link. This way it's not tied to the user's actual ip address.

indeed there's a date field in the ecard table that could be used for.
Omni, I don't know exactly what you meant with the client id from the session, but here's what i did ( attachement above updated ):

- suppressed the ip check

- any access to forgot_passwd.php triggers the delete of "forgot_passwd" entries in the ecard table older than 15min: forgot_passwd entries are recognizable by their recipient_name='forgot_passwd'

So now:
. a link is sent to the email adress specified: this link is a md5(time() . server process id), so totally random: 15min to break it, good luck

. i think though you should add a control when new users register: if the email he provided already belongs to another user, he's told he has to provide another one..( supra mini mod, but i know, feature freeze.. )

-matt-

[omniscientdeveloper]

$cpg_udb->client_id is a hash specific to the site and client's session. Altough, it is possible for more than 1 user to have the same client_id, a confirmation email should secure it


[edit]

Actually, the session_id could be used, since it lasts for 2 hours. This would mean that you wouldn't need that extra field. A session is automatically created for all users, which lasts 2 hours. A password request could be linked to the user's session.

[/edit]

[nol33t]

but you agree you still got to store the temporary link & email somewhere right? cause when you aren't logged in the user_id of the session = 0, so how do you find back which user wanted to change of password..

[omniscientdeveloper]

You'd have to store a special hash that noone, without the email address would know. The link, itself, could hold the user's email address or id, since that information is retrieved by the forgot password function previous to sending the email anyway.


I wouldn't store it in the ecard table though. I'd prefer it be in the session table.

[nol33t]

I think you should take a look at the modified forgot_passwd.php file i attached above then

(but yea stored on the ecard table, but entries easy to identify there - up to you -)

-matt-

--edit: looked at the session table, it's small in here..hash + info saying it's for a lost password + email adress + timestamp...

[donnoman]

why not just take the md5 hashed password, hash it with the userid, send the combined userid/passhash in an email to the user.

when they click on the email , do the same thing on the server, hash the userid against the pass hash, compare against the submitted values, if they are the same go ahead and reset, if not waggle your finger at them and say NO! NO!.

no session variables involved, and the original password or password hash never goes over the wire. Even if they know the userid, There's no way to subtract it from the hash and get the original password hash.

[nol33t]

donnoman, i started to implement your idea which seemed good to me.

However i just stopped, and tend to prefer the actual solution i proposed you guys with storing a temporary&random link, for the following reason: with your solution, if a user never changes of password, it would be then possible to brute force & guess  his user_id/pass hash ...
correct me if i'm wrong please

-matt-

[donnoman]

Your right, no time limit. so somewhere were going to have to store a time limit no matter where or how you do it.

[nol33t]

imo the "random id link" concept is important too, otherwise brute force guess could still be do-able, attacker steps being:
- ask for a new pass
- try to brute force for the time limit existing ( open source software so easy to know that kind of stuff...or you would have to make the time limit configurable )
- when the time is expired, ask for a new pass again, start the brute force again, etc..