Decryption of Encrypted Password

Aaaa! Not again! I don't understand what's wrong with the authors of all such questions on the hash (or passwords).

The cryptographic hash function is not designed to be "decrypted"!

This is a one-way function. Reversing it (finding argument value by image) is infeasible. When a cryptographic hash function is used, such reversing (call it "decryption", does not matter) is never needed; just the opposite: it is required to make it infeasible.

Please see:
http://en.wikipedia.org/wiki/Cryptographic_hash_function[^].

If you need encryption and decryption, use encryption algorithms.

[EDIT #1]

Ah, this is related to passwords?! Please think thoroughly: why do you think "decryption" could ever be needed for authentication or any other password-related purpose? It is never needed, because you never need to store a password. The idea is so obvious: you store only the hash function of a password, calculate the same hash during authentication and compare hash with hash. Never a password with password. This way, only one person in the world knows her/his own password. It would be so bad in anyone else knew. Isn't that reasonable and simple?

[EDIT #2]

Please see also my recent answer: storing password value int sql server with secure way[^].

[EDIT #3]

As to the encryption algorithms, with .NET you have a decent choice:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.asymmetricalgorithm[^],
http://msdn.microsoft.com/en-us/library/system.security.cryptography.symmetricalgorithm[^].

For passwords, I would still recommend cryptographic hash functions, as I already explained.

Wow,

—SA

Well AFAIK, you cannot reverse the hashed string - the algorithm is designed so it's impossible.

If you are verifying the password that a user entered the usual technique is to hash it and then compare it to the hashed version in the database.

This is how you could verify a usered entered table

SELECT password_field FROM mytable WHERE password_field=pwdencrypt(userEnteredValue)