password recovery

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

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.

  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

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.