This article is painfully light on the details. The blog post they linked is much more informative: https://support.lastpass.com/help/incident-2-additional-deta

This article is painfully light on the details. The blog post they linked is much more informative: https://support.lastpass.com/help/incident-2-additional-details-of-the-attack https://support.lastpass.com/help/incident-2-additional-deta... DevOps itself is a huge (and thin) attack surface. This is a feature of software as a centralized business venture. If your company is storing user data, then it must be someone's job to do that. They need administrative server access to do that job. The important takeaway is that the data itself can still be safe. So long as the company did not have a way to decrypt it, that data can rest anywhere. Guaranteeing that reality, however, is very difficult for a business - that is expected to be private about their implementations - to prove to its customers. When this beach happened, LastPass should have focused on telling their users to never reuse the master password that they had set at that time. That's the biggest vulnerability: the content of their vaults (as copied by the attacker) was, and is, still kept behind that password. The need for each user to keep that specific password secret is the main effect of this situation. This is a great reminder that you can't trust anyone to keep your data private. You can only trust math.