Hacker News Reader

Comment by sircastor | Hacker News Reader

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.

View on HN

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 =)

Reply on news.ycombinator.com