3
$\begingroup$

LastPass encryption scheme is recently changed to use more PBKDF2 rounds, specifically 100100. This seems like a really weird number choose. From what I understand brute force time scales linearly with rounds because more rounds simply mean that each hash takes longer/more memory to compute. Being just over 100k, it feels like there could be some weird prime number tricks that they are trying to avoid, but I honestly can't come up with anything, and it doesn't seem to be for backward compatibility with un-upgraded vaults either because those used to be 5k rounds IIRC, which would make it 105000 if they just slapped the extra 100k rounds on top.

So, why did they pick such a weirdly specific number instead of just straight up 100k? I don't get it.

$\endgroup$
6
  • 2
    $\begingroup$ Using a different number from others can be a pre-countermeasure. $\endgroup$
    – kelalaka
    Oct 24, 2019 at 7:12
  • 1
    $\begingroup$ Ok, so it's simply to defend against a potential rainbow table formed from someone else's leak, and if every service uses a slightly different number of rounds (100k+1, 100k+2, etc.), then these would be rendered useless. $\endgroup$ Oct 24, 2019 at 7:20
  • 1
    $\begingroup$ Not exactly, since the salt already prevents it. This is why I said pre-. $\endgroup$
    – kelalaka
    Oct 24, 2019 at 7:33
  • $\begingroup$ Seems bit pointless then. But I guess more layers of defense are always better ¯\_(ツ)_/¯ $\endgroup$ Oct 24, 2019 at 8:04
  • 2
    $\begingroup$ It sounds as though the number may have come from somewhere the sun don't shine. $\endgroup$ Oct 24, 2019 at 16:41

1 Answer 1

3
$\begingroup$

LastPass uses PBKDF2 with SHA256. The number of iterations (also called count) in PBKDF2(PRF=SHA256, Password, Salt, iterations, dkLen) is used against the password crackers. With the increase of the computation power, the developers change the number of iterations from 5000 to 100100 and there is nothing special about it other than being large. Having different numbers from others only can be considered a pre-countermeasure that may be helpful in the future. You can still adjust the iteration number to any value that you want.

The salt, on the other hand, is used as a countermeasure against Rainbow Tables. Actually the salt simply killed the Rainbow Tables. They are no longer helpful if the sites use a salt-based password hashing.

With a good PBKDF function with properly used salt, the only way to break is the brute-forcing the possible password and combinations. The number of iterations linearly increases the cost of brute-force. That is, if you double, the attacker with the same system need double time.

Keep in mind that there is an old saying inside the US National Security Agency (NSA):

$$\texttt{Attacks always get better; they never get worse}$$

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.