Hacker News Reader

Comment by FatActor | Hacker News Reader

I missed that part. What is the problem about URL exposure?

EDIT: all three replies to this comment are about sex-shaming people via their email address, ip, home address. hardly pearl clutching. go to DefCon some day, you'll see how that information is basically for sale legally, let alone on the darkweb.

i don't have a horse in this race because i use my own password storage software but the amount of FUD in this thread is cray cray.

View on HN

Since they're tied to people's account details, address and similar, I'd imagine quite aggressive blackmail opportunities going forward if the data gets to the hands of criminals.

Think postal letter named and addressed, giving your email, and the adult (or other embarrassing) sites you were a member of listed on the letter, along with details of a bank account to make immediate payment to...

Also, you may be able to identify people working for certain high profile orgs (defence contractors, etc) and target them further if you can gleam from URLs they have access to internal systems by specific URL.

>go to DefCon some day, you'll see how that information is basically for sale legally, let alone on the darkweb.

"It's already out there so we shouldn't bother preventing it from spreading further," is a terrible argument.

Agreed. Also what's being overlooked by others is the inability (using dumps of "users of site X") is the ability to globally intersect that with another site.

The ability to quickly find users who have an account in (list of embarrassing sites) intersected with (list of internal gov and mil sites, and large defence companies) is hugely powerful to some adversaries, and data leaks/dumps only give half of this equation.

I might be misunderstanding, but if the url was adobe.com, then it would be possible to find the corresponding password from that adobe breach for the same email address (not trivial, but if someone moves in the right circles I assume they could get a whole host of the big breaches in a searchable format).

A subset of users might have reused the breached password(s) for their lastpass master password.

Not sure if you could also feed the breached passwords into the brute force tool to give it a headstart, in case they did a slight variation on a breached password for the lastpass master password.

With a list of names, billing addresses, email addresses, telephone numbers, IP addresses (sounds like it's a list since the user first started to use LP) along with URLs having a 99.9% probability of the individual having an account at the URL... that can be pretty much catastrophic. Create a list of OnlyFans subscribers, or if there is a subdomain used for OF creators you can compile a list of them. Any service that uses unique subdomains (like the users username) means you can connect usernames with individuals and so on.

Some URLs will be for internal corporate networks, things that should be protected by VPN but aren't, or publicly-accessible projects with poor security.

It would be really interesting to crawl through this data and filter out all the boring usual stuff, and see what else shakes out.

It's also somewhat helpful for spear-phishing or other social engineering. If you know which services a particular person is using, it's easier to fool them into giving up access to one or more of them.

Probably that now it is known that people with a lastpass account of email address X also have an account at login.furriesindiapers.com or something really insane like dailywire.com

Or worse... find everyone that has a "WePostDamningInformationAboutOurDictator.com/wp-admin" URL

Yeah, yikes.

Any information that helps an attacker craft a more targeted attack is useful to the attacker. With URL exposure the attackers now have a comprehensive list of services that a person depends on and where further data about them is stored.

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

I wonder what other data is unencrypted . They need to be more specific on what that means. Were there certain fields that a person can set in the vault that were not encrypted?

There is a notes field (this is different from the “secure notes” feature) for each password entry that you could use to write remarks. I don’t know if that would be encrypted.

I wonder why URLs would be unencrypted given that all the other things are encrypted. I guess browser integration relies on it?

right, they need to know whether to offer you a password or not regardless of whether you have re-locked

That doesn't require it to be stored in the clear on the server. Extensions/apps could keep a domain list (don't see why they need full URLs) in memory after lock.

Are domains truly the only scope that matters? What if a platform site allowed hosting user web apps (which could themselves offer authentication) all on the same domain, each in their own directory/path. As long as the app was careful to set the path attribute of the session cookie appropriately, the app could be pretty well-contained. Then a password manager just decides that a password field anywhere on the whole domain is a good place to autofill your password for one of the apps on that domain? That's pretty scary!

The context here is with a locked vault so no data to auto-fill with. It's most likely purpose was to indicate "LP has the login info for this site but the vault is locked". An indicator like that can be coarse and simply use a root domain and ignore subdomains and paths, better to have some false positives than leak data in the clear.

[We might be wrong about the locked-vault but might have data scenario, but that kind of seems the only legit reason to store that stuff in the clear, so if that wasn't the reason, LP's negligence is even worse]

This feels like it might've been a good opportunity for hashing.

Reply on news.ycombinator.com