Popular password management company LastPass has been under the pump this year, following a network intrusion back in August 2022.
Details of how the attackers first got in are still scarce, with LastPass’s first official comment cautiously stating that:
[A]n unauthorized party gained access to portions of the LastPass development environment through a single compromised developer account.
A folllow-up announcement about a month later was similarly inconclusive:
[T]he threat actor gained access to the Development environment using a developer’s compromised endpoint. While the method used for the initial endpoint compromise is inconclusive, the threat actor utilized their persistent access to impersonate the developer once the developer had successfully authenticated using multi-factor authentication.
There’s not an awful lot left in this paragraph if you drain out the jargon, but the key phrases seem to be “compromised endpoint” (in plain English, this probably means: malware-infected computer), and “persistent access” (meaning: the crooks could get back in later on at their leisure).
2FA doesn’t always help
Unfortunately, as you can read above, two-factor authentication (2FA) didn’t help in this particular attack.
We’re guessing that’s because LastPass, in common with most companies and online services, doesn’t literally require 2FA for every connection where authentication is needed, but only for what you might call primary authentication.
To be fair, many or most of the services you use, probably including your own employer, generally do something similar.
Typical 2FA exemptions, aimed at reaping most of its benefits without paying too high a price for inconvenience, include:
- Doing full 2FA authentication only occasionally, such as requesting new one-time codes only every few days or weeks. Some 2FA systems may offer you a “remember me for X days” option, for example.
- Only requiring 2FA authentication for initial login, then allowing some sort of “single sign-on” system to authenticate you automatically for a wide range of internal services. In many companies, logging on to email often also gives you access to other services such as Zoom, GitHub or other systems you use a lot.
- Issuing “bearer access tokens” for automated software tools, based on occasional 2FA authentication by developers, testers and engineering staff. If you have an automated build-and-test script that needs to access various servers and databases at various points in the process, you don’t want the script continually interrupted to wait for you to type in yet another 2FA code.
We have seen no evidence…
In a fit of confidence that we suspect that LastPass now regrets, the company initially said, in August 2022:
We have seen no evidence that this incident involved any access to customer data or encrypted password vaults.
Of course, “we have seen no evidence” isn’t a very strong statement (not least because instransigent companies can make it come true by deliberately failing to look for evidence in the first place, or by letting someone else collect the evidence and then purposefully refusing to look at it), even though it’s often all that any company can truthfully say in the immediate aftermath of a breach.
LastPass did investigate, however, and felt able to make a definitive claim by September 2022:
Although the threat actor was able to access the Development environment, our system design and controls prevented the threat actor from accessing any customer data or encrypted password vaults.
Sadly, that claim turned out to be a little too bold.
The attack that led to an attack
LastPass did admit early on that the crooks “took portions of source code and some proprietary LastPass technical information”…
…and it now seems that some of that stolen “technical information” was enough to facilitate a follow-on attack that was disclosed in November 2022:
We have determined that an unauthorized party, using information obtained in the August 2022 incident, was able to gain access to certain elements of our customers’ information.
To be fair to LastPass, the company didn’t repeat its original claim that no passwords vaults had been stolen, referring merely to “customers’ information” being pilfered.
But in its previous breach notifications, the company had carefully spoken about customer data (which makes most of us think of information such as address, phone number, payment card details, and so on) and encrypted password vaults as two distinct categories.
This time, however, “customers’ information” turns out to include both customer data, in the sense above, and password databases.
Not literally on the night before Christmas, but perilously close to it, LastPass has admitted that:
The threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service.
Loosely speaking, the crooks now know who you are, where you live, which computers on the internet are yours, and how to contact you electronically.
The admission continues:
The threat actor was also able to copy a backup of customer vault data.
So, the crooks did steal those password vaults after all.
Intriguingly, LastPass has now also admitted that what it describes as a “password vault” isn’t actually a scrambled BLOB (an amusing jargon word meaning binary large object) consisting only and entirely of encrypted, and therefore unintelligible, data.
Those “vaults” include unencrypted data, apparently including the URLs for the websites that go with each encrypted username and password.
The crooks therefore now not only know where you and your computer live, thanks to the leaked billing and IP address data mentioned above, but also have a detailed map of where you go when you’re online:
[C]ustomer vault data […] is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.
LastPass hasn’t given any other details about the unencrypted data that was stored in those “vault” files, but the words “such as website URLs” certainly imply that URLs aren’t the only information that the crooks acquired.
The good news
The good news, LastPass continues to insist, is that the security of your backed-up passwords in your vault file should be no different from the security of any other cloud backup that you encrypted on your own computer before you uploaded it.
According to LastPass, the secret data it backs up for you never exists in unencrypted form on LastPass’s own servers, and LastPass never stores or sees your master password.
Therefore, says LastPass, your backed-up password data is always uploaded, stored, accessed and downloaded in encrypted form, so that the crooks still need to crack your master password, even though they now have your scrambled password data.
As far as we can tell, passwords added into LastPass in recent years use a salt-hash-and-stretch storage system that’s close to our own recommendations, using the PBKDF2 algorithm with random salts, SHA-256 as the internal hashing system, and 100,100 iterations.
LastPass didn’t, or couldn’t, say, in its November 2022 update, how long it took for the second wave of crooks to get into its cloud servers following the first attack on its development system in August 2002.
But even if we assume that the second attack followed immediately but wasn’t noticed until later, the criminals have had at most four months to try to crack the master passwords of anyone’s stolen vault.
It’s therefore reasonable to infer that only users who had deliberately chosen easy-to-guess or early-to-crack passwords are at risk, and that anyone who has taken the trouble to change their passwords since the breach announcement has almost certainly kept ahead of the crooks.
Don’t forget that length alone is not enough to ensure a decent password. In fact, anecodal evidence suggests that 123456, 12345678 and 123456789 are all more commonly used these days than 1234, probably because of length restrictions imposed by today’s login screens. And remember that password cracking tools don’t simply start at AAAA and proceed like an alphanumeric odometer to ZZZZ...ZZZZ. They try to rank passwords on how likely they are to be chosen, so you shold assume they will “guess” long-but-human-friendly passwords such as BlueJays28RedSox5! (18 characters) long before they get to MAdv3aUQlHxL (12 characters), or even ISM/RMXR3 (9 characters).
What to do?
Back in August 2022, we said this: “If you want to change some or all of your passwords, we’re not going to talk you out of it. [… But] we don’t think you need to change your passwords. (For what it’s worth, neither does LastPass.)”
That was based on LastPass’s assertions not only that backed-up password vaults were encrypted with passwords known only to you, but also that those password vaults weren’t accessed anyway.
Given the change in LastPass’s story based on what it has discovered since then, we now suggest that you do change your passwords if you reasonably can.
Note that you need to change the passwords that are stored inside your vault, as well as the master password for the vault itself.
That’s so that even if the crooks do crack your old master password in the future, the stash of password data they will uncover will be stale and therefore useless – like a hidden pirate’s chest full of banknotes that are no longer legal tender.
While you’re about it, why not take the opportunity to ensure that you improve any weak or re-used passwords in your list at the same time, given that you’re changing them anyway.
One more thing…
Oh, and one more thing: an appeal to X-Ops teams, IT staff, sysadmins and technical writers everywhere.
When you want to say you’ve changed your passwords, or to recommend others to change theirs, can you stop using the misleading word rotate, and simply use the much clearer word change instead?
Don’t talk about “rotating credentials” or “password rotation”, because the word rotate, especially in computer science, implies a structured process that ultimately involves repetition.
For example, in a committee with a rotating chairperson, everyone gets a go at leading meetings, in a predetermined cycle, e.g. Alice, Bob, Cracker, Dongle, Mallory, Susan… and then Alice once again.
And in machine code, the ROTATE instruction explicitly circulates the bits in a register.
If you ROL or ROR (that denotes go leftwards or go rightwards in Intel notation) sufficiently many times, those bits will return to their original value.
That is not at all what you want when you set out to change your passwords!
WHAT IF MY PASSWORD MANAGER GETS HACKED?
Whether you’re a LastPass user or not, here’s a video we made with some tips on how to reduce the risk of disaster if either you or your password manager were to get hacked. (Click on the cog while playing to turn on subtitles or to speed up playback).
WHY ‘ROTATE’ IS NOT A GOOD SYNONYM FOR ‘CHANGE’
Here’s the ROTATE (more precisely, the ROL) instruction in real life on 64-bit Windows.
If you assemble and run the code below (we used the handy, minimalistic, free assember and linker from GoTools)…
…then you should get the output below:
Rotated by 0 bits = C001D00DC0DEF11E Rotated by 4 bits = 001D00DC0DEF11EC Rotated by 8 bits = 01D00DC0DEF11EC0 Rotated by 12 bits = 1D00DC0DEF11EC00 Rotated by 16 bits = D00DC0DEF11EC001 Rotated by 20 bits = 00DC0DEF11EC001D Rotated by 24 bits = 0DC0DEF11EC001D0 Rotated by 28 bits = DC0DEF11EC001D00 Rotated by 32 bits = C0DEF11EC001D00D Rotated by 36 bits = 0DEF11EC001D00DC Rotated by 40 bits = DEF11EC001D00DC0 Rotated by 44 bits = EF11EC001D00DC0D Rotated by 48 bits = F11EC001D00DC0DE Rotated by 52 bits = 11EC001D00DC0DEF Rotated by 56 bits = 1EC001D00DC0DEF1 Rotated by 60 bits = EC001D00DC0DEF11 Rotated by 64 bits = C001D00DC0DEF11E
You can change the rotation direction and amount by changing ROL to ROR, and adjusting the number 4 on that line and the following one.
