[clark800]

I've been surprised by how negative the opinions of deterministic password managers have been since I've been using one for over two years and it has been a much better experience overall than using KeePass on Dropbox, and I also think that it's more secure than cloud-based systems (see point 4).

My take on the points in the post:

1. Out of the 100 or so sites that I use, only a few have password policies that require tweaks, and it usually just requires disabling symbols and or adjusting the length. These tweaks are cached in my browser, so this hasn't been much of an inconvenience.

2. My passwords are rarely revoked, and when they are it is just a counter bump. This is state, but again it is cached in the browser.

3. It's true that they can't store existing secrets, but this can be viewed as out of scope for a password manager.

4. For the application I use, it's not true that exposing just the master password exposes all of your site passwords. There is a 512bit private key that is synchronized once between devices using a QR code. An attacker would need both the master password and the private key file to generate any passwords. Because the private key only exists on devices I physically own, this should be harder to obtain than an encrypted database that lives in the cloud, so I view this system as more secure than KeePass on Dropbox, Lastpass, or 1Password.

My experience over the past two years has been that the advantages are more significant than the disadvantages.

[pwinnski]

If your browser is caching all of your passwords, I think you've got security problems well outside the scope of your choice of password managers.

[clark800]

Only the override parameters for a site are cached, such as a boolean to indicate that symbols are disabled or an integer reset counter. The passwords are never cached.

[eikenberry]

I'd guess he doesn't mean cached, but instead means that his web browser works with this system keyring (or has its own) to save/use the passwords.

[problems]

Which is bad. I've reverse engineered script kiddie malware far too many times to find them shipping "iStealer" and similar, which basically just dump browser password stores and send them to a gmail or FTP account. Often these pieces of malware include the SMTP credentials to the same gmail account or FTP access to download the results.

And having seen their results, let me just say, these script kiddies can do damn well with this tactic.

Do not use a browser/system keyring store under any circumstances unless you can be 100% positive that you won't accidentally run that sketchy exe you came across.

If you use Keepass, it presents another layer, they have to actually get your keepass password too, or dump your database when it's logged in. Often something like that won't be hit by script kiddies but certainly would in a targeted attack. The best practice here is to run Keepass on a separate machine to prevent an all-at-once dump. Even a separate machine on the same network where you use Synergy or similar to sync the clipboards would probably be sufficient.

Anything worth more than dirt should of course have 2FA, which is why I also suggest a tiered password system (ie: junk password for common and worthless sites, separate passwords for banking, etc) and 2FA as an alternative to a real password manager.

[eikenberry]

> Do not use a browser/system keyring store under any circumstances unless you can be 100% positive that you won't accidentally run that sketchy exe you came across.

This is easy once you decide to do it. Just don't download and run random crap, don't be stupid and "curl URL | bash", etc. It really isn't that hard to be 100% if you pay attention. The main problem is that most people just don't care enough.

[acomar]

Wait, KeePass only decrypts the database into memory for a particular process, right? So it would take an exploit of some kind to read the memory holding the decrypted database?

[problems]

No, it wouldn't take an exploit, it just takes a process running as an administrator, maybe even as the same user if the attacker is clever.

There's several ways to go about it:

1) Basic basic software keylogger, there are some mitigations against this via common APIs though with mixed success. It also would mean a lot of data to filter through. Not fun for someone just looking to grab as many passwords as they can.

2) Dump memory, just save the entire memory of the keepass process via ReadProcessMemory calls, as long as you have sufficient privileges this should be possible. The passwords are in there, KeePass has no memory shadowing support to my knowledge at least. And once you've logged in to keepass you don't get prompted for the password again, therefore, it should be entirely possible to read all passwords based on just this.

3) Replace the keepass executable with your own modified version that logs the password or other auth credentails to disk, or just dumps the database to disk on logon if they're using some esoteric authentication method like Yubikey. This involves shipping your own patched exe around though, which works, but isn't particularly clever, could be fairly large and will be revealed with a signature check.

4) Do the same, but rather than replacing it on disk, do it in memory - do it from a shared library or inject your own code via WriteProcessMemory/CreateRemoteThread, etc. This is usually less detectable. Doesn't matter if the executable is signed this way either, you bypass the signature system and can avoid the need for disk write permissions too. This is the way to get the brownie points.

Any and all of these are fairly trivial to someone who knows their way around the Windows API and has a copy of the Keepass source and IDA. However, none of these are things commonly used by script kiddies going for a hit-and-run operation. All of these however are on the table in a targeted attack with even a slightly competent attacker.

[dictum]

> I've reverse engineered script kiddie malware far too many times to find them shipping "iStealer" and similar, which basically just dump browser password stores and send them to a gmail or FTP account.

Meet the guy behind some of them: https://news.ycombinator.com/item?id=13003236

[erelde]

If only my bank allowed passwords...

Shame, Société Générale, shame.

[whyagaindavid]

I thought browsers store password s encrypted. I use Firefox sync that encrypts and uploads passwords. Do u mean this is also vulnerable? Thx

[problems]

We're talking about different things:

- Firefox Sync is not vulnerable in the sense that Mozilla, nor any attacker can read your passwords while they're on the wire or on Mozilla servers. Passwords are encrypted client-side only and are effectively unbreakable between your devices assuming your master password is secure.

- The Firefox browser password store is only encrypted if you use a separate master password to unlock your saved passwords each and every time your browser starts up. This master password would defeat the majority of script kiddie malware, but not a targeted attack, similar to separate password managers. However, it's also a real pain, no one wants to have to type all that extra stuff, so they just use the default - remembering passwords without a master password. Even if you use Firefox Sync, your passwords still get sync'd into this store. Firefox Sync keeps them safe everywhere between your devices, but not on your devices.

- If your Firefox password store has no master password set, that means that the Firefox browser must be able to read your passwords from it. They can (and do) encrypt it all they want, but ultimately all it takes it a little bit of reverse engineering to decrypt it, because the key needs to somehow be accessible to Firefox, that means that to read your passwords, malware simply needs to duplicate what Firefox does.

[tomrod]

Neophyte to all this. What is a browser password store? Do you mean never letting Chrome (or whatever) save a password?

[problems]

Yes. If you want to see how vulnerable you are to this sort of attack, Nirsoft ships a good tool called WebBrowserPassView:

http://www.nirsoft.net/utils/web_browser_password.html

Be aware, this may be detected as malware or a "hacking tool" by your AV for obvious reasons.

[countingteeth]

How is this to supposed to show "how vulnerable you are to this sort of attack"? This runs standalone.

1. As a general rule, if you download and run an untrusted standalone program, it could probably steal your passwords even if you use a password vault (although that would certainly make it a little bit harder).

2. You can just go into the Chrome password manager and click "show" to see any stored password. No tool needed.

Chrome uses sandboxing and process isolation extensively. Using the default browser password store certainly presents a ripe target if someone manages to totally own the browser, but technically there's not a huge leap from owning the browser to owning an external password store, and certainly not grabbing any and all passwords entered into the browser via a password vault.

I'm not disagreeing that a standalone password vault encrypted with a master password is effectively more secure than the built-in manager. I do think it has been exaggerated both how much more so it is. Saving strong passwords with the built-in password store is generally much less bad than, for instance, using a common memorized password, or using very weak passwords. Both of which are likely outcomes of "never use the password store."

[pwinnski]

I never let my browsers store a password to anything, ever. I rely on 1Password to supply all passwords, and having my browser also store a password doubles the attack surface.

[cschmidt]

What system are you using?