Password storage sits in domain 1.4. On paper it is three vocabulary words: hashing, salting and key stretching. People learn all three definitions and lose the points anyway. The exam almost never asks what salting is. It describes an attack and asks what you should have done about it. Salt and key stretching answer two completely different attacks.
A hash alone is not the finish line
Professor Messer's wording is worth keeping. A cryptographic hash "is used to represent data as a short string of text". It also goes by message digest or fingerprint. And "this cryptographic hash is not encryption."
That last part gets skipped a lot. Encryption is built to be reversed by whoever holds the key. A hash has no key and no reverse. That is the whole reason it fits password storage: the server can check you without ever keeping the thing you typed.
So systems store "a hash for all of the passwords". Or a hash plus a little extra information called a salted hash. The extra information is where this gets interesting. A plain hash has a problem that has nothing to do with weak math: the same input always produces the same output. Two people who picked the same bad password get the same row in the file. Crack one and you have cracked both. The algorithm is fine. This is a property of it, and it is one an attacker can build a business on.
Salt removes the shortcut
Salt is "random information that we add during the hashing process to modify or randomize the resulting hash". The detail that matters for the exam is that "every user gets a different random salt to go along with their password."
The attack it kills is the rainbow table. Messer calls that "a pre-compiled set of every possible input and the series of hashes associated with those inputs". Somebody spent the compute once and wrote all the answers down. Now they look hashes up instead of calculating them. Add a random per-user salt and "these rainbow tables will no longer work", because the table was built for the password alone and not for the password plus your own random string.
Here is what people get wrong. Salt is not a secret. It sits in the database right next to the hash. It has to, or the login check could not run. So what if the attacker dumped the whole table and holds every salt? Salting still worked. That table is dead either way. Slowing anybody down was never the promise.
Key stretching goes after speed
Key stretching takes the other job. Messer describes it as doing the work over and over: "you may want to hash a password, then hash the hash of that password", and keep going from there.
Read that as buying time rather than adding secrecy. Nothing about the stored value got more secret. It got more expensive. A user logging in pays the cost once and never notices (which is the whole design). Somebody running a dictionary through a stolen file pays that same cost on every single guess, which is why a rig that would have chewed through the entire candidate list in an afternoon can end up grinding away at the exact same wordlist for weeks. Same hardware and the same password; wildly different amount of the attacker's year gone.
The decision you are actually making
Label the attack before you read the options. There are only two shapes here.
Attacker using something precomputed? Two accounts falling together because their hashes matched? The shortcut is the problem, so salting. The stem tips its hand with words like rainbow table and precomputed and lookup.
Attacker already holds the file and is grinding through candidates? Speed is the problem, so key stretching. Look for brute force or offline cracking or a dictionary attack.
Then there are the options that show up in both questions and are wrong in both. Encrypting the password database sounds strong and is largely a shell game, since the key has to live somewhere on that same server. Tighter complexity rules are a policy control. They change nothing about how the stored value is protected. A longer hash output doesn't slow anyone down either.
A well-written question will sometimes hand you a combined answer that is correct. Real systems do both, while the stem that names one attack wants the one control that removes it.
Drilling it
Take a blank card. Write "precomputed table" and "raw guessing speed" on one side. Put salt and key stretching on the other. Run every password question you own through that order. Attack first. Control second. If you catch yourself picking a control because it sounds like the stronger one, you have skipped the step the question was testing.
The habit is worth more than the vocabulary. A lot of 1.4 works this way, where two controls both look right until you say out loud which attack the scenario is describing. Want a quick read on whether that skill is there yet? The free diagnostic at https://secplusmastery.com/diagnostic is built out of scenarios rather than definitions, and the practice questions and labs at https://secplusmastery.com run on the same idea.
Top comments (0)