You're mixing together 3 independent concepts:
1) Storing the password
2) Retrieving a password/Generating a new password
3) Getting the password to the user.
Each level has different ways you can deal with them with varying pros and
cons.
1) If a password is hashed, then nobody can get at it; it's essentially 100%
secure (or as close to 100% as one could reasonably hope for.) Therefore
you're on the right track if security is your #1 concern. If usablility is
your #1 concern then perhaps this is not the best way. It depends on your
requirements.
2) If you have code that can retrieve a password, that can be useful and
user friendly. Or code that can generate a new password is a more secure
alternative that's slightly less user friendly because then the user has to
remember a new password or reset it to a more memorable password, etc.
3) How to get the user their password is another matter. Emailing it to
them is user friendly & easy, but certainly not the most secure option. A
more secure option is to have one or more secret question and answer pairs
that the user must answer correctly as an alternate way to be authenticated.
Biometrics are even more secure, but expensive & such.
You can combine the above techniques in a variety of ways to meet your ideal
tolerance of risk vs. usability.
--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net
"Showjumper" <dfgkjhdf> wrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
A question regarding forgotten passwords - As i understand it, it is best
and most secure to use a 1 way hash+salt to store passwwords, and then if
the user has forgotten the password, generate a new password and then
email to them. What i dont understand how that is any more secure than
using a reversible encryption to store the password which would allow
decrypting and then emailing it to the user. In both cases, an email is
still sent w/ a password.
Thanks
Ashok
