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

[problems]

Yeah, this is not an attack itself, just one of the most common post exploitation routes to easy profit. So common that if you have amateur people who try to pirate things, cheat at games or click on the big flashing red banner ad, they're almost certain to come across it and they're almost certain to have common accounts stolen.

Using even a separate password manager, even an integrated one like LastPass raises the bar beyond this extremely basic level and takes it from easy target to medium target, eliminating every common stealer malware I've seen. This definitely doesn't rule out targeted ones of course, like you say, on an objective level there doesn't seem to be much of a difference. At a practical level though based on what's in the wild for non targeted attacks, it's huge.

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