9

Last weekend LastPass' network was compromised and that a list of email addresses along with the hashes of the master passwords were stolen. It is being recommended that LastPass users change their passwords on several security websites. https://blog.lastpass.com/2015/06/lastpass-security-notice.html/

According to the LastPass link above, "LastPass strengthens the authentication hash with a random salt and 100,000 rounds of server-side PBKDF2-SHA256, in addition to the rounds performed client-side.".

Is there any real reason for someone with a strong (30+ random characters) password to bother changing their master password? My understanding was that with a random salt and 100,000 rounds of PBKDF2-SHA256 and a long password, the password would be safe from brute force attacks even if a hacker had a budget equal to the world GDP. I am asking this question to make sure I am not missing something.

cuengi8
  • 103
  • 2

2 Answers2

3

No, a 30+ random character password is safe

If your password is 30+ random characters, the number of possible passwords is well beyond 95^30, which is 2.14e59.

The Oclhashcrack page gives a sample crack rate for SHA256 of 16,904 Mh/s. So lets assume the "budget equal to the world GDP" would allow for a million of these computers to perform the cracking. (We are ignoring the 10,000 rounds for simplicity).

The computer can guess 16 billion hashes per second times 1 million computers. This would equal about 1.6e16 guesses per second. Thus it would still take 1.3e43 seconds which is equal to 3.1 e25 times the age of the universe. Multiply the number of computers by 10, and you drop to 3.1e24 times the age of the universe.

So finally consider that the 10,000 rounds means that the hash calculation would be reduced by 10,000. Further consider that the hashes are randomly salted. This means that an attack has to be targeted on a specific hash.

What about other attack possibilities?

If we consider that attackers had access to the Lastpass network, the attackers are more likely to get the plaintext of a 30+ random character password by intercepting it in plaintext when you log into the website. Lastpass hasn't given any indication that this has happened, but this would be a realistic reason to change your password.

Community
  • 1
amccormack
  • 3,971
  • 1
  • 15
  • 23
  • 1
    you should always qualify the word "safe" - you cannot declare "safety" with any certainty, regardless of your math – schroeder Jun 16 '15 at 15:12
  • 1
    I'd likely dispute that "30 random characters" is going to be randomly distributed among 95 different possible characters. But your argument still stands because of the password length is so high that losing a factor of a billion isn't significant. – Steve Sether Jun 16 '15 at 15:24
  • 1
    @SteveSether yeah the character length of 30 is the variable driving the hockey stick growth of the key space. I also leave out the fact that you could expect to guess the plain after guessing only 50% of the key space. – amccormack Jun 16 '15 at 15:29
  • Since LastPass is a browser plugin or discrete Android application, I would hope they aren't as simple to man in the middle as intercepting the password in plaintext. One would hope the client only sends the hash rather than the actual text of their password. – Herringbone Cat Jun 16 '15 at 15:30
  • @Herringbone_Cat yeah, I meant something along the lines of hijacking webpages on the server or stealing the SSL key and decrypting. I didn't mean intercepting non-ssl traffic. – amccormack Jun 16 '15 at 15:34
  • @schroeder the math is the qualification. It explains why I'm very comfortable saying it is safe. – amccormack Jun 16 '15 at 15:38
  • @Herringbone_Cat: Yes, [they hash the password client-side too](http://security.stackexchange.com/a/81098/8340). Even though this usually means "the hash is the password", the effect in LastPass's case is that an attacker can't use any intercepted password to decrypt the local database. – SilverlightFox Jun 16 '15 at 15:39
  • @amccormack math is the justification, not the qualification – schroeder Jun 16 '15 at 16:41
  • 1
    I'd argue that a 30+ password is probably a passphrase. The math is different for passphrases. Suppose it's a 7 word pass phrase, each word chosen at random from a 7776-word dictionary. The search space is then 7776^7 or 1.7e27. At the assumed rate of 1.6e16 guesses per second this would take ~1e11 sec. or ~16 centuries on average. However, if the dictionary only contains 1000 popular words, the right guess only takes some 8 hours on average. – Dick99999 Jun 17 '15 at 10:35
  • 1
    @Dick99999 Sure, but the question states "30+ random characters". – amccormack Jun 17 '15 at 10:51
0

The real danger is not structured guessing I think. Guessing takes to long for 30+ passwords or passphrases on average. But on average also implies they might have some luck on day 1, and you don't want your password to be the lucky one.

The real danger are existing lists with millions of known passwords. Hashing them one by one and comparing the hash with the stolen hashes is quite doable. I have seen lists that contained:

yTp3HHuuCTo9kyTp3HHuuCTo9kyTp3HHuuCTo9k

xc3xacntrxc3xackulxc3xacmbroqulxc3xac

yankeesayka-ofrp3olgavaner8913gruscha

werhnbkliopfdsrftgwerhnbkliopfdsrftg

welcomeelquehacequeelcorazonyore_21

whateverabdulaziz.ahmadjonov.1977

williamshort.guy.with.blonde.hair

All 30+, and all in danger. To my knowledge the only way to cope with this know passwords lists risk, is to choose your characters or words really at random. If you have not done that, your 30+ password is at risk.

Dick99999
  • 525
  • 5
  • 8
  • 2
    Wrong. The hashes are salted so precomputed hashes are irrelevant. – isarandi Jun 17 '15 at 12:28
  • I don't mean precomputed in that sense. The salts (email and random number) are stolen too. So one can compute the hash of each password on the pw-list, just like the client and server do when authenticating, and compare that outcome with the stolen hashes, right? – Dick99999 Jun 17 '15 at 16:30
  • You are right, I misunderstood what you meant. It's true that you could take the N most common passwords and hash all of them using each user's unique salt. This will take O(N*M) time for M users. I doubt that you could set N to be as high as to include "werhnbkliopfdsrftgwerhnbkliopfdsrftg" in the trials. I'm not an expert but it seems prohibitive to me. – isarandi Jun 17 '15 at 17:25