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)