password recovery

rubyonrails-talk
1

Hi there,

I am looking to implement a password recovery feature so users on my site can request a password when they forget theirs...

My passwords are one way encrypted, using a sha1 hexdigest so currently users would only see a garbled string which is not their password.

So - are there any tutorials that cover this as a walkthrough, so I can learn as I go? I've tried google, but there's so many suggestions, it's knowing which is the best etc... Also couldn't see anything that covered that on Railscasts.com

Any ideas?

Many Thanks

2

Craig Westmoreland wrote:

My passwords are one way encrypted, using a sha1 hexdigest so currently users would only see a garbled string which is not their password.

First to get some semantics out of the way: SHA1 is not an encryption it is a message digest (a.k.a. hash). The whole point if message digest is that it cannot (within reason) be reversed.

You have two options:

1. Encrypt passwords using a encryption algorithm such as AES, DES, or Blowfish, so that you can reverse them. (NOT RECOMMENDED!).

2. Give the user temporary (one-time use) password and send them that. Keep track that the password is temporary and make them reset their password immediately after logging in. (This is the safest way I know of to implement password recovery).

The reason #1 is not recommended is that you must store the keys used to perform the encryption somewhere on your server. If your database was compromised then it's highly likely that your server is compromised as well. A hacker would be able to find everything he needs to know to reverse all the passwords in the database. Secondly, as a developer you would also have the knowledge to reverse anyone's password.

I personally get very upset if any web site is ever capable of telling me what my password is. I make every effort to avoid using sites that I know are capable of this.

3
  1. Give the user temporary (one-time use) password and send them that.

Keep track that the password is temporary and make them reset their

password immediately after logging in. (This is the safest way I know of

to implement password recovery).

I would implement this slightly differently. Rather than create a temporary password, take them through the normal process and then enforce a password reset - I would create token, send them a link to a reset password page that has the token in the URL, accept a new password on that form, find a user with that token and change the password, remove the token from the user record (so it can’t be reclicked from email or hit accidentally) and redirect them (to either a login page or their profile page if you automatically log them in from the token).

To me that’s a slightly better UX flow than giving them a temporary password, login with it (knowing their browser may suggest to save the one-time password) and then ask them to reset it.

Cheers,

Andy

4

Andy Jeffries wrote:

I would implement this slightly differently. Rather than create a temporary password, take them through the normal process and then enforce a password reset - I would create token, send them a link to a reset password page that has the token in the URL, accept a new password on that form, find a user with that token and change the password, remove the token from the user record (so it can't be reclicked from email or hit accidentally) and redirect them (to either a login page or their profile page if you automatically log them in from the token).

Thanks, I like this better too. Should have thought of it myself. This would be easier for the user.

This is actually a third option too that I didn't mention because it's not quite ready for common use:

3. Eliminate username/password authentication from your site entirely. Then you don't have to worry about password recovery at all (e.g. http://stackoverflow.com).

This is the choice I made for my latest web site. However, I had the advantage that my users are software developers, as such I didn't have any qualms about asking them to use OpenID. This was hugely advantageous for me as a developer. I know longer retain any responsibility of storing private data about my users. Not even passwords. Plus, doing this allowed me to forego SSL since there is no longer any private data passing across the internet to my site.

This is also becoming a viable option for any web site. Especially when combining OpenID with authentication using Twitter, Facebook, etc. So many big providers such as Google, Microsoft, Yahoo, AOL, WordPresss and others support OpenID these days. It's getting to the point that almost everyone on "The Net" has at least one of these.