Many of you have been asking for my thoughts on the #LastPass breach, and I apologize that I'm a couple days late delivering.

Apart from all of the other commentary out there, here's what you need to know from a #password cracker's perspective!

Your vault is encrypted with #AES256 using a key that is derived from your master password, which is hashed using a minimum of 100,100 rounds of PBKDF2-HMAC-SHA256 (can be configured to use more rounds, but most people don't). #PBKDF2 is the minimum acceptable standard in key derivation functions (KDFs); it is compute-hard only and fits entirely within registers, so it is highly amenable to acceleration. However, it is the only #KDF that is FIPS/NIST approved, so it's the best (or only) KDF available to many applications. So while there are LOTS of things wrong with LastPass, key derivation isn't necessarily one of them.

Using #Hashcat with the top-of-the-line RTX 4090, you can crack PBKDF2-HMAC-SHA256 with 100,100 rounds at about 88 KH/s. At this speed an attacker could test ~7.6 billion passwords per day, which may sound like a lot, but it really isn't. By comparison, the same GPU can test Windows NT hashes at a rate of 288.5 GH/s, or ~25 quadrillion passwords per day. So while LastPass's hashing is nearly two orders of magnitude faster than the < 10 KH/s that I recommend, it's still more than 3 million times slower than cracking Windows/Active Directory passwords. In practice, it would take you about 3.25 hours to run through rockyou.txt + best64.rule, and a little under two months to exhaust rockyou.txt + rockyou-30000.rule.

Keep in mind these are the speeds for cracking a single vault; for an attacker to achieve this speed, they would have to single out your vault and dedicate their resources to cracking only your vault. If they're trying 1,000 vaults simultaneously, the speed would drop to just 88 H/s. With 1 million vaults, the speed drops to an abysmal 0.088 H/s, or 11.4 seconds to test just one password. Practically speaking, what this means is the attackers will target four groups of users:

1. users for which they have previously-compromised passwords (password reuse, credential stuffing)
2. users with laughably weak master passwords (think top20k)
3. users they can phish
4. high value targets (celebs, .gov, .mil, fortune 100)

If you are not in this list / you don't get phished, then it is highly unlikely your vault will be targeted. And due to the fairly expensive KDF, even passwords of moderate complexity should be safe.

I've seen several people recommend changing your master password as a mitigation for this breach. While changing your master password will help mitigate future breaches should you continue to use LastPass (you shouldn't), it does literally nothing to mitigate this current breach. The attacker has your vault, which was encrypted using a key derived from your master password. That's done, that's in the past. Changing your password will re-encrypt your vault with the new password, but of course it won't re-encrypt the copy of the vault the attacker has with your new password. That would be impossible unless you somehow had access to the attacker's copy of the vault, which if you do, please let me know?

A proper mitigation would be to migrate to #Bitwarden or #1Password, change the passwords for each of your accounts as you migrate over, and also review the MFA status of each of your accounts as well. The perfect way to spend your holiday vacation! Start the new year fresh with proper password hygiene.

For more password insights like this, give me a follow!

@epixoip 100,100 rounds is a new default. Many old accounts have the rounds set to 5,000.

@alx Incorrect. It was 5000 *client side* iterations plus 100,000 server-side iterations. See my comments on the 2015 LastPass breach for reference:

https://arstechnica.com/information-technology/2015/06/hack-of-cloud-based-lastpass-exposes-encrypted-master-passwords/

Hack of cloud-based LastPass exposes hashed master passwords

Users: Change your master password and enable 2-factor authentication immediately.

Ars Technica
@epixoip @alx are we sure about the additional server-side iterations? The announcement from LastPass the other day didn’t mention anything about that, and it sounded very much like the iteration count you have in your account settings is how many they use.
I checked mine and it was still set to 5000, so that along with the unencrypted metadata made me abandon ship to 1Password.
@HamAndChris @epixoip's link from 2015 quotes a LastPass blog post claiming "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." So it's a pretty explicit claim, and despite their security failures it seems unlikely they would have weakened that setting since. FWIW.
@alx @HamAndChris @epixoip hmm… their docs say that the salt is not random, it’s your username: https://infosec.exchange/@neilmadden/109570603420250703 But those docs don’t mention anything about a client/server-side split.
Neil Madden (@[email protected])

An interesting detail about #lastpass is that apparently the PBKDF2 salt is your username, so entirely possible to precompute hashes prior to compromise. Source: https://support.lastpass.com/help/what-makes-lastpass-secure-lp070015

Infosec Exchange
@neilmadden @alx @HamAndChris @epixoip
Doesn’t matter if your salt isn’t random, so long as it’s unique.
@BenAveling @alx @HamAndChris @epixoip Depends if you are likely to be individually targeted. If you are then a predictable salt allows an attacker to precompute hashes prior to compromise, speeding up password recovery post-compromise. This is why OPAQUE goes to great lengths to hide the salt: https://datatracker.ietf.org/doc/html/draft-krawczyk-cfrg-opaque-03
The OPAQUE Asymmetric PAKE Protocol

This draft describes the OPAQUE protocol, a secure asymmetric password authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. Prior aPAKE protocols did not use salt and if they did, the salt was transmitted in the clear from server to user allowing for the building of targeted pre-computed dictionaries. OPAQUE security has been proven by Jarecki et al. (Eurocrypt 2018) in a strong and universally composable formal model of aPAKE security. In addition, the protocol provides forward secrecy and the ability to hide the password from the server even during password registration. Strong security, versatility through modularity, good performance, and an array of additional features make OPAQUE a natural candidate for practical use and for adoption as a standard. To this end, this draft presents several optimized instantiations of OPAQUE and ways of integrating OPAQUE with TLS. This draft presents a high-level description of OPAQUE highlighting its components and modular design. A detailed unambiguous specification for standardization will be presented in future revisions of this document, or separately.

IETF Datatracker

@neilmadden

True, but something of an edge case. Especially so here, given that the disclosure timing was chosen by the adversary.