6 ms·

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 muc

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 10y ago
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.
- eikenberry 10y ago
  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 10y ago
    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.
    - dictum 10y ago
      > 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 https://news.ycombinator.com/item?id=13003236
    - acomar 10y ago
      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 10y ago
        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.
- clark800 10y ago
  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.
cschmidt 10y ago
What system are you using?

pwinnski 10y ago

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.

eikenberry 10y ago
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 10y ago
  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.
  - dictum 10y ago
    > 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 https://news.ycombinator.com/item?id=13003236
  - acomar 10y ago
    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 10y ago
      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.
clark800 10y ago
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.

cschmidt 10y ago

What system are you using?