LastPass finally admits: Those crooks who got in? They did steal your password vaults, after all…

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 follow-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 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 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, for instance, logging on to email 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.
• Requiring 2FA only for the first login from a new device, such as a new mobile phone. This minimises the number of times you need to go through the 2FA process yourself, while nevertheless preventing crooks from simply trying out your passwords on their own devices.

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 intransigent 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 password 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 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 amusingly descriptive 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” above certainly imply that URLs aren’t the only personal data that the crooks can now read out directly, without cracking any passwords.

The good news

The good news, LastPass continues to insist, is that the security of the 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 password 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, LastPass master passwords set up in recent years use a salt-hash-and-stretch password generation system that’s close to our own recommendations, using the PBKDF2 algorithm with random salts, SHA-256 as the internal hash, 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 2022.

But even if we assume that the second attack followed immediately and 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 assume that only users who had chosen easy-to-guess or early-to-crack passwords are at serious risk, and that anyone who has taken the trouble to change their passwords since the initial breach announcement has probably kept ahead of the crooks.

Don’t forget that length alone is not enough to ensure a decent password. In fact, anecodtal 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 should 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 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 in your old vault will be stale and therefore useless – like a hidden pirate’s chest full of old banknotes that are no longer legal tender.

However, you should change your master password first, before changing any passwords inside the vault, as a way of ensuring that any crooks who may already have figured out your old master password can’t view any of the new passwords in your updated vault.

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?

Please 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 (machine code mnemonics that denote rotation thats goes leftwards or goes rightwards in Intel nomenclature) 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 assembler and linker from GoDevTool.com)…

…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.