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?
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.
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.
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.