Nowhere in the code did we decrypt the password. In fact, the password is never stored anywhere. We always worked with the hash of the password. Here are the important points to take away from this recipe:

• Never use the Random class in C# to generate your salt. Always use the RNGCryptoServiceProvider class.
• Never reuse the same salt in your code. So don't create a constant with your salt and use it to salt all the passwords in your system.
• Never tell the user that the password is incorrect if the password didn't match. Also, never tell the user that they entered an incorrect username. This prevents someone trying to compromise the system after discovering that they got one of the two login credentials correct. Rather, if either the username or password has been entered incorrectly, notify the user that their login credentials are incorrect. This could mean that either the username or password (or both) has been entered incorrectly.
• You can't get the passwords from the hash or salt stored in the database. Therefore, if the database was compromised, the password data stored within it would not be at risk. The encryption of the user's password is a one-way operation, meaning that it can never be decrypted. Also important to note is that, even if the source code was compromised and stolen by someone with malicious intent, you would not be able to use the code to decipher the encrypted data in the database.
• Combine the previous methods with a strong password policy (because even in 2016, there are still users that think using 'l3tm31n' for a password is good enough), and you have a very good password encryption routine.

When we look at the user access table, the correct way to store user credentials would look something like this:

The salt and hash are stored alongside the username, and are secure because they can't be decrypted to expose the actual password.