The current implementation just uses rand() to come up with a 20char
password, which it hashes and sticks in the password_reset field.
This
field gets cleared when you login, so there's some protection against
"someone doing something dirty" there. Supposedly, it's possible to
predict what rand() would spit-out (by knowing the current time or
something -- I'm not that crypto), so it would be a better step to get
numbers from /dev/urandom, though someone else might be able to
enlighten me as to whether or not that's worth the extra hacking in
light of the above hole (b). In the presence of (a), this seems to be
the only remaining hole.
Hi, I'm new here... Dunno if I need to introduce myself or anything. :)
While the likelihood of catching email is rather unlikely (unless the
web server or client is compromised, which kind of makes this point
rather ... pointless), I'd think something like this would work:
1) User requests password reset
2) 3 unique, random values are generated, a, b, and c, which are
stored local to the webserver
3) A cookie is set on the browser with a+b hashed, with a timeout
4) special url is emailed to the user with a+c hashed used for
confirmation
5) user clicks url
6) a+c is checked, hash of a+b is generated
7) a+b is validated against cookie
8) if we're here, user is allowed to change password.
It's complicated, but IMO we're covering an edge case. However, if
the cookie is delivered flagged secure over SSL, the local machine
(or SSL) pretty much has to be compromised for this to fail.
The user DOES have to use the same browser, respond within the
timeout, and of course be able to get the email for this to work.
--
Erik Hollensbe
[EMAIL PROTECTED]
_______________________________________________
PDXRuby mailing list
[email protected]
IRC: #pdx.rb on irc.freenode.net
http://lists.pdxruby.org/mailman/listinfo/pdxruby
