Skip to content

LastPass Password Manager Security Breach

As a business that relies on this service, should you be concerned? Take any actions?

Last week, it was reported that LastPass, a popular password manager service company for over 33 million people and 100,000 businesses (according to their website) had a security breach.

LastPass said a threat actor gained unauthorized access through a single compromised developer account to portions of the password manager’s development environment. From there, the threat actor “took portions of source code and some proprietary LastPass technical information.” LastPass said that master passwords, encrypted passwords and other data stored in customer accounts, and customers’ personal information weren’t affected.

 

Our assessment of the response of LastPass and risk

The reality is that development accounts getting hacked goes on with some alarming frequency. Even with this knowledge, LastPass deserves its due credit as they came very clean, very quickly. They could have buried it or waited until customers were found to be exposed to risk, however, they didn’t. That’s the sign of a company that is very ethically grounded, clear-eyed and with mature incident response. Subsequently, I don’t find myself doubting a word they say. That has a huge weight on how one should evaluate their claims and their responsiveness.

LastPass uses the same cryptographically sound algorithms the rest of the best-in-class world uses. Why is that important?  We know how crypto-algorithms work, it’s not a secret set of algorithms to be obtained this way on a developer account as the goal. Private key encryption is based on mathematical cryptography, so if you are in possession of the cryptographical algorithms, it doesn’t matter. You need the private key(s) to “crack” anything. The algorithms used doesn’t help one decipher anything at all without private keys. LastPass notes they don’t even have their consumer private keys stored; a legitimately lost customer master vault key must be restored by the consumer regenerating it themselves through secure techniques. Even in a dire circumstance where a private key store was theoretically breached, or the key generation process mined somehow, there is still a pragmatic reality of matching private keys discovered to customers, which LastPass have millions of at the consumer level. A malicious user breaches development accounts with a long-term arc purpose, the intention being to get back doors built in for the future, with benefits taking months to come to fruition. Sounds like LastPass (so far) headed this off proactively and transparently.

There is also no set of customers identified as affected. That’s a big deal. It means they are likely telling the truth and don’t have a master vault key management generation breach problem. It also means there was no company restricted PII (Personally Identifiable Information) about their customers released, as such, even if somehow a major code vulnerability was found with the development platform, it would be hard to target this (at least quickly).

At this point, moving too fast and scrambling has far more risk for customers where all sorts of configuration changes of this kind may become a bigger risk than presented here within the confines of this breach. The prudent path for many may be to:

1

Watch LastPass PR releases for the next couple of weeks closely. If they use abstract and indirect “weasel language”, such as “some customers may be affected”, it may need a risk review leading to (2) below. This certainly has not been the case up until now, LastPass has acted prudently, proactively, responsibly and with transparency with regard to this breach.

2

In the worst-case scenario I can think of for the kind of information taken here / possible code repository configurations / back doors built, all these would take quite a bit of time (weeks) to weaponize and longer (months) to target. You have time to set up a contingency plan to switch them out if (1) above LastPass messaging starts using too many “weasel words” suggesting transparency is now lacking or (2) you are informed you may have been impacted somehow (LastPass are under SOC 2 / SOC 3 compliances where they must inform customers in this unfortunate circumstance) and you can then switch them out with a sane and measured roll-out plan with a lot more configuration reliability if you have done the necessary contingency planning to do so upfront.

 

Steve McGeown

Security Practice Manager