Ask HN: How (un)secure are the passwords saved at my browser?

Yes, browser password storage is really poorly secured. For what it's worth, a Chrome staffer explained on this very site[0] their reasoning, but that doesn't really sit too well with me - in my opinion, browsers should either go all way the way and integrate a full KeePass/1Password style password storage or remove the feature altogether.

Firefox appears to be a bit better by letting you set a master password that's used to encrypt passwords[1], although without digging into the behavior I can't say exactly how much that helps.

[0]: https://news.ycombinator.com/item?id=6166731 [1]: http://kb.mozillazine.org/Master_password

Lastpass is zero-knowledge but subject to any number of attacks on the client. As the old adage goes: If you can't attack the crypto, attack the client! My personal setup is an always updated version of KeePass. I gave up using 1Password when I realized the loopback is cleartexted when autofilling passwords, and a host of other vulns like the .opvault format not used as the default, and too many other vulns to count. The master password is also a single point of failure and once you get that, you get everything. A chain is only as strong as its weakest link and all that. With KeePass even if they have the master password, they also need a second key / keyfile, and a machine ID so a copy of the KDBX file is useless to an attacker (unless they can emulate your machine UUID).

You can read more about that 1pass vuln here: https://news.ycombinator.com/item?id=11212002

> I gave up using 1Password when I realized the loopback is cleartexted when autofilling passwords

There's a forum post or blog post or something (I forget) by 1Password about why this is, and it basically boils down to, it's impossible to be completely certain that the other end is the process you're trying to talk to, so there's no point in encrypting the traffic on the wire. Any process with permission to sniff the traffic (i.e. root) also is capable of intercepting the connection entirely and pretending to be the other end, so encryption doesn't really get you anything. Remember, both ends are processes on the same machine, so you can't use certificates or signatures to prove identity as the keys would have to be on the local machine where the attacker can find them.

> a host of other vulns like the .opvault format not used as the default

It was used as the default for iCloud, just not for Dropbox because of compatibility concerns with older versions of 1Password. According to a forum post from 2 years ago, "In time, all users will be converted to the newer format" (https://discussions.agilebits.com/discussion/comment/139552/...). I'm not actually sure whether they've made the switch yet, since I already stopped using Dropbox for syncing.

> and too many other vulns to count

Please elaborate. I've heard of far fewer issues with 1Password than competing services. I've certainly never seen anything that even remotely qualifies as "too many other vulns to count". So I'm extremely skeptical of this claim.

> The master password is also a single point of failure and once you get that, you get everything

You also need to have the actual data. I'm skeptical that KeePass is any better. From reading wikipedia, it needs a master password and/or a key file. If you use a master password, that's the same as 1Password. If you use a key file, anyone who gets access to your machine can now decrypt all your passwords so that seems worse. If you use both a master password and keyfile, anyone who gets access to your machine (i.e. to get your KDBX file) and has your master password can also get at everything, and it's also not clear how using a combination like this even works if you're syncing your KBDX file with any other machines (e.g. using Dropbox). Wikipedia also says you can use the Windows current user details instead of a password/key file, but again, any attacker that gets access to your machine now has all the information necessary to decrypt your KBDX file.

> With KeePass even if they have the master password, they also need a key, and a machine ID so a copy of the KDBX file is useless to an attacker (unless the can emulate your machine UUID)

They don't need to emulate your machine UUID, they just need to apply the cryptographic operations to decrypt the KBDX file themselves. If an attacker gets access to your machine (e.g. to get your KBDX file), they can get all that other info too (assuming you even set up KeePass to use that info).

> If an attacker gets access to your machine (e.g. to get your KBDX file), they can get all that other info too.

Well in theory yes, but one typically wants to slow an attacker down. I'm not saying a KDBX file is entirely useless, just cumbersome if an attacker now has to replay the decryption using various disparate key parings. Most attacks are smash and grab jobs where all the low hanging fruit is gathered, and attackers (generally) don't lie around on a box waiting trying to figure out the inner workings of your KeePass setup.

If the attacker knows you use KeePass (or notices the KBDX file) then it's easy enough for them to grab all of the relevant info at the same time they grab your KBDX. There's no need to "lie around on a box waiting".

What advice I give in terms of computer security I see more like being sanitary similar to washing your hands, it will not make you free of germs but it will greatly reduce the chance of getting an serious infection. The thing you should realize is that your data will never be perfectly secure. You could take your data offline and store it on an encrypted hard-drive in a waterproof safe on the bottom of the ocean and there could still be ways to access it. You need to find a middle ground where you feel safe enough not to worry about serious infections but aren't afraid of germs to the level it affects your every day life.

Most browsers store their passwords in plain-text, this means there's applications that can fetch all your stored passwords from all browsers and send them to an undisclosed location in seconds given user level privileges on the machine.

By upgrading to lastpass you have reduced that attack surface by using a secure passphrase and encrypted data-store but you have increased your attack surface to anything accessing lastpass servers and application bugs.

With all these attack vectors one might think that it's better to just not save passwords and just remember them, while this is true in theory in practice it's impossible to remember a sufficiently unique password for each website you are registered to which leads to password reuse which is another much greater attack vector where your leaked passwords from one site can be reused on other sites.

In general I would advice you to use a password manager that generates and encrypts passwords (Lastpass is one of them), use a secure passphrase and don't reuse passwords. Password reuse will likely make you less secure than writing your passwords on a post-it by your computer (don't do that either)

I would also consider looking into using proper 2-factor authentication for sensitive login (document storage, email, password manager) but I don't want to bore people with the details there so I'll defer you to do some independent research

TLDR

* Store passwords encrypted (Lastpass is fine)

* Don't reuse passwords on different sites

Yeah it's pretty easier to get to your saved passwords in Chrome -- they're at chrome://settings/passwords. They're not encrypted or anything (depending on your OS, you might have to enter your password to reveal the passwords at that link, but that's just to stop unsophisticated snoops -- there's nothing blocking access to the plaintext passwords on your hard drive). I'm not sure precisely how LastPass is accessing them (I use 1Password) but I'm not really surprised. Chrome's password store is for convenience, not security. If you want security, use 1Password or LastPass or something.

Passwords stored by the browser can't be encrypted. Unlike with, say, LastPass, the browser doesn't have any "master password" to encrypt data with. Moreover, the passwords can't be stored as hashes (like in /etc/passwd), since websites require users to provide passwords in plain text.

Granted, if you use full-disk encryption, this concern is much less serious.

> ... the browser doesn't have any "master password" ...

Firefox does. Chrome doesn't. I can't speak to Safari or Internet Explorer.

Safari stores your passwords in your login and/or iCloud keychains. So they are encrypted on disk, but the master key is kept in memory unless you change the setting to disallow that. (/Applications/Utilities/Keychain Access.app, right-click on login keychain, choose Change Settings for Keychain "login"; I don't know how to change this setting for the iCloud keychain)