See what is unencrypted in your LastPass vault | Hacker News Reader

See what is unencrypted in your LastPass vault

github.com

58 pointsnequo10 comments

The wiki (https://github.com/cfbao/lastpass-vault-parser/blob/master/l...) contains a list of all unencrypted fields in an `acct` data block. It is trivial to decode the custom format of LastPass (e.g. using exactly this tool, but figuring out the format manually doesn't seem much harder).

If anyone is interested, although this is originally from 2018, all of these fields still exist and still only the same 6 fields are encrypted. I checked this by creating a LastPass account with a temporary E-mail and looking at the `getaccts.php` network request made upon login to the website.

There also seem to be 3 new fields unknown to the tool (in the resulting csv these are just "?", "??", and "???"). "??" appears to be a timestamp of recent settings or password changes.

Of particular interest are the following fields - "url": Probably the biggest deal. Attackers know exactly for which sites a specific user used LastPass.

- "sharedfromaid": "aid of the sharer's Site/Secure Note". Might be used to correlate different LastPass users.

- various timestamps (creation, last access, modification), bools "autologin" and "never-autofill", "fav" (added to favorites): Might be used to infer usage of websites.

- "genpw": "Is an auto-saved generated password". Really useful for deciding whether brute-forcing is worth it.

- "breached": I couldn't check whether this key is actually being used. If it is, this seems like an incredibly useful shortcut for attackers (directly telling them where passwords from existing breaches might be tried).

I've been trying to reason through the threat model for this and 1Password's newfound cloud storage. This write-up, and any reversing efforts for 1P, only speak to what goes over the network and how the client stores locally (1P uses b64 in sqlite on the client, for example) but I don't know how anyone could speak to what the breach had access to unless those dumps are made public.

One scenario I can imagine is that the API routes merely add authentication over s3:PutObject and the wire serialization is the storage format. But surely if that were true then 1P wouldn't have thrown such a hissy fit over giving up local vaults since their clients already supported multiple cloud backends anyway.

Coming back to the linked repo, the files are 4 years old: did LP not change their format at all over 4 years?

You're entirely right of course, the vault data as accessed in the breach need not necessarily be in the same format as what is transmitted to the client.

And yes, the whole repository is from 2018, but I checked again today and it seems only 3 additional fields were added. In particular the same fields are unencrypted as before.

That's stunning to hear, and also speaks to "then they must not have been adding many features" or that file format must be absolutely rockstar. I'll try to make time to study it in order to learn which this is

(BTW, you also have duplicate comments: https://news.ycombinator.com/item?id=34110529)

The three additional data fields might fulfill some functions related to new features.

Additionally, there is a full history of all former passwords which is transmitted in its own request, so in particular this vault format doesn't seem to contain all data LastPass has concerning a particular account (though what is unencrypted within this format is surely also unencrypted on the LastPass servers).

I think I'd see no problem if LastPass had a great product and kept it as is for extended periods of time, I don't need new features every few months for a security product. But this should have all been encrypted from the start, and there were discussions about this 4 years ago already https://www.reddit.com/r/AskNetsec/comments/8v7bcc/just_a_re.... This could have been fixed for years, but it's the same even now.

I had to read this a few times to establish that you weren’t confusing LastPass (the topic of TFA) and 1Password.

But even then I’m not 100% sure… :)

Yeah, I knew I was running that risk, but since I (thankfully) don't have a LP account, I don't have the same depth of experience with that ecosystem. However, I think they now have more in common than differ ... err, php and lax security practices aside. When I saw the attacker had exfiltrated the cloud storage, as a 1P member I thought "there but for the grace of God go I" and have been trying to think through the threat model that does apply to me

I have better-than-average experience with 1P's opvault format, and have lightly dug into their local cached copy, but realized I can only say so much about their cloud storage situation because the local copy presumably isn't the same as the way they store it

---

BTW, if one is into vault storage formats, I have really enjoyed this series that dug into the 1P API and associated (they didn't have to reverse engineer the .opvault format, that was published): https://darthnull.org/series/1password/ and https://github.com/dschuetz/1password#readme

Interesting. I too am reconsidering the cloud password storage approach.

I much preferred local WiFi sync when it used to be available.

Any idea where the history information is saved? (previous passwords and their dates)

I don't know where that information is saved, but it isn't transmitted with the normal vault format on login (at least on the website). When opening the history dialog for a given password/account, a new request is made specifically for the password history. The response contains the edit times in plaintext and the encrypted passwords.

Reply on news.ycombinator.com