Resetting passwords

Can anyone think of a better way to do this?

I have passwords hashed in the user table. When a user wants to reset his or her password, they enter their registered e-mail address in the text field submit it, and then are sent a reset-confirmation e-mail containing a unique link that will reset their password and e-mail their new, random password to them.

As it is now, I've set up an entirely new table for password reset requests which contain the user id, creation date, and the unique hash for resetting the password. But to some extent this seems wasteful because after 24hrs the requests expire, and after the password is reset, the request is removed from the table. So it's like I have this table that seems necessary but never really grows and will probably never have more than a few rows at a time. Is this a good thing?

Any other way I can approach this problem?

Seems like the only information essential in that table is the unique hash. If you can find a way to generate that hash from existing keys (perhaps a hash of the old password, or a hash of login+user_id?), then you wouldn’t need this table.

Vish

Eleo wrote:

Can anyone think of a better way to do this?

I have passwords hashed in the user table. When a user wants to reset his or her password, they enter their registered e-mail address in the text field submit it, and then are sent a reset-confirmation e-mail containing a unique link that will reset their password and e-mail their new, random password to them.

As it is now, I've set up an entirely new table for password reset requests which contain the user id, creation date, and the unique hash for resetting the password. But to some extent this seems wasteful because after 24hrs the requests expire, and after the password is reset, the request is removed from the table. So it's like I have this table that seems necessary but never really grows and will probably never have more than a few rows at a time. Is this a good thing?

Well, it's not a bad thing, per se. Theoretically there's a slight performance hit due to the fact that you're either doing a join at some point or doing two table lookups, but it's so minor I wouldn't think about it.

And there's certainly nothing wrong philosophically with having a database table that stores temporary values. Think about how you can use a database table to store session data, for example. And if it makes you feel better, just think: when your app has millions of users, there'll probably be thousands resetting their passwords at any one time!

Personally, I'd just add some extra columns to the users table. But if having a separate table makes more sense to you, then go that way.

Chris

What we do at agileXtreme.com is pretty neat. We have a reset field on each user record. If a user requests to reset their password they key in their email address. We then find the user matching that, hash and salt the hash we already have of their password and send them that in an email as a reset code. All they ten have to do is go to the reset page and enter the combination of their reset code and email address (and new password of course) and they’re done. We of course match the code they enter with the field in the database, and clear that field when they are finished.

It works like a charm.

PGP.sig (186 Bytes)