# Resetting passwords

**URL:** <https://www.ruby-forum.com/t/resetting-passwords/70703>\
**Category:** Rails\
**Created:** [October 2, 2006, 6:20am UTC](https://www.ruby-forum.com/t/resetting-passwords/70703 "2006-10-02T06:20:05Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![eleo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ea5d25/32.png) [@eleo](https://www.ruby-forum.com/u/eleo)\
**Post date:** [October 2, 2006, 6:20am UTC](https://www.ruby-forum.com/t/resetting-passwords/70703/1 "2006-10-02T06:20:05Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![eleo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ea5d25/32.png) [@eleo](https://www.ruby-forum.com/u/eleo)\
**Post date:** [October 2, 2006, 5:27pm UTC](https://www.ruby-forum.com/t/resetting-passwords/70703/2 "2006-10-02T17:27:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![eleo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ea5d25/32.png) [@eleo](https://www.ruby-forum.com/u/eleo)\
**Post date:** [October 2, 2006, 5:43pm UTC](https://www.ruby-forum.com/t/resetting-passwords/70703/3 "2006-10-02T17:43:20Z")

</div>

Eleo wrote:

> 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

---

<div class="post-metadata">

**Author:** ![eleo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ea5d25/32.png) [@eleo](https://www.ruby-forum.com/u/eleo)\
**Post date:** [October 4, 2006, 7:15pm UTC](https://www.ruby-forum.com/t/resetting-passwords/70703/4 "2006-10-04T19:15:00Z")

</div>

What we do at [agileXtreme.com](http://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.

* * *

Peter Wright  
removed\_email\_address@domain.invalid

Personal Blog → [http://peterwright.blogspot.com](http://peterwright.blogspot.com)  
Agile Development Blog → [http://exceeding-expectations.blogspot.com](http://exceeding-expectations.blogspot.com)