LastPass disclosed yesterday afternoon (LastPass security incident notice, December 22) that the intrusion the company first reported in August had, on subsequent investigation, produced more substantial customer-impact than the initial disclosure characterised. The disclosed scope now includes: customer vault backups (the encrypted-but-recoverable storage of customer passwords and other credential data), customer account metadata (including email addresses, billing addresses, telephone numbers, and the URLs the customers had stored credentials for), and partial customer payment-card data. The vault encryption is intact in the standard sense — the customer's master password is required to decrypt the vault contents — but the exposed data provides offline-attack opportunities against any vault whose master password is weaker than the recommended LastPass minimum.
The technical content. The intrusion mechanism, on LastPass's account, was credential-compromise of a LastPass DevOps engineer's home computer, with the engineer's credentials being used to access LastPass's cloud-storage infrastructure where customer vault backups were stored. The exposed vault data is encrypted with the customer's master password using LastPass's documented PBKDF2 key-derivation parameters (default 100,100 iterations as of recent versions, with older accounts having lower iteration counts). The offline-attack timeline against a strong master password (16+ characters, well-chosen) is, on current GPU-cluster economics, substantial — measured in years for a single vault attack at brute-force rate. Against a weaker master password (the 8-12 character range that many users in fact use), the attack timeline is substantially shorter and may be feasible for motivated adversaries.
The trust-model implications for password-manager-as-a-category are the part of the disclosure that has the broader implications. The implicit security promise of cloud-hosted password managers is that the operator's security posture protects against the various threats including operator-side compromise. The LastPass case demonstrates that the operator's security posture is not, in 2022, sufficient to that promise. The customer-organisation conversations about cloud-hosted password-manager deployment are correspondingly more nuanced than they were a week ago.
The defensive posture in the post-LastPass environment. First, every LastPass customer should rotate every credential stored in the affected vault to the assumption that the credential may, eventually, be exposed through offline-attack against the master password. The aggregate cost of that rotation across the LastPass customer base is substantial. Second, the choice of password manager is, in 2022, more nuanced than it was in 2018. The cloud-hosted-versus-self-hosted trade-off, the operator's security-posture maturity, the master-password strength requirement, and the multi-factor-authentication posture all matter. Third, the broader-than-LastPass conversation about password managers is, in 2022, less straightforward than the 2017-era "use a password manager" advice was; the use case is still correct, the specific operator and configuration choices matter more.
For the customer-portfolio response. We have not used LastPass internally; the customer-portfolio password-manager deployment is split across 1Password (most), Bitwarden (some self-hosted instances), and a small population of customer-organisation-internal solutions. The customer-organisation response has been the standard enumeration of LastPass usage among employees (which has produced, as expected, a non-trivial population of personal-and-corporate-mixed LastPass usage that we have been encouraging migration off for some time) and the credential-rotation posture for any such usage. The aggregate operational cost is moderate.
I will return to this through Q1 2023. The LastPass situation will continue to develop and the broader password-manager-conversation will be a substantive theme.