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
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.
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’
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
ROR, and adjusting the number
4 on that line and the following one.
109 comments on “LastPass finally admits: Those crooks who got in? They did steal your password vaults, after all…”
LastPass needs to disclose what fields are actually encrypted. Are the notes in the password vault encrypted? They only mention secure notes which live elsewhere. Also be aware that the bad actors have all the customer data you mention plus the URLs of every site in your password vault. Those are not encrypted. Nice helping hand the to credential stuffers!
Good point. I have amended the article to make clear that what LastPass has been referring to since August 2022 as “password vaults” that it stores in the cloud might not be *quite* what you and I might infer from the specific word “vault”.
(I think of a vault as a secure-by-design space with secure walls, ceiling and floor, and a secure door on the front, as you see in the featured image at the top of the article. I picture that door, when closed and locked, as sealing off *the entire vault*, as a matter of definition. If there’s a less-secure lobby area or an anteroom outside, where you can wait while the vault is opened… I wouldn’t call that part of the vault. In fact, I’d take pains to point out to my customers that the anteroom was just that – an anteroom – and most definitely not part of the vault itself!)
Thanks for the comment.
LastPass actually did say some data inside the customer vaults was stolen in clear text. And it is pretty bad. And their notice is deliberately vague in places but unambiguous on the whole. The stolen backup data was behind a two part key, and the attacker obtained both parts, which is how they were able to access the vault data from LastPass’ backups. The Vault backups were stored encrypted at rest with keys in LastPass’ possession, and those keys were stolen.
“The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which 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 … The encryption and decryption of data is performed only on the local LastPass client. ”
… meaning the parts listed as unencrypted there were Never encrypted. Apparently LastPass does not consider URLs to be sensitive because those are among the Vault data that is NOT encrypted by LastPass Vaults, stated above.
They go on to warn that since the attacker knows Who you are, Where you live, Your phone number likely associated with various 2FA, Your email address likely associated with various 2FA, Your public IP address, Where you work, and other metadata they are too embarrassed to disclose, AND the URLs and names of the online services you stored in LastPass, all LastPass customers are at severe phishing risk:
“The threat actor may also target customers with phishing attacks, credential stuffing, or other brute force attacks against online accounts associated with your LastPass vault.”
So the attackers may not know your password, but they know what services you have accounts at, and since they know your email addresses, they know most of your usernames anyway.
I didn’t see any admission that “at rest” keys were stolen. Was there one?
You don’t need “at rest” decryption keys if you have (say) authenticated API access into the secure-at-rest data. Same reason why full disk encryption on your laptop is great if the crooks take your hard disk out when the laptop is off and try to crack it in another PC, but not much use if they grab your laptop while it’s open and running… all the encrypted data gets transparently unscrambled when they access it
This part here: “To date, we have determined that once the cloud storage access key and dual storage container decryption keys were obtained, the threat actor copied information from backup that contained”. Backups were sitting in cloud based object storage, encrypted, but the backup data encryption keys (plural) and the API key for accessing the backups were all stolen. Unless I’ve misread or misunderstood that. They did scatter the important bits all around the writeup on purpose after all.
The lastpass update says: “Your sensitive vault data, such as usernames and passwords, secure notes, attachments, and form-fill fields, remain safely encrypted based on LastPass’ Zero Knowledge architecture. There are no recommended actions that you need to take at this time.”
They did previously say that there was no need to worry about customer data or your password vaults having been stolen, too.
Then they said, well, maybe some customer info was stolen. Then they said, well, when we said customer info we meant password vaults, too. And they said, well, when we said “vaults” we meant “general stuff including unencrypted data”, in case you had assumed the “vault” implied “locked up securely”.
So even though they are now saying it’s not recommended to do anything, well, that doesn’t mean you should feel compelled not to do anything 🙂
I am not a LastPass user but if I were I would change my own passwords. Seems like a small hassle with little or no downside…
I sure as Hell, Wouldn’t be using Last Pass to store my NEW passwords, or User name, which I would definitely be swapping out too! Probably consider a change of phone number too, since I can’t readily change my home address! What a fricken nightmare! I’m glad I opted for KeePass way back when. Last Pass has ruined any credibility they might have once had IMHO!
Yes, it’s stupid not to encrypt the URL fields, makes it easier to select which accounts are the best targets to crack (large company remote server access).
My main concern is that situations like this make it harder to convince the general population to use credential management tools at all — and that’s a real problem. I think the overall message needs to remain really clear:
Using a reputable password manager where all technical documentation states that your information is only ever available to the hosting company in encrypted form is still a FAR BETTER option than any password-saving/remembering technique than almost any of us could come up with alone.
I also think that password management companies could get better at building very clear “if we ever get hacked, this is what we will do and this is what you should do” documentation and functionality right into their solutions. If I know that I’ll get an email and a big loud alert in the product to change my master password and/or my individually saved passwords depending on the situation, I’ll feel better about it.
Not mentioned in all of this is the saving of other text-based information, like account numbers, answers to “security questions,” ID, payment info, and other sensitive stuff that people might save in their password management tools. If an old master password gets cracked by the nefarious criminal and one’s vault is decrypted, I assume all that harder-to-change info is also revealed. That’s maybe worth thinking about in addition to the passwords. I’m not a LastPass user, so I don’t know the specifics of what could be in someone’s vault in this case, but it’s another consideration.
But despite all that, reputable password managers are still a hugely valuable thing!
Happy holidays, all!
Agreed. We looked at this for Data Privacy Day a while back (from the length of my hair in this video, it must have been about 1/3 of the way between the start of the coronvirus pandemic and today, hahaha):
Is Google Password Manager reputable? It is really convenient autofilling from the browser, but would it be considered similarly secure as LastPass (LastPass prior to the recent hack of course).
Depends on how much you trust Google to run your digital life.
As far as I know, the Google Password Manager is tied to your Google Account plus one of both of Android or Chrome…
…given that I have none of those three things in my regular digital life, the “choice” is easy for me.
Anyway, my inclination is like that of several previous commenters: I use a local password storage solution and backup my password vault as a genuinely fully-encrypted BLOB, as I would back up any encrypted data.
Personally, I have numerous passwords and secrets that I need on my laptop but outside my browser, and when not online. So a password manager tied to an online account *and* a browser is definitely you my cup of tea. Your mileage may vary.
Thanks for taking the time to reply. Great article and information 🙂
You could secure your Google passwords/browsing-Data with 2 passwords + 2FA and Hardware-Keys.
You can secure your main Google account with a password and 2FA/Hardware-Keys and your browsing-data/passwords with another password, encrypting them even against Google viewing the data. All Google and the attacker sees is the number of bookmarks and passwords you have, assuming the attacker broke into your account.
The only downside is if the attacker successfully got into your Google account and is a dick, they can just wipe everything clean with a single click once they get salty and realize that after going through all that trouble, they still can’t access your passwords.
“Rotating” sounds so much more professional than “changing”. Anyone can change a password, but “password rotation” makes it sound like you need to bring in an expert.
OTOH when I worked for an organization that called for quarterly password changes, rotating the leading or trailing digit is exactly what many people did.
Why use the right word when you can use deliberately use the wrong one and then tell everyone who’s confused that they’re just not technical enough 🙂
I didn’t say so in the article (perhaps I should have) but I suspect you are right when you allude to the history of the term “password rotation” being that it literally was how people used to do password changes.
(That’s why some password systems still keep your last N hashes so they can stop you switching endlessly between a small number of passwords you have already memorised. Back in the 1990s, when “forced rotations” were a thing, loads of people would simply change their password twice on the first day of the month – once to ‘qwertyuiop’ and then straight back again to the password they had before. Or, as you say, they would go through ‘nameofcat-1’, -2, -3… -8, -9, -1. (Programmers would include -0, of course.)
And people would often use a two digit trailing number indicating the month, when monthly password changes were required…
Is there a password manager that you do recommend?
Don’t know what to say any more. I’ve just aimed people at various market leaders until now.
Better give me until the New Year to think about that one…
Ummm, Heloooo? Sophos Intercept X promotes KeePass in it’s app. Personally, I was using it long before Intercept X though. I also use the open source KeePass client, KeePass 2 for Android. Which is very good too.
Well, that’s not inconsistent with my reply saying, “Don’t know what to say any more. I’ve just aimed people at various market leaders until now. Better give me until the New Year to think about that one.” (The OP asked what I’d recommend.)
To be precise, our mobile app doesn’t exactly *promote* KeePass (at least, I don’t *think* it does, though I must admit, ahem, I have never RTFM). It’s compatible with KDBX (KeePass Database) files, because that’s a well-known open source password file format, but that’s not quite the same as promoting the app.
If you really want to, you can take our choice of KDBX as a kind of “neutral acknowledgement” of sorts…
…but the OP asked what I would recommend, and as I don’t myself use KeePass (or, for that matter, LastPass), I can’t very well say, “KeePass is great; you shpould use it.”
(The reasons I didn’t jump in and recommend our own product here, which some people might have expected to see, is  it’s a mobile privacy and anti-virus tool that includes a password vault function as a handy option, not really a password manager app;  the Password Safe function is only available on mobile devices, which isn’t much help if you want to secure your desktop browsing;  this sort of article isn’t really the right sort of place to start trumpeting our own product. Having said that, your comment gave me a reason to sneak in a mention that Sophos Intercept X for Mobile does, indeed, include basic Password Safe functionality if that would suit your needs :-)
I don’t trust anything on the Internet as being secure. I use Keepass. It runs on your computer, it is free and a portable app. I have been using it for years. The database is encrypted and stored on your local computer. I can use a thumb drive to unlock the database. Once you pull your thumb drive from the computer the database locks.
I store a copy of the database on dropbox so I can use it off any computer anywhere ( but never open it from the dropbox folder) I copy it down, use and/or edit it, then copy the new version (if any changes were made, back to dropbox. The database file can be named anything you want, for instance “tempfile”
Best of all Keepass is free. I have been using it for about 15 years.
There’s a bit of a contradiction here between saying that you “don’t trust anything on the internet as being secure” and “I store a copy of the database on Dropbox”…
…but I think I get your point.
You’re using your Dropbox cloud storage indirectly, merely as a general sort of encrypted backup, rather than as an integrated, real-time part of a password manager app, where there is a greater chance of coding blunders or bugs that could leak the right memory buffer (e.g. the part that temporarily holds a decrypted password) to the wrong part of the code (e.g. the part that uploads an unencrypted log entry to the cloud server).
I am inclined to your view, especially if the password manager relies on an application that asks for your master password in one part of its code, retrieves your encrypted passwords in another part of its code, does the password decryption locally in a third part of its code…
…and blithely promises you those three functions will never (accidentally or otherwise) mix anything up.
Paul, I have seen a lot of comments like Ron’s saying they use KeePass but use [insert cloud storage provider here] for syncing. To me this doesn’t make a lot of sense.
If you’re going to use a password manager, why wouldn’t you trust their software and cloud infrastructure to hold the data instead of a third-party cloud provider who has either been breached before themselves (Dropbox) or can access your cloud storage data themselves because it’s not “zero-knowledge” encrypted?
Someone like BitWarden has a lot more incentive to keep my password vault secure than these third party providers. Without that trust, they are worthless. However, Dropbox can get breached and survive because people use it for more than storing a password vault.
If you encrypt a BLOB, any BLOB (containing passwords or not) offline and later upload it to Dropbox (or anywhere else of that sort), then it is “zero-knowledge” protected because you never share your password with Dropbox, or any part of Dropbox’s code, app, system, website, etc.
Dropbox can access your uploaded BLOB (just as LP can, or its attackers did), but the company doesn’t know anything about the content of file or how to peek inside it.
That was what LP led people to believe, too, though it turned out (see Cassandra’s various comments above) that some of the data in those “zero knowledge” BLOBs was not even encrypted, and LP not only could read it but relied on doing so in order to index the other half of the data, which was encrypted.
Yes, you inevitably increase your risk by storing your password BLOBs on other people’s computers, whether Dropbox’s, your brother’s, or LastPass’s. If that worries you then keep the vault on your own device and back it up on a USB drive and lock that in a safe deposit box… but always keep that vault encrypted!
“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.”
Oh, Joy! Looks like I’ll be working on this for most of the Christmas weekend. And likely the next step is to find a new PW manager that is local ONLY. Don’t quite trust the browser PWMs (Brave, Edge, FF).
The downside is… Christmas weekend! Who wants IT work?
The upside is… Christmas weekend? Maybe I’ll have some time to work on my own IT for a change.
Here’s the ASM source in text form, as requested. I hope that WordPress doesn’t ruin the formatting:
To build with the Go Tools programs (you only need GoAsm.exe and GoLink.exe):
My management team asked me to look into password software to help all 150 staff I support in their password management needs. Many times I pushed back and didn’t want to delve into this because:
1) I don’t have the resources right now to research and support this new initiative and
2) I didn’t understand why most companies believe storing passwords in the cloud is secure (encrypted or not)
Thankfully, I haven’t done anything and will not!
My suggestion will be for staff to have a local file (password protected) on their computers or phones and ensure it’s not saved to a cloud drive anywhere.
Old school as I may be or think, having a piece of paper ‘hidden’ at home is far safer than organized hackers from finding out passwords from a vulnerable device or cloud account.
My two cents!
Two problems with telling users to take the DIY approach:
1. That local file will end up getting backed up into the cloud sooner or later, either by accident or design.
2. That local file will need decrypting every time a password is needed, so users will routinely have *all* their passwords decrypted when they really only need one of them in cleartext in memory at a time.
3. That local file won’t stop users pasting the right password into the wrong site when a believable phishing email arrives.
4. That local file will get copied-and-pasted from all the time, and sooner or later a user will forget what’s in the clipboard and paste a password where it really shouldn’t go.
5. That local file will end up copied into a secret secondary location and left decrypted all the time, because “efficiency”.
6. That local file may end up using the “encryption” built into a user’s favourite text editor or standalone organiser app, and that may be weaker than you would like.
7. That local file may end up on GitHub (or one of zillions of other online services), because that sort of thing “just happens”.
8. That local file will not force or even assist your users to choose decent passwords, and to make each one different.
9. That local file may end up on someone else’s computer because that was the “easiest” way of telling a new employee an existing password.
10. That local file will get stolen every time you have a malware incident, or at least you should assume that will happen.
Hmmm, those two problems I started with turned into 10 pretty quickly…
…I recommend seeking out a dedicated password manager that is designed to work purely locally, if that’s really what you want.
(Given that good backup rules suggest “keep a spare backup that’s offline and offsite”, for obvious reasons, you should expect password databases to get backed up at some point.)
KeePass 2 for Android has its own built-in keyboard for credentials transfer, no using clipboard unless your sloppy, and I think there’s some form of protection for clipboard on more recent versions of Android. Also, it offers local storage only, if preferred. I don’t use desktop/laptop, but, if I’m not mistaken, what’s available to other platforms can be local only too.
I once changed my work password before going on a long holiday because we had to change our passwords every month. I *saved* the password on a piece of paper in my wallet. Enjoying my holiday, I saw the paper and threw it away….
“Never change your work password at the end of the day.”
Last Pass makes it impossible to delete your account. I end up in an endless loop of frustration. I can’t even find their contact email. I don’t want to store my passwords in cyberspace anymore. What do you suggest?
Any LP users out there with suggestions?
I just deleted my account the other day (by coincidence). The instructions are a little annoying to find online, but once you do find them, if you just go through the steps one by one, you’ll eventually get a confirmation that your account has been deleted. Not that this secures any data compromised before you deleted your account.
I assume this is from a third Paul, not Ducklin nor Dodd.
It is not I. My replies always say “Paul Ducklin” (injected automatically by WordPress); I never have had a LastPass account to close; and my replies tend, how can I put this while remaining polite to myself, ahem, tend to be longer.
Not sure if this is the most efficient way, but this is how I deleted my LastPass account. Log in, click on Account Settings. Partway down the page there is a section called Account Information. In one of those sections there is a subsection called My Account. If you click on that, it will bring to to another page that has your account status. Find the section called Existing User, to the right of it there is a button that says Delete or Reset Account. Click on it, enter your master password, and then click through the multiple warnings about how this is permanen t(duh).
I’m done with LastPass. They had one job and they royally screwed it up. As a “security” firm, they should be ashamed, and frankly, they should just shut down. Why anyone would continue to use them after this is beyond me.
Why would changing the master password do anything? Isn’t it static in the backup that was stolen? Bottom line is lastpass needs to inform customers directly if their data was stolen and the customers need to change every password and key in the vault, including the master password. And I agree with someone who said if I had to change every password, I would be changing password managers while I was at it.
Well, changing the master password would ensure that if the crooks crack your old one they don’t know the new one. Otherwise if they did get lucky with your password, then they could target you for your new password database (they now know who you are) in some other way, e.g. data stealing malware, and then they would know all your new passwords as precisely as they knew your old ones.
Unlikely, yes. Impossible, no. So why not change everything?
If you *don’t* change your master password first, then the crooks can also access your new changed passwords….
Of course it won’t save you changing all the stored passwords as well.
Rotation comes from latin rotare, act of rotating or turning, action of moving round a center,” “a turning about in a circle”. To any Spanish, Portuguese, Italian, etc latin-origin language speaking person, it’s quite obvious that rotate implies eventually repeating. So I definitely agree that password rotation is not a good word choice. Maybe password renewal.
Good point – “rotation”, as in what the earth does on its axis, such that every night is followed by another day.
By the way, “renewal” is not IMO the right word because it implies continuity, not change – when you renew your vehicle tag, you don’t get a new number or a new plate, you just get a new sticker (or even just a cloud-based update, as in the UK, where we no longer have discs, tags, stickers, seals or any physical proof of payment).
A “renewed” password would essentially just be the old one reactivated.
I think “change” is the word to use. It pretty much demands that the new one be different…
Unfortunately, the video didn’t really answer the question about if your password manager gets hacked. If the bad guys have the files (which apparently, they do) does 2FA whether it be authenticator codes or something else like yubikey, add any extra security?
The answer to that is (I’m sorry about this!) is, “It depends.”
For quite a few online accounts, even if you have 2FA set up in the least intrusive, softest sort of way, the answer is that 2FA will help to keep the crooks out, assuming that they try to use your hacked password from a computer or a mobile device of their own. A new device typically forces 2FA, even if the 2FA codes are suppressed once the new device is registered to your account. (Pretty sure that’s how Facebook does it by default,)
I try to ensure that I set up 2FA, wherever possible, in “always bug me for a one-time code” mode; I always make an effort to ensure that I don’t tell sites to “remember me” in my browser; I try to remember to logout explicitly as often as I can; and I have set up Firefox and Edge so they always forget all my cookies every time I exit.
Loosely speaking, the more willing you are to expect, accept, and satisfy 2FA requests, and the more careful you are not to choose options like “remember me for 21 days” or “keep me logged in”, the more that 2FA can do to protect you against crooks who only know your username and password, because the less likely it is that they’ll be able to sneak in with those two bits of data alone.
2FA is far from a panacea (and it’s not an excuse for picking poor passwords, either!), and the crooks have plenty of tricks for bypassing it (e.g. calling you up, convincing you that they are from site X, bank Y, or application Z, and “helping” you to perform some “security enhancement action” by talking you through the “new” process, phishing you for all the needed data at one go, or just phishing for the 2FA code if they’ve already got your username and password).
But 2FA can help, by adding a little bit of hassle for you in return for a lot of extra hassle for the crooks.
Yes, 2FA adds extra security for the saved accounts, if they have it, but not for the password manager master password. I would still change all the saved passwords and as they say in the article, the master password first.
The 2FA only guards against front-end application logins. Google, Yubikey, etc. 2FA are completely unrelated to and disconnected from actual password database file on your computer (and that LastPass has a copy of, what was stolen here). 2FA is a sort of gatekeeper preventing unknown people from getting a hold of that database file.
When you download the lastpass app on a new device and try to log in, you don’t have that encrypted database yet and LastPass won’t give it to you until you authenticate to them with your 2FA. After the 2FA login they send the device the password database, and now the only protection that the database has from an informed attacker with direct access to that file on the device is an encryption key which is derived from your master password.
Takeaway: 2FA is used to prevent someone from shoulder-surfing or guessing your password to get your data on their own device. 2FA is a critically important security measure but this is Not the type of attack that it intended to protect you from. The badguys sidestepped the 2FA because they didn’t have to log into your account to get the your database – they just stole it directly from LastPass’ servers.
The guy who said that incidents like this will keep the non-technical general public (like me) from adopting password managers is spot on. I understood hardly anything of what you guys were talking about. I’m glad I’m not in the workforce anymore. Most employers don’t give much help to non-techies because it costs money. My 63 passwords are written on a list in a drawer under my computer where the burglar who has been predicted for 30 years can find them.
My partner had finally convinced me to start using LastPass this summer after years of nagging. I had an elaborate system of different email addresses, usernames, and memorized passwords that I never wrote down. I just had a “hint” spreadsheet. The system had worked well for about a decade but had completely broken down in the last few years. My hint sheet had become a long list like “email #6 with favorite old username #4 and PW#5 with special character at the end”. Between constantly having to change PWs at various sites because of hacks and needing to create long PWs with special characters, my poor brain couldn’t handle it anymore. I kept telling my partner “What if LastPass gets hacked?” and he convinced me it was a low risk. After going through all the hassle of changing all my PWs with LastPass, I was feeling pretty happy with it.
LastPass project started at LogMeIn. That knowledge alone made LastPass ineligible to doing business with us. I was questioned by the management about it, and I stood my ground. As it turns out, I was right.
LastPass was bought by LogMeIn, IIRC, not started there.
Presumably the key vaults are decrypted on LastPass servers prior to being rendered in the browser/relayed to the LastPass extension? In this case there would be at least two possible avenues a threat actor could theoretically utilise to obtain plaintext credentials:
1) Access to the memory of the LastPass servers responsible for decrypting the vaults
2) Intercepting requests sent from the decrypted vaults to the LastPass extension/browser page.
With the leaked source code a skilled threat actor could put the pieces together to achieve these goals. It’s getting way too close for comfort now!
No, that’s not how it works.
According to LastPass, your master password is never shared with LastPass’s servers – the passwords are encrypted locally before being uploaded to the cloud, and when you want to use them they are supplied to your browser in encrypted form and only decrypted at your end.
I will admit that my original assumption was that the entire vault was encrypted, so that the whole thing would be downloaded in order to be used. But it turns out that the website names in the vault are unencrypted, presumably so that LastPass can find and send just one encrypted password at a time instead of sending you the entire encrypted vault for every password.
That last paragraph is puzzling. The diagram of their “Zero Knowledge Architecture” rather implies that entering your password enables the downloading of the entire vault giving you a local “vault” (unencrypted?). Presumably when you require a password it is “served” from this local copy – how else would it work when LastPass servers are off-line (which is not unknown, “due to maintenance”)?
The idea of submitting URLs to LastPass and that enabling them somehow to index into “the (server-side & encrypted) vault” to return something that is only decrypted locally, does not sound like “Zero Knowledge Architecture”.
Their latest announcement claims:
1. “contains both unencrypted data, such as website URLs,” – and what else?
2. “as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.” – Does that mean that when you “open your vault” and select an item and you see the edit form that “everything” filled in through that form is fully encrypted? (Except for some reason the URL – which is part of the “form-filled data” – is that a nasty bit of unravelling of their story?)
3. Are the note fields on the password “form-filled data” form – as opposed to “secure notes” (a different beast) fully encrypted? Because that is the place for me to record the random “memorable answers” to the challenge questions that some websites still use. It is also where I store data beyond the “password” from which some websites ask for say the “2nd, 5th and penultimate characters”. If the note fields are treated like the URLs, that is more unravelling.
This is a worrying situation that really requires some good investigative journalism – by a journalist who is tech and security savvy. I suspect that Sophos as a security site rather than a journalism outlet feel that is somewhere where they are reluctant to go (glass houses etc.)
Meanwhile working through my passwords in some form of priority order (hosting, recovery emails, finance, e-commerce, personal identity sensitive, other etc.) and changing them is proving to be a real PITA on Christmas Eve – bet the bad guys are not “Christians” who celebrate Christmas with a day off!
I wondered about that “zero-knowledge” thing, too. “We know nothing about your data except half of it” is what the system sounds like to me. Along with, “And we aren’t going to tell you which half.”
(Maybe the two halves – their known known and your known unknown – somehow magically cancel out and that’s where the “zero” comes in?)
Don’t think that is a good reason for not encrypting the URIs. LastPass locally could request the encrypted vault record from the served matching a hash of the encrypted URI. Perhaps the URI can be encrypted using a hash of the master password and a different algorothm to avoid too much delay on the client, instead of the full master password. I’m sure there are better ideas.
So there is a good chance that the crooks could (can?) read enough data to know the websites you use. Can they writeto that data to for instance change a website URL to a close match to assist with a phishing attack?
Good question – I guess that only LastPass can answer it, based on what their logs show. Did the crooks access the password vault data via an API or directly? Did the access method they use support writing? If so, did they do any writes? LastPass hasn’t said anything about *modification* of vault data, so we can’t say if that’s because they are trying to work out if it happened but don’t yet know; have worked it out and aren’t saying; haven’t yet looked but are planning on doing do; haven’t looked and don’t intend to; or haven’t looked because they haven’t yet had your insight that they ought to :-)
If we assume that the crooks could change individual fields in individual vaults at will (and for all we know they may have had access for close to four months, depending on when they may the “lateral jump” from the development system to the cloud data server – the jump that LastPass initially said was not possible)…
…then they could, as you say, use this for phishing.
For example: change the URL of some, many or all users who have a specific website listed in their vault; then phish those specific users by email using the modified URL as their lure (after all, the crooks do have email addresses to go with each vault); and hope that at least some of the users fall for the phish and believe it because their password manager apparently “recognises” the fake site.
Basically, such an attack would trick the password manager into “endorsing” the phish, by implying that the URL you clicked must be legitimate, and thus trick you into clicking “Yes” to submit the decrypted password to the fake site.
My gut feeling is that this would be rather noticeable to do in a widely-distributed phish, because anyone who didn’t fall for the phish (or who never received it, say due to a good spam filter) would no longer be able to login to the real site, and this might draw attention to the situation. But in a more targeted attack against a chosen set of users, you can imagine it might work well.
You are talking about the “live” vault and whether Bad Guys can go in and make changes? They only have an offline copy of the vault, right? One they grabbed from a backup. I have to assume that all doors to LPs live operational vault data are closed and impenetrable, or am I naive? Of course, once they correctly guess my unguessable master pw that can go in and change whatever they want, I suppose
You write: “I have to assume that all doors to LPs live operational vault data are closed and impenetrable”…
…I think that’s all of us, including LastPass, assumed about every copy of the vault data.
Yet here we are.
I guess that if the crooks ended up with a copy *of a copy* of the “live” data (which the LastPass notification seems to imply) then you are right – any changes they made while they were in would not have been reflected in the live data.
But even if the data they stole was a backup… well, modifying backups is worrying enough, given that backups usually exist so that they can be restored if necessary, thus pushing any bad data in the backup into production.
Thus I think @Cassandra’s question is both interesting and important: did the crooks have write access while they were in (and, by implication, would any unauthorised changes have been reliably detected).
And still no warning that if you have a paid for LastPass account, not only are your customer account details outside the “fully encrypted vault”, but presumably so is the password you use to authenticate your customer account to LastPass for doing things like paying for the service?
Now what could be more logical that making your LastPass customer account password the same as your LastPass Password Vault password?
Looks like a very good reason for using Free versions of password managers and trying to ensure that Zero Knowledge extends to their knowledge of you!
Can you experts tell me something about those password cracking tools? The tool would need to try a login to LastPass for every guess… so doesn’t Lp then block the access when there are too many erroneous tries?
The problem is this – now that the crooks have their own copies of those password vaults…
…they can crack them in their own time, using their own software, on as many computers as they want, without having to rely on LastPass’s servers to grant them access.
The jargon terms here are: “online attack” and “offline attack”.
Generally speaking, in an online attack, such as putting a bank card into an ATM and trying to guess the PIN code, both the rate and total number of guesses can be regulated by the system you’re connecting to. Three wrong tries and the card gets cancelled (and sometimes confiscated, too).
In an offline attack the crooks get as many goes as they want, as fast as they want.
LastPass has made offline attacks hard by choosing a password verification algorithm that is deliberately slow – but LastPass can’t stop well-organised crooks (or government-level attackers) from using 1000, or 10,000, or even 1,000,000 computers at the same time to speed things up.
Each password guess can be tested independently of any other, so that even if one PC could only try one password a second (that’s fewer than 100,000 a day), a million PCs would work 1,000,000 times faster and could therefore try close to 100 billion passwords a day.
The hope is that if your master password is weird and complex enough, then it won’t be in the first 100 billion passwords tried, or even the first 100 trillion…
…which buys you enough time to change all your passwords so that by the time the crooks crack your vault and figure out your list of old passwords (if indeed they ever do), they’re no longer any use.
Makes sense, but didn’t they say that the “good stuff “ , my actual password “vault” , was only stored locally in house and out of reach?
They said (IIRC) that the cloud-based backup vault files included some unencrypted data, e.g. the list of websites that you use, and some encrypted data, e.g. the passwords for those websites.
And *that data was stolen*.
So the answers to your questions are: no, the vault data was not “local to you only”, assuming you had backed it up to the cloud; and, no, it wasn’t “out of reach” of the crooks (although LastPass first thought the crooks hadn’t got at it); and therefore, yes, the Bad Guys are now in possession of the “good stuff” and can crack away at it as hard as and for as long as they like.
If they have the password vaults downloaded, and they crack your master password, then it won’t make any difference if you change your master password now. They will still have access to a snapshot of your entire unencrypted vault at the time of the download. The recommended action would be to change all passwords. In my case, hundreds….
It does make a difference if you change your master password now, because if you don’t then [a] the crooks will still be able to open your new vault and [b] it will be worth them using the personal information acquired in the breach to go after it.
(If crooks crack the combination lock on your bike, drop the lock on the floor and ride off with the bike, you could either buy a new lock because you no longer trust the old one, or change the combo and keep using the old lock. The one thing I bet you wouldn’t do to use the old lock still with the old combo on your new bike.)
I have had occasion to store the password in the notes section. LastPass likes to update things at the wrong time, and will put the old password back in place of the new one. It’s disturbing everything wasn’t encrypted, like I ASSumed it would be. Shame on LP, and shame on them for continuing to not tell us exactly what wasn’t encrypted. Especially worried because those fall back questions in case nothing else is right might be exposed since they are not “Secured Notes” That should have been a clue.
You need an editor. 2002, 2012, or 2022? Typos abound.
Well, I don’t have an editor, or perhaps I should say that I am essentially my own editor, and even editors sometimes miss things like that.
Anyway, I have changed “August 2002” to “August 2022”, which is the typo I think you were referring to.
Thanks for the comment, by the way, though it would have been more helpful if you’d simply said, “Typo in phrase XXXX, should say YYYYY”, rather than writing “typos abound” (I only found one instance of 2002, and none at all of 2012), which suggests there are dozens more that you found but didn’t disclose.
I guess that you’re putting me to the test… so I had better go and read the whole article backwards. (That’s the only trick I know of for proof-reading your own writing, which is notoriously difficult because you know what it’s supposed to say and are therefore prone to “autocorrect” it somewhere between your eyes and the language-processing parts of your brain.)
Who (except trolls) care about minor typos?? I found this article very helpful, and many stteps above what LastPass came up with! I added a minor typo on purpose so that the typo police has something to work on.
Thanks for your kind words.
TBH, I don’t mind being told about typos publicly, because they oughtn’t to happen… and I try to take criticism on the chin if someone not only points out the mistakes but also lays down strong words on the issue.
But it is frustrating when people who have found typos and feel strongly enough to report them don’t bother to identify them so I can fix them to help everyone else…
(A couple of years back I had a report along the lines of “three typos – unacceptable!” and though I quickly found two I never did find the third, though I spent half a Saturday afternoon determined to find it. Either the person has decided to freak me out, or that typo is there to this day.)
Some people just report them in a comment and add [no need to publish] at the end, which is nice, and one loyal reader who prefers anonymity just sends me emails. They also regularly come up with great story ideas, often based on scams that they themselves have received and would like to warn others about, which is great community spirit in my view.
As you can see, I hasn’t risen to your bait.
This is rather like Y2K. What is the ultimate answer? How do we know if we have been hacked?
Change all your passwords? Right. I have over a 1000 passwords. Change them all. Forget it. Many sites make it nearly impossible to change passwords.
The answer is to move beyond passwords. Fingerprint, Eye, YubiKey, or some other identification scheme.
This scare tactic leaves everyone up in the air. What is the best alternative? Or is this secretly an advertisement for your own software? Try 1Password.
I don’t know how you defend yourself against an accusation of running a “secret ad” (that’s an oxymoron, isn’t it?), especially a secret ad for a product we don’t have…
The advice in the article is hardly a scare tactic: change your master password and then change the passwords in your vault if you can.
TBH, if you have more than 1000 passwords, perhaps it’s time to close down some of those accounts instead, so they aren’t hanging around in your name?
On a related note, I would love to see a world where privacy rules actively discouraged companies from getting you to “create accounts”, and better yet where online merchants were required to have a “buy once without creating an account” option.
While not perfect, I am starting to see consumer web sites not even let you create passwords, they just go straight to sending you the six digit code to your email address. The Raleigh airport parking reservation site (parkrdu dot com) is one. Hyatt hotels is moving in that direction – they give you the option to log in either way – traditional password or emailed code.
The problem with an emailed code is that email is rarely secure against surveillance and interception (how do you think webmail providers manage to target you with ads?), and emails are often archived in plaintext form for regulatory reasons by employers. (The archival thing is perhaps not so much of an issue if those codes have a very short period of validity.)
The other problem with one-time codes as an alternative to passwords is that they give an impression of being some sort of 2FA (which feels like *extra* security) when they are really just 1FA if they are sent instead of passwords.
Typo: A folllow-up
I could have sworn I fixed that, though I figured it would be a good word for a follow-up to a follow-up…
Users also need to change the passwords for their email accounts as soon as possible. Why? Because email accounts are often used for password recovery like “forgot password” buttons/links.
* Merry Christmas everyone *
Thanks for this article and good wishes to all the quiet programmers working to make our lives better. My wishes for next year:
* cookie acceptance globally in browser privacy settings instead of in x different interfaces and notices.
* downgrading by search engines of pages with more than 25% ads (especially where the page is covered by a popup ad), pages with too much bloat/ads.
* more legislation targeted at spam mail and phishing, including badly configured mail and web servers.
* more automation targeted at spam and phishing – new accounts mentioned in spam mail should be suspended etc.
My master password rating is semi-good with the popular online password rating tool showing that it would take five years to crack. Is that sufficient to deter the bad guys? Obviously I know there’s SE ways they can attach but assuming only brute forcing, is a five year timeline realistic or do they have superior tools nowadays?
It’s not a good idea to put your password into any online site other than the one it’s intended for… especially not a “password checker” site, where the only thing you can be sure of is that the site has no need to be told what your password is. (If that checking site is run by crooks, or has been hacked by crooks, the time now to hack your password is exactly zero seconds…
As for “time to crack = 5 years”, well, that’s meaningless without also stating what sort of algorithm is being used, whether you’re talking password generation or password verification, how many computers the attackers have to work on the problem, and whether the attackers have any other hints, no matter how slight, that could help them pick more likely passwords sooner.
For example, if your master password is “secure” for five years against an average desktop PC then a determined criminal with 10,000 spare Bitcoin miners might be able to do the same amount of computation 100,000 times faster, and 1/100,000th of five years is, by my reckoning, just under half an hour.
So it is really reassuring that LastPass say in their “disclosure” (blog.lastpass.com/2022/12/notice-of-recent-security-incident/)
Generally available to the bad guys – or to your son determined to break daddy’s password?
I am increasingly concerened as I dig into this (and frankly worry) that the LastPass announcement has some technical details, but has then gone through a “PR Spin cycle” without going back to the techies and saying “can we say this”? I.e. “millions of years”, “unencrypted data, such as website URLs”, “fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data” (my emphasis – URLs are “form-filled data”). I imagine the techies are pulling their hair out at how this announcement was phrased.
“Millions of years” certainly made me smile, in a wry sort of way.
I suppose you can consider it a cheery sort of thing to say, given that it happily implies that things will still be ticking over then as merrily as they are now – safe commercial nuclear fusion will be no more than 20 years away, some smiling entrepreneur will be in the news showing off the prototype of a safe and affordable flying car (or aquatic, you choose) that will be on the market as soon as they get the permits sorted out, and good weather will mean a bumper harvest for both the Tierra del Fuego coffee growers association and the Spitzbergen wine industry.
Thanks for answering my question. I just got off the phone with Lastpass, complaining about this breach, asking to waive my premium subscription and further inquiring. For being a long-standing premium user, the best they could offer me was a 10% discount (LOL). They said that in the next month they will be coming out with an update regarding how many vaults were compromised, according to them it is still unknown how many vaults were copied. More importantly, they said that MFA will still be required to access the vault in case the master pass is brute-forced. What do you think about that? They said that anyone spreading info that MFA is not relevant in this breach is incorrect and that MFA is required in the case of this breach.
As I mentioned, I can see how you might make something like a Yubikey into a necessary part of entering your master password for offline use… but it’s not clear to me how you could reliably incorporate something like a one-time SMS code generated by LastPass into the processing of your master password for offline decryption.
The answer certainly wasn’t obvious from LP’s diagram, so I await their explanation with interest.
Seems like there is still a lot more that they don’t know than they do know.
They’ve apparently contacted the 3% of business users (or something) that might be at risk, which implies they know how to tell who was affected and who wasn’t, yet they won’t know for another month who was affected and who wasn’t.
Other information still missing is just how long after the first breach did the crooks achieve their “lateral movement” into the second part of the network? In other words, how was LP clinging to the “no customer data was touched” story after it had been?
I’m not suggesting that these are easy questions to answer correctly… but surely it’s not too difficult to list the things you don’t know yet instead of waiting for people to ask individually about them?
“Rotate” also implies a change of axial positions
Linear Column Roll
More akin to a log roll, a barrel roll
Where you stand on the log in the water, floating, seemingly “walking” but your feet are keeping the log rolling, almost like running in place but rolling in place
I think LastPass has been brexh for a second time.. thats why I don’t use the service anymore, I changed to another provider dashlane seem to have good records and no breaching in the history so far
‘…any crooks who may already have figured out your old master password can’t view any of the new passwords in your updated vault.’
Surely if they have an offline copy of the vault, changing your password now is too late? If they get your password through an old compromise like Adobe, they can access your whole database of passwords?
It’s too late to stop them eventually cracking the passwords that were in your vault at the time it was stolen. So you want to change the passwords in your vault (or close down old accounts) in case the crooks do crack your old master password at some point.
But wouldn’t it be an irony if you changed all your vault passwords but didn’t change the master password…
…because then, if you were one of the unlucky ones, and the crooks did crack your old master password, they would have the master key to all your new passwords, too.
It is therefore well worth the crooks’ while to try and steal the new password vault file of anyone whose old password vault they have managed to crack.
After all, they now know your name, your contact details, and the sites you like to visit, so they have a better chance of succeeding with a targeted phishing attack against you tomorrow than they did before this breach happened. (Or, for all you know, there’s still a backdoor into LastPass’s cloud servers that they haven’t found yet – because we now know that LastPass has been wrong about the extent and the danger of this breach before.)
So, just in case the crooks ever get hold of your new vault file in the future (or some other crook gets it and sells it to them)…
…why take the risk they could instantly open the new vault and read out all your new passwords when you can close that door on them today simply by changing you master password first?
so the Bad Guys have a blob of data that is my encrypted set of password info? The theory then is that they can offline try a gazillion master passwords until Bingo, is that correct? My question is: for that to work, wouldn’t they also have to replicate exactly the acrobatics of LastPass’ decryption and how the master password is used in that process? For all we know, can’t LP mess around with the encryption and do all sorts of proprietary scrambling of the master PW befroe it’s used for the actual encryption?
And: What’s the word on what steps are taken to ensure this doesn’t happen again?
LastPass’s password acrobatics are documented, as they should be. (If any aspect of the secrecy of a cryptographic system lies in keeping the algorithm itself secret, run and hide, because “secret” algorithms have a habit of becoming unsecret pretty quickly – especially if they are implemented in code that’s part of a product installed on your device that you can decompile and inspect. And in this case the code has to be in the app you run locally, if LastPass is telling the truth about all the cryptographic processing being done at your end. Also, fudging cryptographic algorithms to make them non-standard is a terrible idea because the people doing the fudging are almost certainly not as good at cryptography as those who devised, specified, attacked, analysed and ratified the standard version of the algorithm in the first place.)
As for what LastPass has done to stop this happening again… it’s now up to them to tell you and for you to decide if you think it will work (and, for that matter, if it’s the whole and unvarnished truth).
LastPass has already made a couple of “declarations of safety” that didn’t pan out as you might have expected (including the company’s original insistence that neither customer data nor password vaults were at risk via a hack of the development network, and its implication that password vaults were “zero knowledge” data BLOBs when at least some of that BLOB was stored unencrypted and thus directly extractable with no master password). Let’s see what they come up with this time and figure out what we think then…
If I use 2fa yubkey, if they will brute force my master password, will they have to my vault ? Or they need 2fa?
I don’t know the answer to that.
In theory, a Yubikey or similar “tamper proof” encryption hardware device could be used to generate part of your secret master decryption code in a way that would require the crooks to have your vault and your master password and your Yubikey to get at the data.
But LastPass’s 2FA also seems to allow a choice of SMS and app-based verification as well, and SMS codes rely on random numbers *generated by LastPass* and sent to you. So those SMS codes can’t be a part of the “zero knowledge” cryptographic secret that goes into generating your master password, given that they are neither controlled by you nor uniquely known to you. So it depends on how LP integrated Yubikeys into its process – are they an alternative to SMS in the “login to the cloud part”, or a special part of the cryptographic secret in the local decryption part?
The LP documentation seems to imply that the actual 256-bit AES password string used for decrypting your vault (too big for brute force and no good for dictionary guessing) is directly generated only from your master password, with 2FA being relevant to the process of logging in to the LP cloud to access online copies of the vault… any LP users know for sure?
(If you change your passwords anyway, this question is still interesting but not quite as important :-)
By reading the lastpass documentation, I think that is the case, i.e. 2FA is of no help for offline master password bruteforcing. I would image all other password manager have the same architecture too.
I panicked for a small moment, but then I remembered that I did in fact delete my LastPass account when I switched over to BitWarden earlier last year. I’m glad that I did. Let’s just hope they actually deleted my data from their servers when I did so.
LastPass are clearly in the mode of defending a ship that’s hit a sizeable iceberg and from the communication still selling the somewhat irrelevant “zero knowledge” thing, it appears that defending reputation is as high a priority as giving full answers to all the questions the customers will have. Putting out what is effectively a press release just three days before Christmas is classic tactic that politicians use to say things they’d prefer not to be heard.
Lots of useful comment and information above. Thanks everyone.
Thank you Paul for a helpful article.
I count myself as a non-technical user trying to keep up to speed. I would like to make a few, probably ill informed, comments.
1) Throughout it is assumed that URL equates to a website. Really? When I store a URL, or last pass does it for me, it contains a lot more than just then URL but often hundreds of characters of hex data. That is not a URL it is, I suspect, user specific information. My point is that the URL contains personal information and therefore presumably covered by the data protection act.
2) Has LasstPass (LP) been negligent collecting information that is not really necessary, such as credit card numbers?
3) LP has made public announcements about the breach. If there is a risk then it is my understanding that it is also obliged to send a notice to each user that has or may have been affected, which they did on 26/08/22. However that did not provide advice on changing passwords and the new revaltion it seems that it would be advisable to change passwords – not had that yet – so not good.
4) Do I need to change to another password manager? That is moot. LP has suffered a breach and, if it is to survive, it will change and go to great lengths to prevent another incidence. For example, all development is done on LP secure premises on an environment that is not and cannot be connected to the internet, just saying. The point it is that it is LP today. It will probably be another tomorrow so switching may not provide the protection we would like to believe/
5) Surely the advice should be that the only information that goes into the manager is stuff that you can recover from. For me the convenience of being able to enter the name of a website I want to go to and to have LP enter the user and password for me is a help, as is the autogenerated passwords. Of course I have a separate list of all the passwords. In addition for any critical site, Government, banking; I always make sure that the password manager does not have all the information needed – That is separate.
All in all the LP breach is not good. It appears that it arose from a human failing from someone who should have known better. We are now a bit wiser and more careful but the product is still basically sound and will get better and it is a wake up call for all to update or list of websites, usernames and passwords.
In reply to your point (1), I have rather generally described those unencrypted URL as referring “websites” but perhaps I should have said that they “denote web-based services that you use”. As you say, most URLs consist of more that a domain name, given that they typically include paths (such as the text “/wp-admin” added to a server name to access a WordPress login screen) and even customer-specific info (such as “/login?name=duck”, or something if that sort).
To me, however, the main thing about those unencrypted URLs is that they apparently provide an exhaustive list of all services (I loosely called them “servers”) for which you have found a need to store strong passwords… and IMO that gives the crooks the chance of producing much more plausible scams to phish you out of additional data. Everyone knows that crooks will regularly get lucky when spamming our Facebook scams (many people have FB accounts) or claiming to be from a High Street bank (choose a well known UK bank and you will be right for, say, 5% or more of all recipients). But a crook who can create a fraudulent message that gets several aspects of your online life correct – for example, if the crooks know your bank, your mortgage lender and your pension fund, along with unusual one-off details such as where you get your car serviced and which specialist bicycle insurer you use… well, that can’t so easily be explained by chance.
There’s one more mystery that you perhaps can help me resolve? It’s the statement “LastPass never stores or sees your master password”. How, then, is it possible for me to go to lastpass.com and log in there? I provide my email address and my master password (as far as I can tell, there’s no option to have a separate PW for e.g. updating payment details ) . How do they log me in without knowing what PW to expect? What exactly is sent to LP if it isn’t the master PW?
This thread of comments/answers is a gold mine for us puzzled LP users, by the way. Thanks for being so helpful!
Thanks for your kind words.
Any LP users able to comment on the choice of different password for “logging in” and “unlocking passwords”?
I’m using free versions (was LastPass, now BitWarden). So no e-commerce transactions (which presumably mean “an e-commerce” account as well as a vault account – even if the same sign-in is used)
Both imply that the email address you supply identifies “your account”.
When I put in my BitWarden Master Password, it implied that the password was being used to encrypt my password vault.
What is not clear – given both password managers imply that all decryption takes place locally on my computer – is how they validate that I am who the email address implies who I am and that I am entitled to have a chunk of encrypted data sent to me.
The only thing that I can think is that there are “two encryptions”. My vault is encrypted to create “a blob”. That blob is then combined with my email address and encrypted again using my password. So when I submit my details, they look to the server for “the data” identified by my email address and decrypt “that data” to see if that results in the (encrypted) “blob” and the email address. If the decrypted email address matches the one submitted through the log-in field, the encrypted blob is then returned.
We then worry whether both stages of the encryption are up to scratch.
With Bitwarden, being open source, I could probably check – if I had the skills!
Lots of good information here, including the article itself, the questions/comments and the answers. Digesting all of this has led me to one conclusion; I was right years ago when I decided it was totally illogical to believe any online password manager could be considered “secure”. I admit, it also took me a while to trust an open source local password manager, but I did eventually trust KeePass after much investigation and double checking. It is a pain to sync between different platforms (e.g. Windows and iOS), but it is possible. There are ports listed on the KeePass website for this purpose, which I have used but prefer to “do it the hard way” and manually copy my encrypted password file where and how necessary.
But, But, But
The more I try to think through this the more convinced I am that we need a calm disinterested skilled journalist to do some detailed work on password managers to enable us to read between the lines of the guff put out by companies that have password manager products (and their “fans”).
“In your head” Passwords can’t be the way to go – either too easy for bad guys to guess or too easy for good guys to forget.
“In your head” Password algorithms on their own are appealing but a bit of thought (and possibly a friend pointing it out to you at the time of a breach) passwords like FpasswordB, GpasswordM and TpasswordW are guessable by the algorithms that the bad guys have.
“On the wall” in a secure house is probably OK provided you don’t get burgled by someone who realises that list on the wall has a value – and you don’t want the hassle of identity theft (or more) after you have been burgled.
So “Password managers” seem to be the remaining solution whilst we still have passwords. Online or offline?
Cloud based on-line ones provide a reliable back up and subject to availabilility of WiFi are “available within an arm’s reach of desire” (Old Coca-Cola merchandising objective). But as we have learnt they can be hacked & stolen and potentially brute force broken at the bad-guys leisure.
But what about off-line ones?
I think I may be more likely to get my laptop stolen than my blob of data stored in a cloud based password manager’s servers (even if LassPass do end up writing to me in the new year revealing that I have been impacted).
Do I want my laptop stolen ,em>with my encrypted blob of passwords – which can presumably be just as easily brute forced as a stolen on-line blob (with the added benefit that there are no doubts about who the data belongs to). (Yeah, you encrypt your hard-disk, but how long do you think a determined hack would take? Steal from a coffee shop – or other place where you have it open – and if they are quick they can download the password blob before your screen lock cuts in. Or perhaps they only nicked it having shoulder-surfed you as you logged in?)
So when-ever you log off, store your vault under some cryptic but innocent name with someone like dropbox (and trust that hackers will not know what it is or whose encryption algorithm have been used) and then shred the vault on your PC? That is an accident waiting to happen.
So it’s a balance of where you want the risk to lie. Possibly for easily stolen laptops having the password “off-machine” has its advantages, whilst for others the case can be made for having the vault “on-machine” but with a reliable back up process (disk crashes still occur)?
Whatever the case, the one thing I have learnt is that changing passwords is a time consuming hassle – even if you do some clearing up of your online life at the same time. Google account security may be good – but changing passwords and dodging through their optional/compulsory data accumulation requests at the same time does not endear me to them as I struggle to get onto old recovery email accounts or get that dreaded feeling that I have “lost” that PAYG telephone number which was another recovery mechanism.
How many of us can be adequately “informed buyers” of password managers?
Most people won’t like this, or be willing to do it…
…but I have given up using “sleep” or “hibernate”.
I don’t lave my laptop unattended, even in a coffee shop I trust not to be full of thieves, and when I need to take it with me (even to the toilet), I shut it down first. It takes about as much time to boot up from cold than it does for me to settle back into my seat, order a new cup of coffee, check for new messages on my phone, and generally look into the distance for a few seconds under the guise of “resting” my eyes.
Bootup times on modern SSD-equipped laptops can be made short enough that there’s only a modest disadvantage in not using “sleep” or “hibernate”, and also avoids the problem that from time to time, closing the lid won’t sleep properly when you are about to take a bicycle journey… and in summer, that is likely to mean an overheated laptop when you reach your destination. It also means that if you get knocked off by a car (always a risk in the bicycle-intolerant UK), well, that’s when your bag is most likely to get stolen, epecially if the straps break when you land. (It happens.)
Did they fail in their reasonable duty of care to their customers is the real question? I suspect they did and that the enterprise is done for.
I think your article is a blended and detailed summary of a technical story. What I think is that under common law one might expect a company offering to secure storage of passwords to be able to demonstrate reasonable and professional protection of that data.
That they were hacked is all the evidence one would need to say they failed in their duty of care to their customers. But also taking 4 months to “sort of” tell us what happened is also indicative of a lack of the measurement, management and monitoring you would expect in planning for this event.
Most security breaches involve significant human factors. What was going on with the compromised single user dev account one wonders.
Finally. Is this an illustration that all your “PBKDF2, bcrypt or scrypt” and your “200,000 iterations of HMAC-SHA-256” are all just sticking plasters on a very poorly designed underlying system?
Tell us what a well designed system might look like. Including the human factors