Hitesh Bagchi says: > Hi Tim, > We were faced with a similar dilemma in our app. This is finally what we did : > 1. We used MD5 hash to encrypt the password and insert it into the DB.
MD5 is considered by some to be "probably flawed". There are some known small compromises on parts of the algorithm. This is not to say it's necessarily a bad choice, but if you care, I'd consider using SHA-1 instead (although the benefit may not be worth re-implementation). A good synopsis can be found here: http://home.pacbell.net/tpanero/crypto/md5.html > 2. On login user entered password is hashed and matched with the password in the > DB. > 3. If user forgets his/her password and performs a Change Password then his/h er > password is reset. > This is what we do to reset password : > 1. On performing Change Password a 32 byte hash key is generated using the us er's > UserID and the current timestamp. The first 8 characters is sent to the user in a > mail as his new password and those 8 characters are re-hashed into a 32 byte hash > key and the user's password in the DB is updated with that value. > Hope this helps. There are a few problems with this: 1) You're going to the trouble to hash the passwords so no one can read them, then you're sending plaintext through email. It is a total security compromise to email plaintext passwords. 2) When given passwords, people will tend to either memorize them or write them down. If they're randomly generated, you're vastly increasing the chances that they'll do the former (since most people don't use a password safe). When dealing with web apps, I like to redirect people to a password change form and allow them to choose their own new password, or generate an S/KEY dictionary version. - Adam ----- Surgam, Inc. is a technology consulting firm with strong background in delivering scalable and robust enterprise web and IT applications. http://www.surgam.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>