Rule 1: Use a Modern Hash Algorithm (bcrypt, PBKDF2, scrypt)
Rule 2a: Use a Long Cryptographically Random Per-User Salt
Rule 2b: Have an additional 'system' salt that is a fixed value for the entire system and it's not stored in the database (better hide it in the source code)
That cheat sheet seems to have been written on the assumption that you're rolling your own, which is not a great idea. If you use Bcrypt, it handles salting for you, and you don't have to iterate it, since it has a tuneable work factor that you can tweak to make it faster or slower as your needs and Moore's Law dictate.
Regarding Rule 2b, why did the author keep repeating "store the salt in the database along with the key". Why would you want to do this? A cracker would have access to your hash and your salt. Wouldn't it be trivial for him to append the salt and then do a regular old lookup table on common passwords?
At least if the salt is within the source code, it's hidden from plain view. Or did I miss something?
The salt does not need to be hidden. First of all, it needs to be unique per hashed information (password), so you cannot store it in code. Second, its purpose is to force any attacker trying to use a lookup tables to calculate one lookup table per password.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
Edit: also, instead of using a "system salt", why not use an HMAC to replace hash function?
Rule 1: Use a Modern Hash Algorithm (bcrypt, PBKDF2, scrypt)
Rule 2a: Use a Long Cryptographically Random Per-User Salt
Rule 2b: Have an additional 'system' salt that is a fixed value for the entire system and it's not stored in the database (better hide it in the source code)
Rule 3: Iterate the hash
Source: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
------
For ASP.NET the only proven option for rule 1 is PBKDF2 which is builtin (http://msdn.microsoft.com/en-us/library/system.security.cryp...)