5 ms·

I use Password Store -- uses git + gpg to store all of the passwords. It makes it really easy to maintain a synchronized password store across multiple devices

I use Password Store -- uses git + gpg to store all of the passwords. It makes it really easy to maintain a synchronized password store across multiple devices including Android http://www.passwordstore.org/ http://www.passwordstore.org/

ultramancool 11y ago
The cryptography in gpg is less than optimal for this purpose and I have to admit I just don't like gpg because it's so big and supports different ciphers, big codebase means more exploitability. But it could work for this purpose, it just seems really inefficient to me. Is there browser integration or a better UI for it?
- striking 11y ago
  Using GPG means that Password Store is less than 600 lines of bash at its core (minus emacs, completions, so on). http://git.zx2c4.com/password-store/tree/src/password-store.sh http://git.zx2c4.com/password-store/tree/src/password-store.... GPG is maintained, and well. Even as it supports different ciphers, that attack doesn't apply here. And very little functionality is accessed through this script. If that's not a tiny attack surface, I don't know what is.
  - ultramancool 11y ago
    Password Store might be tiny but GPG itself is a huge attack surface - that's the problem. Maintained, yes, well... I'd question that. I don't think it's very heavily reviewed or anything, and vulnerabilities pop up in it quite frequently, enough that I'm uncomfortable using it for serious purposes. https://www.cvedetails.com/vulnerability-list/vendor_id-4711/Gnupg.html https://www.cvedetails.com/vulnerability-list/vendor_id-4711... Many of these vulnerabilities have to do with very important cryptographic code... If you're comfortable with it, that's fine, it's not a bad solution. But personally I'd honestly be more comfortable with plain text files and TrueCrypt, which has no real cryptographic problems even after quite heavy review, the best we've found is a privesc bug in the Windows driver.
    - striking 11y ago
      You have linked a list of vulnerabilities dating back to 2006, 10 of which are worth talking about. That's just over 1 per year. Only one allows arbitrary code execution. Privesc is bigger than all of these combined, especially in a kernel driver. If Snowden can use GPG, so can you.
      - ultramancool 11y ago
        Getting root or SYSTEM on my machine is no big deal when all the valuable data you can have is already available as my user. Privesc is minor to me, but it depends on your threat model of course. If you're in a shared environment without VM isolation, it could be a much bigger issue for you. I don't mean to downplay it as you're right, kernel mode privesc is bad, it just happens that it's a minor effect on my threat model for personal systems. Arbitrary code execution that say, a cloud storage provider could modify would be a far bigger problem. Some of the cryptographic issues are also arguably bigger problems for practical usage. As such, to me, GPG is not nearly as worthy of trust as other, far simpler platforms. > Snowden can use GPG so can you This just doesn't make sense as an argument to me - one guy who needed strong encryption used it once therefore you should use it forever and ignore or don't try to develop simpler alternatives? 1 vulnerability that's "worth talking about" per year is enough to make me want to run the other direction, especially on something as sensitive as a password manager.
        xorcist 11y ago
        VM isolation? Now that's an attack surface.
    - tedunangst 11y ago
      Don't get me wrong, I love to take a dump on GPG as much as the next guy, but this argument is a little misguided. If you're decrypting password files that come from a malicious party, you have a pretty big hole in your security model.
      - ultramancool 11y ago
- burrows 11y ago
  https://github.com/burrows-labs/pz https://github.com/burrows-labs/pz 68 loc
  - striking 11y ago
    Nice work! This is a very neat spin on the idea. I'll definitely give this one a try. edit: although, what happens if the dictionary is changed? It's the same on all Macs, but what about trying the same script on Linux?
    - dchest 11y ago
      The dictionary is only used once to generate master password. Then it derives site-specific keys with PBKDF2 from it. You can skip pz-master and use your own master password, but make sure it has enough entropy. @burrows: I think there's modulo bias here: https://github.com/burrows-labs/pz/blob/master/pz-master#L11 https://github.com/burrows-labs/pz/blob/master/pz-master#L11 It probably doesn't matter much, but the displayed entropy estimate won't be exact.
      - burrows 11y ago
        You're right; thanks.
  - tyho 11y ago
    What if you need to change the password, store gmail.com.1? how do you remember which one you are on?
    - dchest 11y ago
      Indeed, that's the reason I stopped using my own password generator and switched to password manager. (Also, sometimes I can't remember my username, so password manager is more helpful.)
  - ariabuckles 11y ago
    Nice! I also wrote my own stateless password manager: https://www.npmjs.com/package/viridium https://www.npmjs.com/package/viridium It handles changing a password by keeping a file of the salts, which is theoretically safe to post to a public github (mine's in my dotfiles repo, though it's a private bitbucket repo)

ultramancool 11y ago

The cryptography in gpg is less than optimal for this purpose and I have to admit I just don't like gpg because it's so big and supports different ciphers, big codebase means more exploitability. But it could work for this purpose, it just seems really inefficient to me. Is there browser integration or a better UI for it?

striking 11y ago
Using GPG means that Password Store is less than 600 lines of bash at its core (minus emacs, completions, so on). http://git.zx2c4.com/password-store/tree/src/password-store.sh http://git.zx2c4.com/password-store/tree/src/password-store.... GPG is maintained, and well. Even as it supports different ciphers, that attack doesn't apply here. And very little functionality is accessed through this script. If that's not a tiny attack surface, I don't know what is.
- ultramancool 11y ago
  Password Store might be tiny but GPG itself is a huge attack surface - that's the problem. Maintained, yes, well... I'd question that. I don't think it's very heavily reviewed or anything, and vulnerabilities pop up in it quite frequently, enough that I'm uncomfortable using it for serious purposes. https://www.cvedetails.com/vulnerability-list/vendor_id-4711/Gnupg.html https://www.cvedetails.com/vulnerability-list/vendor_id-4711... Many of these vulnerabilities have to do with very important cryptographic code... If you're comfortable with it, that's fine, it's not a bad solution. But personally I'd honestly be more comfortable with plain text files and TrueCrypt, which has no real cryptographic problems even after quite heavy review, the best we've found is a privesc bug in the Windows driver.
  - striking 11y ago
    You have linked a list of vulnerabilities dating back to 2006, 10 of which are worth talking about. That's just over 1 per year. Only one allows arbitrary code execution. Privesc is bigger than all of these combined, especially in a kernel driver. If Snowden can use GPG, so can you.
    - ultramancool 11y ago
      Getting root or SYSTEM on my machine is no big deal when all the valuable data you can have is already available as my user. Privesc is minor to me, but it depends on your threat model of course. If you're in a shared environment without VM isolation, it could be a much bigger issue for you. I don't mean to downplay it as you're right, kernel mode privesc is bad, it just happens that it's a minor effect on my threat model for personal systems. Arbitrary code execution that say, a cloud storage provider could modify would be a far bigger problem. Some of the cryptographic issues are also arguably bigger problems for practical usage. As such, to me, GPG is not nearly as worthy of trust as other, far simpler platforms. > Snowden can use GPG so can you This just doesn't make sense as an argument to me - one guy who needed strong encryption used it once therefore you should use it forever and ignore or don't try to develop simpler alternatives? 1 vulnerability that's "worth talking about" per year is enough to make me want to run the other direction, especially on something as sensitive as a password manager.
      - xorcist 11y ago
        VM isolation? Now that's an attack surface.
  - tedunangst 11y ago
    Don't get me wrong, I love to take a dump on GPG as much as the next guy, but this argument is a little misguided. If you're decrypting password files that come from a malicious party, you have a pretty big hole in your security model.
    - ultramancool 11y ago
burrows 11y ago
https://github.com/burrows-labs/pz https://github.com/burrows-labs/pz 68 loc
- striking 11y ago
  Nice work! This is a very neat spin on the idea. I'll definitely give this one a try. edit: although, what happens if the dictionary is changed? It's the same on all Macs, but what about trying the same script on Linux?
  - dchest 11y ago
    The dictionary is only used once to generate master password. Then it derives site-specific keys with PBKDF2 from it. You can skip pz-master and use your own master password, but make sure it has enough entropy. @burrows: I think there's modulo bias here: https://github.com/burrows-labs/pz/blob/master/pz-master#L11 https://github.com/burrows-labs/pz/blob/master/pz-master#L11 It probably doesn't matter much, but the displayed entropy estimate won't be exact.
    - burrows 11y ago
      You're right; thanks.
- tyho 11y ago
  What if you need to change the password, store gmail.com.1? how do you remember which one you are on?
  - dchest 11y ago
    Indeed, that's the reason I stopped using my own password generator and switched to password manager. (Also, sometimes I can't remember my username, so password manager is more helpful.)
- ariabuckles 11y ago
  Nice! I also wrote my own stateless password manager: https://www.npmjs.com/package/viridium https://www.npmjs.com/package/viridium It handles changing a password by keeping a file of the salts, which is theoretically safe to post to a public github (mine's in my dotfiles repo, though it's a private bitbucket repo)