Despite Breach, LastPass Demonstrates the Power of Password Management
A few months ago, LastPass suffered a significant breach. Hackers got both the source code and user data, including encrypted secret vaults and plaintext metadata. This is not the first breach LastPass had suffered.
This breach put in me a weird situation. I'd been a champion of using secret vaults for a few years now. After a brief period of trial and examination, I chose LastPass even though it had been breached before. Being happy with the experience despite its quirks and a trying onboarding, I recommended its use to anyone I cared about — my family, friends, and colleagues. I helped them onboard and generate random passwords, install the app everywhere, and come up with a really good master password. In some cases, this wasn't easy and took a lot of guidance and convincing on my part.
The obvious fact I had failed to realize at the time was that a recommendation as strong as that comes with an implicit responsibility. When those people see a major news article about their passwords belonging to hackers now, they reach out to me for questions. They are right — I got them into this mess, didn't I?
Why Evangelize Secret Managers?
I was not always convinced secret managers were a good idea, especially commercial ones with their own cloud infra. As a teen, I started off where more people do, using one "good password" for everything, appending a service-specific prefix or suffix to avoid straight password duplication. I also had the unfortunate experience of working in an enterprise that forced me to change my password every 30 days. The number appended to the end of your password was a token of seniority in that org. I reached some number in the 40s and was really proud of myself and how experienced I was. Of course, when you're proud of something, you really want to share it. And so we did.
I always knew that sharing the chunky part of my password across services was a bad idea. That knowledge became a reality when I started to understand how hackers leverage these common yet faulty tactics to their advantage. Appending two letters to your "good password" does nothing to stop an attacker from compromising one service based on a compromised password for the other. It only makes you feel good about complying with a bad policy. Fortunately, monthly password changes are now passe.
But my first attempt at solving my password problem was using my dad's custom-built bare C based password manager. It was very basic: encrypt and decrypt a text file. You pop the encrypted file on a shared drive and congrats, you have a secret manager! Of course, this has clear downsides, like no mobile support, auto-fill, or password generation. I also wrote my own cli-based interface on top of cloud and native keyvaults. It was great, but still, no utilities. I used these two options for a long while. I was still looking for solutions with those utility features, but anything with the word "cloud" in it was denied at the doorstep.
Then I took an advanced crypto course as part of a masters in computer science. The beauty of Merkel trees and zero knowledge proofs excited my imagination and made me devour the Web in search of real-world applications. I encountered a scientific paper describing secret vaults, and the idea just clicked. Of course, it makes perfect sense! The only way for my passwords to be truly secure is to assume the vault provider is malicious and still be confident that they can't accomplish anything significant. I had reached the conclusion that a password manager that follows the theory would be safe to use.
The other threat vector to get my password is a malicious vendor or party within that vendor. They could, for example, steal my master password from the client application, making the theorized protections irrelevant. After reading though reviews putting different password manager clients under scrutiny, I became convinced that the implementations are up to standards and it's time to migrate.
Several years afterwards, I found myself with hundreds of auto-generated passwords managed by my password manager. I had also been able to convince the people I care about to go through that journey too. I was really happy about it.
What If My Vault Gets Breached?
If hackers actually get access to my plaintext passwords, I will be in a world of hurt. I do have MFA enabled on anything important, but MFA-anyway is notoriously hard to pull off. Just thinking about rolling all those passwords manually gives me a headache. I don't see myself being able to convince my family to do it for their accounts too.
In short, this scenario would be catastrophic.
Wait, Didn't Your Password Manager Just Get Breached?
Well yes, most definitely. One colleague who chose LastPass on my advice recently asked me two questions after reading a concerning article. What happened? and How should he react?
My answer for the first question couldn't be worse. Hackers compromised both code and data. Data contains our vaults, with plaintext metadata including email addresses and our encrypted passwords.
My answer to the second question was very different. There is no indication of the hackers stealing master passwords by abusing the client. We can assume that didn't happen or we would see a whole host of reproductions across the industry. So if your master password is strong enough not to be cracked and you have MFA on everything that matters, you are fine. If you still feel iffy, roll your important passwords.
Concrete steps to take if you were affected by the breach:
- Roll your master password.
- Enable MFA and roll passwords everywhere that matters.
- If your master password was weak, I strongly advise you to roll all of your passwords.
How Can That Be? Aren't Those Answers Contradictory?
The seemingly contradictory nature of these two answers shows just how powerful avoiding storage of sensitive data is.
LastPass got breached. Repeatedly. Attackers took everything there is to take. The impact is severe, but not catastrophic at least given what we know now. That's a brilliant property of the system's design.