Hacker News Reader

Comment by micahcc | Hacker News Reader

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