Cracking encrypted LastPass vaults
markuta.com
markuta.com
I was hoping for an exploration of how quickly one might crack a lastpass vault looking at different strength passwords and different iteration counts.
Instead the author has simply demonstrated that if you tell the cracking tool your password it can indeed crack it...
I guess you can at least follow what they did with your own vault without adding your password to the word list and see if it cracks quickly or not.
It's called "dictionary attack", but author wasn't bothered doing full brute-force attack or masked attack. It's a demonstration that a laptop can reach `2,000,000+ H/s`.
No, the author says their laptop only reaches ~1kH/s. That 2 million number is a pure guess for a multi-gpu setup and that is still pretty weak, unless you have a very good dictionary for a specific target. Brute forcing remotely long alphanumeric passwords is out of the question. So if you have a 8+ character password with upper+lowercase characters and digits that is not close to a real word and was never used anywhere else, you should be perfectly fine after this breach. Only if you have a really shitty password or if you reused it you should probably do something.
If you could do 100 million hashes per second (that seems to be possible with hardware looking at crypto stuff), the way I understand the setup you're still up against the 100100 iterations in the key derivation algorithm. So that's 7 * 10^19 hash calculations.
Even with the hardware to do 100 million hashes per second you're looking at nearly 23,000 years.
Let's hope you get a hit at 50% of the space (the expected average case). That's 11500 machine years with beefy GPU accelerated machine. So to bring this to a usable 5 years (and that's already pushing the expiration date of any creditcard you may find in the stolen vault) you'd need 2300 gpu accelerated machines running 24x7.
In AWS terms, with reserved discounts and everything you're going to spend roughly 60 million dollars cracking one vault.
1) Find all vaults with the lowest iterations
2) Order by some criteria (known money sources: URLs for banks and crypto, known URLs that would have PII information: utilities, telcos, governmental URLs)
3) Start cracking...
Or they could skip all that for some quick money. There's no need to crack anything if the URLs can get you money. How much would a dictatorship pay for the identities of everyone with an account at a URL that posts negative information on the regime? A domain.com/wp-admin account could certainly get you killed.
Speed.#1.........: 38789 H/s (11.17ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#2.........: 39017 H/s (11.17ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#3.........: 38894 H/s (11.16ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#4.........: 39254 H/s (11.02ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#5.........: 38626 H/s (11.17ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#6.........: 39448 H/s (10.94ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#7.........: 39256 H/s (11.06ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#8.........: 38966 H/s (11.14ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#9.........: 38870 H/s (11.17ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#10.........: 39259 H/s (11.01ms) @ Accel:128 Loops:64 Thr:64 Vec:1
Speed.#\*.........: 390.0 kH/s
*edit: just wanted to clarify that I think bruteforcing this dump wouldn't be as useful. It would still take a crapload of resources to be effective or useful in that scenario.
All that I need to do is pay for power, which is at lowest rates.
Who wants to crack some hashes?
The iteration count is 100100. So at 2000000 H/s, that's 19 passwords/s. A 6 alphanum password has 36^6 combinations. 36^6 passwords / 19 passwords/s = 114567491s =
3.6 years
With 65 (base64 + space) characters:
125.9 years
Divide those by 20 (100100/5000) for the lower iteration count. Multiply them by 6 if the password has up to 6 characters.
Note that is NOT a demonstration of being able to crack an encrypted LastPass vault. The author's exercise wouldn't be feasible without prior knowledge of the master password, or choosing a master password that is present in a list of common passwords. That is consist with what we have heard from LastPass so far.
The author does point out that a 2,000,000+ hashes per second could be achieved so it might give insight into how quickly all accounts will be checked against popular word lists. If I was a last pass customer I would be thinking about changing passwords on all accounts.
Why is that disappointing? It is a proof of concept, rather than evidence that it has already been done. Sure, it is not novel and perhaps it is overstated, but it does point out that attacks are already possible. It would also be interesting to see the results of a dictionary attack to see if the behaviour of people who use password managers is any better than the population as a whole.
Obviously black bars are better but sometimes you don't care that much about keeping the data secret.
It's only difficult if it's been resized+compressed lossily, if it's a photograph of a screen, etc. And since font rendering can be different between Windows and Mac, you might have to try it on each one for a perfect match.
What could be better is adding noise that matches the dominant 2 colors of the selection and focuses near areas of contrast. Then you can apply the pixellation on top of that and get something that's tougher to reverse.
Alternatively, it could try to recognize where the text and replace it with a string of random characters that are around the same size. In that case there would be absolutely no way to get back the original text since it's gone before the pixellation is even applied.
I've always thought it foolish to recommend solutions like LastPass and BitWarden, which don't require a secret key. It is dangerous design, prioritizing ease of onboarding over actual security.
The average consumer needs an autogenerated secret key. It provides entropy where the user will refuse to. Everyone I have helped set up a LastPass or Bitwarden account have chosen simple passwords, and are extremely resistant to the point of anger if you make them choose a complex one. After a few weeks, my mother changed her complex password back to a simple one behind my back - the only time she's learnt computer functionality on her own.
1Password's whitepaper, IMO, also shows that it's ahead of the game in general.
I wasn't surprised when LastPass was hacked - indeed, I've been expecting it for years - poor software quality and bad security choices were the red flags. Hopefully this forces BitWarden and LastPass to change and introduce generated secret keys in their account creation phase.
> This is why I prefer 1Password, as it requires the secret key to be compromised in addition to the Master Password, thus providing protection against a weak master password.
To access your vault an attacker will need both your master password and the secret key. These are effectively combined to generate your keys for decryption.
This protects against an attacker gaining access to 1Password servers. They can’t control whether you chose an awful password or not. So to protect them the secret key adds a ton of protection for those with weak, reused, or compromised passwords. Even in those cases an attacker needs to guess the secret key alongside the awful password. Using both the secret key and a strong master password is basically the equivalent of making a vault incredibly secure and, uncrackable using todays technology.
This does not protect against local compromise of a device of yours though, as the Secret Key is stored on device and is accessible. This prevents you from having to type it every time.
An attacker would have no success with a dictionary attack (used in the article). Even if the password was in the dictionary, the private key is still missing.
You could save it in a local keepassXC database if you like.
This 128bit key is only saved locally, not on their servers. So contrary to you disbelief, 1Password does actually prioritise security in this manner over focusing on ‘regular customers’.
Its also fairly common to have more than one device, so you would have the key on more than one device as a result too.
The secret key is never sent to 1Password and is only used locally.
This is why it’s so much more secure than LastPass, and Bitwarden, and any other cloud hosted solution. I know, I just pissed off all the Bitwarden fans, but it is true.
You must save your Secret Key, but it’s also saved in Apple’s Keychain so there’s a copy there as well.
Finally, if you do lose your secret key, your account can be recovered using the Account Recovery process as long as there is someone else on your account with the appropriate permissions. If you want to know how that works, ask, but it’s sort of lengthy so I’ll skip it for now.
Do you know that or do you just hope they do what you think they do?
I was especially impressed by the Cure53 ones, where they were provided access to the source code: https://bucket.agilebits.com/security/Cure53-1PW18-report.pd...
Both LastPass and Bitwarden (and 1Password) support 2FA. This isn't a solution that will have mass adoption, but the UX is much better and more secure than using a secret key. It could even be used by non technical users, depending on the device.
But password managers aren't a solution for digital identity. They're a hassle to use and a huge security risk, especially centralized ones. What we need is a solution that is more secure, but crucially also easier to use. The industry has been trending towards passwordless solutions for years now (OTP, FIDO, WebAuthn, etc.), and the current passkey iteration by Google might be something that could have mass adoption. Assuming you trust Google, but the technology seems sound.
We still might want to use secure storage for other data, but that's a much more niche use case that can be secured with existing MFA solutions, and doesn't have to be as user friendly as identity management.
AFAIK it doesn't help if your vault is in the hand of someone who obtained it from a security breach on lastpass/bitwarden side.
She doesn't have to remember the secret key. She prints out copies and puts them somewhere safe.
> Both LastPass and Bitwarden (and 1Password) support 2FA [...] the UX is much better and more secure than using a secret key
No. Please don't make statements like this if you're not certain. 2FA confers zero benefit in a breach like this one. It is merely an access control, and doesn't provide any cryptographic benefit. Secret keys, however, make such a breach basically worthless. No amount of rainbow table usage or master password compromise will help you unless you can obtain the secret key.
How does 1P compare to built in keychain (Apple devices) when it comes to security? My guess is that there’s encryption key for the vault and private key for access? I’ve been using 1P for family secrets for a while but I’m grieving more and more frustrated with frequent technical issues (unreliable sync, browser extension loses connection to 1P and has to be restarted). And I’m considering switching to OS built in keychain and maybe 1P personal for family shared secrets?
or (=increase number of users actually using a password manager)
There is a marginal usability benefit to LastPass’s lack of such facilities, but I think this breach shows that the security reduction was too high a price to pay for it.
> urges users to print a backup copy
I read it a few times in this thread already, but with the general lack of printers for most people, I find it kind of funny. I personally guess that more people put it unsecured in their dropbox than people actually printing it.
> I think this breach shows that the security reduction was too high a price to pay for it.
I think this breach shows that operational security for lastpass is lacking, something distinctly different from the password storage system security. Although it might be linked as in teams building less secure systems might have worse security themselves.
What I meant by it: Securing the system against breaches of, even encrypted, data.
I was trying to differentiate the security of access to the encrypted database from the security of the data inside the encrypted database, i.e., how hard is it to get it, instead of how hard it is to break once you have it.
Because I think that the security reduction discussed here (e.g., allowing weak masterpasswords) is on the "how hard is it to break it?" side, while the breach itself is on the "how hard is it got get it" side. Based on this separation, I don't think that the breach is a sign that the reduction was a price too high, because the reduction in security did not make the access easy - bad access security made that possible.
Every password manager is built with the idea that one day, the server will be hacked and the vaults will be free to download. The same goes for E2EE in general.
With this in mind, LastPass and Bitwarden's solutions are very poor and can result in most customers vaults being breached, whereas 1Password's secret key model stays strong.
Maybe that's a better way of restating my point that access security is not identical to the security of the password store.
> With this in mind, LastPass and Bitwarden's solutions are very poor and can result in most customers vaults being breached, whereas 1Password's secret key model stays strong.
While believable that most peoples passwords are weak enough to be broken, I wonder how many people actually have bad enough passwords to be reasonably decrypted.
I have no doubt about the security of 1passwords secret-key model being stronger - and I haven't seen anyone claim any different. At most I have seen anyone claim it is cumbersome and will get people to use no password manager instead (resulting in weak, reused passwords).
Ok, can you run it for 7 hours without your password in the list and let us know?
In my pentesting days if we dumped the DC at the beginning of a test we would let that run in our password cracker GPU machine for days to see what hits we got
The main concern is whether LastPass has also faced a supply chain attack that will expose you to a malicious client that will leak your passwords post-decryption.
The way to address that particular concern is to change the passwords of all your services themselves. If you do that, it would a good time to change password managers too—just save the new passwords in the new manager.
Another approach would be to turn on MFA for your services, if you have not yet. Then even a cracked password will not be enough for a bad guy to get in.
All that said, if you have been using a long and complex master password, it’s unlikely that it could be successfully decrypted in the first place.
> These encrypted fields remain secured with 256-bit AES encryption and can only be decrypted with a unique encryption key derived from each user’s master password using our Zero Knowledge architecture.
That all sounds great but the number of bits of AES and the cool "Zero Knowledge" designation is completely irrelevant here. It entirely depends on the strength of the user supplied password. So if your password is weak you are in trouble. The other message here is that if your password was installed before 2019 it is probably going to be a lot easier for an attacker to guess.
That's it, that's the whole thing, but it still needs to be shown...
I don't believe the 6 hours+ claim. (Or rather, the "+" is doing some serious lifting in that sentence.)
Looking at the password, it's of the correct-horse-battery-staple variety, which could be conservatively estimated at 44 bits of entropy (this is even ignoring the additional number appended to a random word) - which would take even the described "multi-gpu" setup with 2 million hashes a second just about 100 days to exhaust (or 50 days to have a 50% chance of getting it), let alone the 1000 hashes a second macbook the author was using.
He took a word list which did not include his password and put his actual password in the word list. He didn't crack his password, he showed that a brute force password guesser can find passwords that are in its word list. If he wanted to save six hours, he could have put it first in the password list. No news here.
Why wasn't LastPass using memory-hard key derivation functions? I thought that's been best practice for a very long time now: we've known about GPU/ASIC hashing for decades.
How secure is a randomized 5 digit pin where you get unlimited guesses but after 10 guesses the pin is reset?
Guessing the pin correctly gets you enough information to open a bank account.
Assuming a system like the above exists, would you consider it a security vulnerability?
Assuming it’s reset every 10 attempts, you have lost keyspace and gained random odds. 1:1000000 of getting the password right, 1:500k on average. Assuming I can perform one attempt per second, about 139 hours to successfully brute force a single account. One second is probably pessimistic, most systems are capable of serving much higher rates.
Unless you have fail2ban or MFA, consider the pin a formality.
Is it 1000k or 10k (99999/10 guesses)?
I can't give full details of what is within accounts without potential exposure of the company. So I called a local bank and asked what I needed to set up an account. All the information required was part of a potential breach.
Is there a rate limit where protecting information with 5 digits is ok?
Rate limits and account lockouts create accessibility and availability issues, I’m not aware of any real world case studies where they have been abused, my guess is demographics are important (a student is more likely to do it to a school rather than a random on the street doing it to a finance company). Though, if usernames are possible to enumerate, you should still consider the risk of someone doing it at scale as a dos.
What is / is not okay is probably largely defined by any security frameworks that you’re required to adhere to - in Australian Gov there is the Information security manual (google ISM ACSC). It states that password complexity goes up if you do not have MFA, and that without it credentials should be 14+ characters long.
Given your assertion that a breach would be possible, I would strongly suggest that your current methodology is dangerous. If you can enumerate usernames doubly so. Are you able to script a proof of concept brute force? Tools like hydra do this, but I prefer python3/requests.
that does little to counter the real problem, as the chance of successfully guessing the pin on first try is still 1/1e5, which gives ~69k attempts for a 50% chance of correctly guess that pin, Which is like ~2 hr at 10 pin attempts/second. Having request throttling helps tremendously, but shouldn't be the only deterrence in place. Moreover it should be implemented in a way that it does not become a way for DoS attacks.
There really isn't anything new here.
Also, Lastpass doesn't encrypt URLs. There's really no excuse for that.
this should not be possible to bruteforce
So it’s kind of like using 5 characters from a much larger alphabet (the English dictionary) instead of 30 from a 26 letter alphabet.
Even on the low end, it should take well over a decade if LastPass chose a good cryptographic hash function with a high iteration count.
The problem is that no average person is gonna use a password that long to begin with.
Most people know at least 3 languages well enough. I often make passphrases out of 5 to 6 languages.
Diceware - an actual formalisation of the approach, including recommended means of generating the entropy and specific wordlists - uses 7776 words, for a shade under 13 bits each. EFF have a nice one - https://www.eff.org/dice
The recommended 6 words gives 77.5 bits of entropy per password. At Lastpass's current default iterations of 100k that's about 2^93 SHA256 operations to have better than even odds of breaking it.
To put that into perspective, the Bitcoin mining network is reportedly hashing at 256 quintillion hashes per second right now. At that rate it would take on average 72 weeks to crack.
One extra word bumps that up to 11 millennia, if that's a bit too tractable for comfort.
It is that it is a method for which the large group of people who would choose "Password0!" as their password [1] can use to create a password they can potentially remember, but such that the chosen password is "relatively" more secure than the basic alternative they would have otherwise chosen.
[1] I.e. the far too common method of "pick a word, make one or two letters capitol, append a numeral, append a !".