Hashing vs. Encrypting Passwords

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 to decide between the two.

After my last client complained bitterly about hashed passwords being a total PITA, I've started to favor encrypted passwords. But someone suggested this just isn't secure enough.

So my question is: What, exactly are the risks of encrypting passwords? Any person with the ability to steal passwords by decrypting them from the database would surely have the ability to reset them if they were hashed, no? I'm having trouble seeing where someone could cause tro开发者_Go百科uble with encrypted passwords but couldn't with hashed ones. Making it convenient for users is also important.

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.

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

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.

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.