[plug] [OT] Question about "password reset" links and hashes

[Tim]

I'm thinking about implementing a password reset system for an app I'm
writing. Obviously I could take a password reset request, then create
a new unique token, store it in the database with an expiry, and when
they click the link verify the token exists and is valid, then allow
reset.

However, I've thought of a way that doesn't require storing this
token, but could potentially have security risks associated with it.
I'm wondering what others think.

Basically, you take the current date (say Ymd format, 20110527),
append it like a salt to the already hashed password, and hash that
string a few times. e.g. in php

sha1(sha1(date("Ymd").'encryptedpassword'));

Then to verify if the password reset link is valid, you just do the
same (with the current date) and if they match, change the password.
Once the password has been changed, the hash will not match, so the
link is invalid. Once the day changes (so if you use it just before
midnight, you have to be quick), the hash will no longer match.

To get the hash of the password, you need to first reverse the hash
(md5/sha1) with rainbow tables, do it again X times (you can loop the
number of times to hash it), and finally you'll have a string like
"20110527$6$6j5B7/FtjRH2MD$KJpoT4rwxmHTw" and still need to break
whatever hash was used for that.

To me it feels safe and easy. No extra database writes, however it
does mean your webapp needs access to the hashed password[1].

Tim
[1] LDAP for example hides the hashed password by default, and you
change the password through LDAP calls, never revealing the original
hashed password.

-- 
Timothy White - Somewhere in Australia