Hacker News new | past | comments | ask | show | jobs | submit login

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?




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

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.


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

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.


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.


Cloud synchronization is a very common use of a password manager. Many people load their password manager files onto Dropbox, GDrive, etc. Assuming authenticated encryption is properly used and care is taken to avoid leaking metadata, this should be a non-issue.


Solid point. Indeed, that should be safe.


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.


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.


VM isolation? Now that's an attack surface.



Nice! I also wrote my own stateless password manager: 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)


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?


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 It probably doesn't matter much, but the displayed entropy estimate won't be exact.


You're right; thanks.


What if you need to change the password, store gmail.com.1? how do you remember which one you are on?


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




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: