Password Salts
As we’ve already discussed it the “Obtaining Windows Password Hashes” article, when you set your password (using Microsoft Windows as an example), it hashes your password, stores the hash, and then discards the actual password you supplied. So when user1 sets their super secrete password to “password”, the system will hash it, and end up storing the resulting hash. The problem with the way windows generates this hash, is that it doesn’t utilize a salt. A salt would prepend an additional value to the password before it is hashed. So instead of generating a hash for “password” a hash is generated and stored for (as an example) “<domain\username>+password”. This does a few things for us. First, it immediately invalidates any pre-generated list of hashes (rainbow tables.) Secondly, since every user has a different salt, an attacker can’t generate a single rainbow table to attack every account on a system. A separate table would need to be generated for each account. The nonce combined with a strong password, and (hopefully) lack of LM hash makes using rainbow tables an increasingly costly, and decreasingly effective attack.
While Windows doesn’t salt passwords for local or domain users, it does utilize a salt when storing cached credentials. Cached credentials are used to log on domain users when they aren’t connected to the domain. The common example for this is a laptop user who is traveling. While outside of the office, they can’t contact a domain controller, so the only way for windows to verify their login is by using a local verifier. This locally stored password verifier is known as a cached credential. This cached credential is actually the password salted with the user name (and domain name where applicable.) In addition to being salted, the cached credential (or password verifier) is also hashed twice, so is actually a hash of a hash. This makes cracking the password take a significant amount of time longer then cracking the LM/NTLM hash.