A few days ago LastPass admitted that unknown attackers copied their “vault data.” It certainly doesn’t help that LastPass failed to clarify which parts of the vaults are encrypted and which are not. LastPass support adds to the confusion by stating that password notes aren’t encrypted which I’m quite certain is wrong.
In fact, it’s pretty easy to view your own LastPass data. And it shows that barely anything changed since I wrote about their “encrypted vault” myth four years go. Passwords, account and user names, as well as password notes are encrypted. Everything else: not so much. Page addresses are merely hex-encoded and various metadata fields are just plain text.
Contents
Downloading your LastPass data
When you are logged into LastPass, a copy of your “vault data” can still be downloaded under https://lastpass.com/getaccts.php. Only one detail changed: a POST request is required now, so simply opening the address in the browser won’t do.
Instead, you can open Developer Tools on lastpass.com and enter the following command:
fetch("https://lastpass.com/getaccts.php", {method: "POST"})
.then(response => response.text())
.then(text => console.log(text.replace(/>/g, ">\n")));
This will produce your account’s data, merely with additional newlines inserted for readability.
Side note: you can also download the data in the original binary format by adding mobile=1 to the request body. It’s really the same data however, merely less readable.
What’s in the data
Obviously, the most interesting part here are the accounts. These look like this:
<account name="!abcd|efgh" urid="0" id="123456" url="687474703A2F2F6578616D706C652E636F6D"
m="0" http="0" fav="0" favico="0" autologin="0" basic_auth="0" group="" fiid="654321"
genpw="0" extra="!ijkl|mnop" isbookmark="0" never_autofill="0" last_touch="1542801288"
last_modified="1516645222" sn="0" realm="" sharedfromaid="" pwprotect="0"
launch_count="0" username="!qrst|uvwx">
<login urid="0" url="687474703A2F2F6578616D706C652E636F6D" submit_id="" captcha_id=""
custom_js="" u="!qrst|uvwx" p="!stuv|wxyz" o="" method="">
</login>
</account>
First of all, encrypted data should have the format !<base64>|<base64>. This is AES-CBC encryption. The first base64 string is the initialization vector, the second one the actual encrypted data. If you see encrypted data that is merely a base64 string: that’s AES-ECB encryption which absolutely shouldn’t be used today. But LastPass only replaced it around five years ago, and I’m not sure whether they managed to migrate all existing passwords.
As you can see here, the encrypted fields are name, username (duplicated as u), p (password) and extra (password notes).
Everything else is not encrypted. The url attributes in particular are merely hex encoded, any hex to text web page can decode that easily. Metadata like modification times and account settings is plain text.
There are more unencrypted settings here, for example:
<neveraccounts>
<neverautologin url="64726976652e676f6f676c652e636f6d"/>
</neveraccounts>
Apparently, drive.google.com is an exception from the password autofill for some reason. More interesting:
<equivdomains>
<equivdomain edid="1" domain="616d65726974726164652e636f6d"/>
<equivdomain edid="1" domain="7464616d65726974726164652e636f6d"/>
…
</equivdomains>
This lists ameritrade.com and tdameritrade.com as equivalent domains, passwords from one are autofilled on another. As these fields aren’t encrypted, someone with access to this data on LastPass servers could add a rule to automatically fill in google.com password on malicious.com for example. I reported this issue in 2018, supposedly it was resolved in August 2018.
What’s the deal with the encrypted username field?
The account data starts with:
<accounts accts_version="105" updated_enc="1" encrypted_username="acbdefgh"
cbc="1" pd="123456">
What’s the deal with the encrypted_username field? Does it mean that LastPass doesn’t know the decrypted account name (email address)?
That’s of course not the case, LastPass knows the email address of each user. They wouldn’t be able to send out breach notifications to everyone otherwise.
LastPass merely uses this field to verify that it got the correct encryption key. If decrypting this value yields the user’s email address then the encryption key is working correctly.
And: yes, this is AES-ECB, a long deprecated encryption scheme. But here it really doesn’t matter.
Why is unencrypted metadata an issue?
As I’ve already established in the previous article, decrypting LastPass data is possible but expensive. Nobody will do that for all the millions of LastPass accounts.
But the unencrypted metadata allows prioritizing. Someone with access to admin.bigcorp.com? And this account has also been updated recently? Clearly someone who is worth the effort.
And it’s not only that. Merely knowing who has the account where exposes users to phishing attacks for example. The attackers now know exactly who has an account with a particular bank, so they can send them phishing emails for that exact bank.
Comments
Completely unacceptable. I might have missed the fine print somewhere, but the only reason I put my trust in LastPass and give them a monthly fee is because I trusted them when they told me my data was encrypted with a password they don't know. Had I known all my URLs were not encrypted, I would have never used their service.
I was always skeptical about keeping my sensitive data on public clouds since I don't know what I'm doing and assume security companies know how to properly safeguard my data. But it is now apparent that they don't either, and at least if I do it I can make sure that everything is properly encrypted.
It's a disaster. Anyone on lastpass needs to leave it. I am, and am making the migration to another. Here's the rub. Whatever data you had on lastpass WILL get revealed. It's now only a matter of time. Maybe tomorrow, maybe a year from now, or maybe 10. But it WILL get revealed. If you stored SSNs, credit cards, addresses, drivers licenses, debt pins, and those pesky security questions (what's your fathers middle name), they are going to eventually be accessible to hackers and scammers. You can no longer use these answers for security questions, else fear another will be able to reset your passwords. Your personal life details, when stored in LastPass, no longer belongs to you. But wait, there's more. Since URLs for saved passwords were not encrypted, you can expect some serious, finely targeted phishing attacks like you've never seen. They already know where you bank now. Where you shop. They know every site you had passwords for. So as of yesterday, you need to become an expert at identifying scams and be super paranoid. This is truly a security disaster of epic proportions. Lawsuits should and will come. LastPass is dead. The worst of this all is the lack of transparency. If LP had any respect for it's consumers, it would have been telling you this upfront. It would be recommending you change all of your passwords NOW and updating any information you had stored in LastPass (cancel your CCs and get new ones; redo security questions with answers you've never saved in LP), etc. This is a complete and utter failure on the part of LP, and is incredibly disconcerting. Trust is 100% lost. They should not be given the benefit of the doubt at this point. Good luck out there. You're going to need it.
Thank you for this article. As a longtime LastPass user, the latest news was unsettling. I dumped my data following your instructions and took a very careful look. I found that username/id, passwords, account names, account numbers, and especially the notes (extra) were all encrypted. I did searches on specific sensitive data, and literally inspected every page, and found no sensitive data that was in plaintext. On the other hand, all of the URLs were in hex, which to my mind is not encrypted; this for me is a lower priority, as my browsing history is collected by everybody these days, as evidenced by instant ads for something I just started searching for. I was considering changing password managers, but do not plan to at this point. It has prompted me, however, to change my master password (which has 2FA protection also), and to review my most sensitive data and ensure it is as secure as possible; strong passwords and 2FA, etc. Thanks again for this article; it was most useful.
Thanks for the article! Is the vault fetch no longer working? I've tried from 2 browsers (while logged into LP extension in both), but it fails with a vague "Failed to fetch" message.
No, if I log into LastPass via web interface and then run this code on their site – it’s still working for me.
I left LastPass years ago. I felt that trusting all the security to the master password was inherently insecure. I moved to 1password, which generates a 128-bit key with high entropy, and then adds that to the master password.
At the end of the day, all these password managers have several problems that aren't easy to fix and will almost currently be exploited in the future.
1) They are all susceptible to supply chain attacks where malicious code can steal the master password and, if present, 128-bit recovery key as with 1Password. Open-source software such as Bitwarden deployed on iOS and Android versions can't be audited since the code can't be reviewed once sent to Apple's and Google's servers and deployed to devices. We have no idea what is running on our smartphones.
2) Huge attack surface: All password managers run on general-purpose OSs, which, as we all know, is very insecure. We are trusting browsers and OSs that are regularly attacked. Windows, OSX, Linux, iOS, and Android are all susceptible.
3) I hear many people incorrectly believing that the Yubikeys are the solution. The problem is they are referring to U2F, and FIDO2, which is an authentication protocol and has nothing to do with encryption - you can't encrypt data with U2F. I know that Yubikeys have several encryption modes like PIV and GPG which do provide strong encryption which is the solution, but no password managers supports them except Pass (Full support for GPG and smartcards) and keypass (kind of supports PIV) But no cloud support.
While there is no perfect solution, I would like to see a password manager that is a mix between the Ledger Cryptocurrency wallet and the Thales HSM. Secure storage of private key with an audit log and a small attack surface.
I've seen talk elsewhere that the URL notes (not secure notes) were not encrypted prior to 2018 and thus could be sitting in archived vaults(also stolen?)? Anyone know definitively?
Sorry, I have no idea about different kind of notes. When I looked at the vault in 2018 I didn’t see anything substantially different from what I see now.
With all the discussion about the shortcomings of their encryption (besides all the other), I keep coming back to one question related to the encryption involving one's password. And I probably should have wondered this before, but how can any data that requires my password for decryption be shared with others at all? if "supersecretpassword" is encrypted with "myvaultpassword" and I share it with somebody else within LastPass, it somehow needs to be decrypted at some point and likely re-encrypted with the other persons vault password. Wouldn't there need to be some sort of gap? And not just with LastPass, but with any service that claims that there's "no way" to decrypt credentials without a user's password...
They use public key cryptography for that. So when you decide to share a password, it is re-encrypted with the public key of the account you are sharing with. This account can then decrypt the password using the private key known to them.
So at least in theory, the server isn’t involved in the process and cannot see the password. In practice, it is really difficult to get the public key of an account without trusting the server – a malicious server could give you its own public key and get access to the password this way.
And there is of course the general issue: once you have shared a password, you cannot “unshare” it. Even if you revoke access, you need to change the password. This is something that LastPass doesn’t stress enough, they rather suggest that disallowing copying passwords can be expected to work.
If someone does move to another product like Bitwarden, how do commoners like myself know it's not going to have glaring issues like Lastpass in a month or year, etc.?
I did my "due diligence" before I chose Lastpass and didn't find these issues popping up in security blogs or such. Wondering how I minimize choosing a product that has glaring issues like unencrypted URLs - that's a horrible failing.
It’s known that Bitwarden encrypts the entire data, so it’s already better than LastPass. I also hope that Bitwarden consistently uses 100,001 PBKDF2 iterations for all accounts (unless changed manually) and at least warns if someone sets a value that’s too low.
Unfortunately, otherwise it seems not too different from LastPass. There is no secret key like with 1Password that makes guessing the master password implausible. So these 100,001 PBKDF2 iterations are all the protection you get, and you should make sure to choose a strong master password.
Bitwarden claims to add 100,000 PBKDF2 iterations on the server side. While this sounds good in theory, judging by their security whitepaper they misimplemented this similarly to LastPass. In 2018 I proved this mechanism to provide no security value. It can be implemented correctly (see Firefox Sync) but it doesn’t look like it was here.
Looking back thru your articles on LastPass and Bitwarden. What does MFA add to the mix? If I have MFA enabled does it really provide any additional security against someone compromising my vault? If they guess my password, aren't they still prevented from accessing the data without the MFA token/code? Thanks!
If the vault data is already compromised (like it happened for LastPass) – MFA doesn’t help at all in this scenario, it isn’t a factor in the encryption. But it does help if your credentials are compromised by some other means. MFA will prevent the attackers from logging into your account and downloading your vault data.