Forum Moderators: DixonJones
I have a php MySQL site in which users are required to log in. I store their password in a db as a MD5 hash. I thought this would be better as users are then sure noone sees their password.
The question that arises is, what mechanism should I use for cases where they lose their password. I could use a hint, a challenge/response or email exchange so that I reset it. It is an ecommerce site so I don't really want to annoy people by bad procedures or make it too lengthy so that they have to wait too long and forget about their orders. Any opinion?
Thanks
The usual technique is for you to generate one, set it as expiring (so they get prompted to change it to something other than the value you've just sent them in plain text in an email) and email it to ther email address they gave you when they signed-up/placed the order.
That has the integrity exposure noted above (password sent in plain text), plus it falls down flat if they gave a false email address, or no longer use that ISP. Worse, if they no longer use that address and someone else does, you've just told a stranger a secret.
If your user is actively tracking an order, or they have only recently started doing business with you, then false/expired email address is unlikely.
Before you send the email, you might want to confirm in some sort of way that they are the user involved (ask for an order number?). Otherwise, I could generate a nuisance attack by pretending to be one of your users and telling you 100 times I've forgotten the password. Your user gets 100 emails all with different temporary passwords, and you look silly in their eyes.
A variant on sending a new password is to send them a one-time URL. That URL allows them to change their password, and then never works again. Ever so slightly safer than a plain text password -- if you make it long and convoluted, it stops a shoulder surfer from memorising it.
If, in the first place, you'd seeded them with a cookie containing a hashed variant of the password, you could retreive that cookie and use it as partial verification that they are likely to be the person they say they are. But that only works from the same machine, and same browser, and only if they haven't deleted cookies.
Uniquely and accurately identifying users isn't easy, and it's more of an art than a science. You need to get close enough so that you don't compromise your business or your users.
Good luck!
That has the integrity exposure noted above (password sent in plain text), plus it falls down flat if they gave a false email address, or no longer use that ISP. Worse, if they no longer use that address and someone else does, you've just told a stranger a secret.
I actually generate their password for them the first time and send it to their email address. That way, if anyone ever logs in, I know that I have their email address correct. It cuts down on the fake email addresses. I remove all the ones that bounce. Sending new passwords to that address is no worse, really.
It doesn't cure the fact that some people's email addresses change, but it helps a bit.
