Looking for my code to generate an encrypted form value in MVC to help prevent against form tampering?

It's on code plex now. It WILL ABSOLUTELY undergo future revisions that should be non-breaking changes.

http://mvcsecurity.codeplex.com/

The next changes will hopefully encrypt per a user specfic session so generate a more unique value that cannot be used in another user's session.

First let's describe three main password storage themes.

1. Plain text

2. Encrypted

3. Hashed

#1 is obvious. It's nothing and the least secure where the password is stored without any modification. If an attack (or other browsing eyes) see this, the secret is gone, angels lose their wings, and children cry. It's like crossing the streams in GhostBusters. You just shouldn't do it.

#2 still stores a password in some format. The problem here is greatly mitigated as the password just can't simply be read. It has to go through some routine to encrypt it and another routine to decrypt it. If an attacker gets your data, they have to know what encryption method was used and what the encryption key is. Upon login, a user's password is encrypted and compared to the stored encrypted password or the stored password is decrypted and compared to the entered password. Either way it's relatively the same thing. Here an attacker can work on finding the decryption algorithm by performing an analysis on the encrypted data. The more data and the more known information the better. Thankfully, this technique is usually bypassed for easier targets because of the complexities in a good implementation of an encryption algorithm.

A no-no here is to store the key somewhere where an attacker can easily find it, such as in the database. An encrypted portion of your web.config may be a better place. See the blog entry on how to encrypt the data in your web.config file.

#3 takes your password and runs it through an algorithm to create a theoretically unreversible 'hash' of your password which is generally an alphanumeric string. You cannot 'decrypt' this. Upon login, the user's password they enter is hashed as well. This resulting hash is compared to the hash in the database. If they match - hooray! There is no password stored to decrypt. However, a weakness with hashes is that rainbow tables exist to help the attacker determine the password. A rainbow table is a precomputed huge table of hashes and the data for them. It's basically a database of hashes and the resulting plaintext used to create that hash. A password such as 'hello' may hash to 813HAB1C5914ED. The attacker simply needs to loook up 813HAB1C5914ED in the rainbow table and see it maps to 'hello' and the password is now known.

Enter in salts. A salt is an additional value added to your encryped or hashed value that specifies some random (or not random) sequence of bytes used an an input to your encryption or hash function. These bytes are readily available on the output hash so it may make you wonder whats the use of it, if its plainly available?

Well, without a hash, an attacker can pre-computer hashes/values with what's called a rainbow table. If you add some salt onto this, this means an attacker cannot use a pre-existing rainbow table to lookup what this hash value it. Your salt meants this new table would have to be completely regenerated which would take quite a while and quite a bit of computational power.

Thats the use of using a salt. IF someone steals your password hashes and they each use a different salt it means the attacker will have a whole lot of work on their end in generating new hashes to compare to your salted hash.