Hashing vs. Encrypting Passwords

Question

I\'m using ASP.NET membership for a site that will serve primarily sophisticated users. I understand the difference between hashed and encrypted passwords, and I\'m trying t

Answer 1

The risk is, that encrypted passwords can be decrypted to get the plain text password.

Hashes normally can't be reversed.

Reversing an MD5 Hash

A quite common occurance is people using the same username and password on all their internet sites.

All it takes is one site password to be decrypted, and all the users sites are at risk.

While with a hash, the cracker never gets the plain text password.

Answer 2

The risk with decryptable passwords is that people use the one password for various logins and accounts, not just for the application you are dealing with.

• With an encrypted password, a stolen/decrypted password could be tried out on users' other accounts (e.g. a stolen banking password could lead to access to their email).
• With a hashed password, there is no recovery. Theft of password hashes should never easily yield usable passwords

Treat passwords as the property of the account owner. It's not yours to view, decrypt, or do other things with. If a user forgets their password, offer reset, and not retrieval.

Answer 3

As other users have said, encrypted passwords can be decrypted and are not a good idea.

If you use a standard hash technique the user who has access to your database could put in the standard md5 for "password" for example. You can solve this issue with a salted hash which takes the input string and a salt string value to create a unique hash that can not easily be replicated. Store it somewhere safe and use sha1($salt . $input). You now have a salted hash.

Answer 4

The point is that Encrypted passwords can be decrypted...so it is possible that with having access to the keys etc all the passwords could be known.

Hashed (with salt) passwords are a 1 one function so there is effectively no possible way of determining what the password was which means the user supplying the password has less to worry about. Sure someone could change the hash in where ever it is stored (e.g. database) so that user could no longer log on, but the password they had provided originally still wouldn't be known.

Edit
As you've tagged the question ASP.Net, I'd recommend using BCrypt.Net library to generate your hashes