Iterations refer to the number of times the password goes through the hash function. The higher the number, the longer it takes, so you want it low enough that it doesn't impact your day-to-day use but high enough that it will hinder an attacker in case the hashed password is leaked.

Maybe overly pedantic to expand on this, but since we’re in an ELI5 context: the attack vector is brute forcing hash collisions. Making it computationally slow for attackers is a hindrance because the relative value of a collision diminishes over time (depending on the value of their target).

It's not really hash collisions: SHA256 is still too secure for that, you're unlikely to find a value which isn't the password used to generate it. It's just brute forcing the password

Your master password is put in a box that’s very hard to break into. But because someone might be really determined to get in, we put that box in another box that’s just as hard to break into. And because someone might be really really determined, we keep putting those boxes in new boxes so it’s really really difficult to get to the password. But sometimes we also need to get to the password, so we use enough boxes that it’s difficult for them, but not so many that it’s annoying for us.

That might be a little too much “like I’m 5”, but that’s the general idea. Hashing is easy one way but it still requires compute cycles to do each iteration. We don’t want to make it excessively expensive for us.

To kinda just expand on that because I think the analogy's most of the way there:

You're trying to keep something safe and all you've got is a weirdly infinite collection of cardboard boxes. So you have this brilliant idea... you get a dozen boxes and put your treasure in one of them.

That's great, it's certainly safer than leaving it laying out. It'll take someone at least like... a minute to go check all dozen boxes and find your treasure. But it still only takes you mere seconds because you know which box to open.

Except you'd really rather your treasure stay safe for longer than a minute. So you take all your boxes and put them inside other boxes. And put those boxes inside other boxes like nesting dolls. You nest each one a dozen times.

So now if someone wants to come and find your treasure, they need to open all 144 boxes to find it! But you still only need to open 12 because you know which stack to look in.

The iteration count is basically just how deeply you plan to nest your boxes.

In more concrete terms, increasing the iteration count is just a knob to control how much cpu/memory resources it takes to compute a hash. You want to turn it up enough to make brute forcing prohibitively expensive (make it as high as you can), but not so much that calculating the single correct hash to verify is too expensive (don't make it too high or else it will take too long to check your password at sign-in). People are saying this should go up over time because computing resources generally become more readily available (faster/cheaper), making both brute forcing easier as well as allowing you to perform more iterations to compute the correct hash on commodity hardware without it taking unusably long.

Thanks, this was a great explanation!

Feynman would be proud. The ability to take a complex subject and break it down in such a way that nothing of value is lost but a child can understand it is rare.

If there are 12^2 = 144 boxes total, you only need to open 2. Not 12 as you said.

Put differently: with x^y nested boxes, you only have to open y. The attacker has to open x^y.

No, you're thinking of something different, like making the password more complex.

While they made it confusing by using "12" for two different things, their analogy is completely correct.

Instead of each password/location having one box, it has a box within a box within a box[...]. You have to unwrap the entire stack to check if the treasure is there.

If you use an iteration count of 5000, then when you log in you unfortunately have to do 5000 hashes. But an attacker has to do 5000 hashes per password guess.

So a deep iteration count can't substitute for a good password, but it can make up for an extra few characters. And it's basically free to increase iterations until the wait becomes visible.

Another issue is the hash used: SHA-256 is a hash which can be calculated extremely quickly on dedicated hardware (which has been incentivised heavily by bitcoin mining). So the gap between the speed at which an attacker can run the hashes vs the intended user is larger than with other hashes, like argon2, which is specifically designed to be resistant to acceleration by dedicated hardware.

Is it actually 144? Wouldn't that be the worst case scenario for the attacker? If I understand the whole thing correctly, the attacker can be lucky and find the right stack of 12 in the first try.

So basically, I would set it at around half of the 144: 72 or did I get something wrong there?

That's good, I like the box in box imagery.

PBKDF2 directly might be some sort of multiverse locked box? Store a "safe key" in a box, in a box, in a box, in a box, in a box... in an iteration of boxes.

Every key in the universe is able open the first box, and every other box. But each key opens up a different multiverse of boxes. The problem for the attacker is they have to open every box, in a box, in a box... in succession to get to a "safe key" stored in that multiverse, which looks like a safe key and quacks like a safe key, but might not be the right safe key.

Maybe not quite right, as the "safe key" is really just another box in the end, but that doesn't make much sense... unlike a box of multiverse of boxes =)

If your (binary, derived 128 bit) encryption key is the key your treasure chest - then the "derivation" is a map from your password ("hunter2") to the where the key (011101...) is buried.

With plain derivation, the map takes you directly from the password to the key. With an extra iteration, the map just points to a place on the map where a trail starts.

If you want to guess the key, by guessing the password - now you have to first walk to were the password points on the map, then follow the path (the iterations) - then dig and see if the key is there. Then you can try the key in the chest (the encrypted data).

The iterations (length of path) adds a certain, predictable, amount of work in order to find the key. It does not make it harder to guess the password, just harder to get the key from the password - and so it makes it harder to check if you've guessed the right password (try the key in the lock) - because there's extra work to be done.

Now you could compare memory-hard paths and compute-hard paths by adding elevation and distance to the analogy (different types of hard work).