Show HN: passgo, a command line password manager written in go(github.com)
github.com
Show HN: passgo, a command line password manager written in go
https://github.com/ejcx/passgo
14 comments
Not encrypting site names was a UX decision. If site names were encrypted, listing entries in your password store would require a prompt for your password.
> If site names were encrypted, listing entries in your password store would require a prompt for your password.
As it should, yes. Any interaction with the password manager regarding my stored passwords should require the master password.
As it should, yes. Any interaction with the password manager regarding my stored passwords should require the master password.
Its a bad default.
You could make it so that site names were encrypted by default, but files with plaintext site names were supported.
You could make it so that site names were encrypted by default, but files with plaintext site names were supported.
Some people may disagree with me but that's fine. There really isn't a correct answer here. It's a product decision balanced with security. I think _strongly_ wanting this is mostly FUD.
I firmly believe in secure defaults (with all my heart) but I don't think there's a compelling reason to hide site names in this situation.
I trust the strong cryptography (and DJB) that protects the passwords and this is plenty for keeping an attacker out.
Yeah, it's more information for an attacker but I don't think it buys an attacker anything meaningful. Responding to ping or listening on specific TCP ports and responding with service banners is "more information" too, but these are accepted. Running your company on someone else's computer used to not be accepted and now it is.
With strong cryptography there is no reason this information can't be public. If you're truly paranoid, you can always use a private repo or a private git server.
If anyone has a compelling argument for why this information should be secret by default I would love to make the change.
I firmly believe in secure defaults (with all my heart) but I don't think there's a compelling reason to hide site names in this situation.
I trust the strong cryptography (and DJB) that protects the passwords and this is plenty for keeping an attacker out.
Yeah, it's more information for an attacker but I don't think it buys an attacker anything meaningful. Responding to ping or listening on specific TCP ports and responding with service banners is "more information" too, but these are accepted. Running your company on someone else's computer used to not be accepted and now it is.
With strong cryptography there is no reason this information can't be public. If you're truly paranoid, you can always use a private repo or a private git server.
If anyone has a compelling argument for why this information should be secret by default I would love to make the change.
Here are two obvious reasons for wanting to hide this meta information:
1) ejcx signs up for a porn service and is embarrassed to admit it
2) ejcx has an account on some server compromised. The attacker now wants to get a nice list of other sites that the ejcx also uses, so they can try their luck to see where ejcx has foolishly used the same or similar password and login name. This information is just a github search away.
In both cases, ejcx may never be so foolish?!. But users of password management apps in general mess up all the time.
I want a password manager that I have confidence in to upload my passwords somewhere I can retrieve them if I lose my home computers etc. However, I don't want to announce to the world the websites I visit.
1) ejcx signs up for a porn service and is embarrassed to admit it
2) ejcx has an account on some server compromised. The attacker now wants to get a nice list of other sites that the ejcx also uses, so they can try their luck to see where ejcx has foolishly used the same or similar password and login name. This information is just a github search away.
In both cases, ejcx may never be so foolish?!. But users of password management apps in general mess up all the time.
I want a password manager that I have confidence in to upload my passwords somewhere I can retrieve them if I lose my home computers etc. However, I don't want to announce to the world the websites I visit.
I don't buy your second point. Your argument is that an attacker can try the password elsewhere faster, when the list of sites an attacker is interested in is small. An attacker could try every site in the Alexa 1m before anyone knows the sites passwords were dumped anyways.
You say "it assumes your remote git repository may be malicious", but you don't do anything to protect your users' metadata?
http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf
http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf
Ah great find. This also needs to be checked. Thanks
This should have been checked before starting to implement and advertise your "secure" password manager. Just saying.
Edit: What, expecting people to do research before they make a software that users are supposed to entrust sensitive data to is so unreasonable it deserves silent downvotes?
Edit: What, expecting people to do research before they make a software that users are supposed to entrust sensitive data to is so unreasonable it deserves silent downvotes?
Maybe site names should be hidden in commit messages, especially when the password vault is publicly stored.
I wouldn't call this a serious privacy breach, you could just use a private repository.
The software claims to be usable without private repositories¹. If it can't do that, it is a serious bug.
¹ From the readme: "it assumes your remote git repository may be malicious"
¹ From the readme: "it assumes your remote git repository may be malicious"
From the context, malicious means either "tampers with your data" or "will attempt to decrypt your data", not "may find your outdated MySpace profile"
In that sense it certainly is usable without private repositories.
In that sense it certainly is usable without private repositories.
Unencrypted, unauthenticated metadata allow tampering with your data: http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf
Ok, just to make things clear, and to make sure I understand, an attack could look like this;
1. I trick you into using my GitEvil Repository Service (GERS™).
2. After you upload your data, I swap target site information (in this case name) with the name for GERS™.
3. Next time you log in to GERS™, you accidentally send the login information for target site instead.
4. Profit
In that case, keeping with the wish to keep the manager searchable without the master password, would it be possible to mitigate this by HMAC'ing the encrypted password with, for instance, the site name?
As should be obvious from the above, I'm no crypto expert.
1. I trick you into using my GitEvil Repository Service (GERS™).
2. After you upload your data, I swap target site information (in this case name) with the name for GERS™.
3. Next time you log in to GERS™, you accidentally send the login information for target site instead.
4. Profit
In that case, keeping with the wish to keep the manager searchable without the master password, would it be possible to mitigate this by HMAC'ing the encrypted password with, for instance, the site name?
As should be obvious from the above, I'm no crypto expert.
Yes, if you don't care about GERS™ knowing which sites you use, when you add accounts to them, when you chance passwords, and all the other sensitive information that can be extracted from metadata.
> would it be possible to mitigate this by HMAC'ing the encrypted password with, for instance, the site name?
In that case you duplicate the metadata: You keep one datum in plain text for search purposes, and a second for MAC/verification purposes. That's a somewhat awkward construction, and you can accidentally create new security holes in your application (by using the MAC'd metadata at point A and the plain metadata at point B – there's a bunch of high-profile CVEs created this way).
Alternatively, you can MAC the metadata separately from the password. However, (H)MAC involves a secret key that must not be shared in plain text. So you'd need encryption anyway to be able to verify the MAC key.
In either case you still allow a few attacks: Attackers can delete entries (DoS), attackers can selectively replace entries with older versions (DoS or information leakage if the password still works), and probably a few others.
Using the password AEAD to encrypt the whole database, not just passwords, not just individual entries, is not just safer, but also reduces complexity.
> would it be possible to mitigate this by HMAC'ing the encrypted password with, for instance, the site name?
In that case you duplicate the metadata: You keep one datum in plain text for search purposes, and a second for MAC/verification purposes. That's a somewhat awkward construction, and you can accidentally create new security holes in your application (by using the MAC'd metadata at point A and the plain metadata at point B – there's a bunch of high-profile CVEs created this way).
Alternatively, you can MAC the metadata separately from the password. However, (H)MAC involves a secret key that must not be shared in plain text. So you'd need encryption anyway to be able to verify the MAC key.
In either case you still allow a few attacks: Attackers can delete entries (DoS), attackers can selectively replace entries with older versions (DoS or information leakage if the password still works), and probably a few others.
Using the password AEAD to encrypt the whole database, not just passwords, not just individual entries, is not just safer, but also reduces complexity.
Thankyou for the clarification
Is the above and the replies by the author really so unworthy of discussion that they require a downvote? Or is someone just disagreeing?
I've been using `pass` for the past few years (I wrote a post on setting it up on OSX which has been fairly popular [0]). However last month I switched to 1Password (I signed up to the family plan trial - I'm not set on it though).
The main thing I like about 1Password is the browser integration. It just makes life so much easier being able to click a button and have the password automatically entered into the form. I have a script ([1] - should be easy to adapt for this) which would poll Chrome for the current URL, decrypt or generate the password, and copy it to the clipboard - but clicking a button is a lot less friction.
1Password also has a xkcd-style password generator option, which is great for things like Netflix that you need to type in on TVs and such.
The main reason why I signed up for 1Password was so I could use it with my family, but the browser extensions only work on OS X 10.10+, so that rules out 2/3 family members (who run Windows 10 and OS X 10.6). You can access the passwords online, but it's no way near as user friendly. If anyone has a good recommendation of an alternative (I'd prefer open source), let me know!
[0] http://www.stackednotion.com/blog/2012/09/10/setting-up-pass...
[1] https://github.com/lucaspiller/passosx
The main thing I like about 1Password is the browser integration. It just makes life so much easier being able to click a button and have the password automatically entered into the form. I have a script ([1] - should be easy to adapt for this) which would poll Chrome for the current URL, decrypt or generate the password, and copy it to the clipboard - but clicking a button is a lot less friction.
1Password also has a xkcd-style password generator option, which is great for things like Netflix that you need to type in on TVs and such.
The main reason why I signed up for 1Password was so I could use it with my family, but the browser extensions only work on OS X 10.10+, so that rules out 2/3 family members (who run Windows 10 and OS X 10.6). You can access the passwords online, but it's no way near as user friendly. If anyone has a good recommendation of an alternative (I'd prefer open source), let me know!
[0] http://www.stackednotion.com/blog/2012/09/10/setting-up-pass...
[1] https://github.com/lucaspiller/passosx
I've not used it myself but I believe LastPass is the most user friendly option. I have no tech family that use it and love it's ease - not sure about OS X 10.6 support but certainly has windows and OSX support (https://lastpass.com/misc_download2.php).
I like KeePass2 which is open source but nothing like as smooth as LastPass (No browser integration on OSX and integration on firefox for windows works but isn't perfect).
I like KeePass2 which is open source but nothing like as smooth as LastPass (No browser integration on OSX and integration on firefox for windows works but isn't perfect).
You can read the agilekeychain with python, it's not amazing of course but you could build basically anything you want on top.
https://pypi.python.org/pypi/blimey/0.9.4 https://pypi.python.org/pypi/1pass/0.2.1
https://pypi.python.org/pypi/blimey/0.9.4 https://pypi.python.org/pypi/1pass/0.2.1
The code looks very clean and well organized. It appears to be doing things as simply and correctly as possible.
A 5 minute glance through the code didn't reveal any vulnerabilities. That's a better result than most.
A 5 minute glance through the code didn't reveal any vulnerabilities. That's a better result than most.
Shameless self plug: https://github.com/creshal/yspave
Password manager that is actually safe against attackers with access to your data at rest by encrypting everything (with authentication), including metadata.
Password manager that is actually safe against attackers with access to your data at rest by encrypting everything (with authentication), including metadata.
Simple alternative: storing passwords in gpg encrypted files and using emacs.
Emacs has EasyPG so when you create a file with .gpg extension and try to save it prompts you for a password to encrypt this file with. Similarly if you open a .gpg file it asks you for a password for decrypting it. This way your only dependency is emacs and you can store passwords file wherever you like. And you don't expose names of sites you need passwords for.
Emacs has EasyPG so when you create a file with .gpg extension and try to save it prompts you for a password to encrypt this file with. Similarly if you open a .gpg file it asks you for a password for decrypting it. This way your only dependency is emacs and you can store passwords file wherever you like. And you don't expose names of sites you need passwords for.
> The most important difference is passgo is not GPG based. Instead it uses a master password to securely store your passwords.
"Instead" here seems to imply that GPG cannot securely store data in a password-protected file, which it can. (See the --symmetric option.)
It just simply uses a library, and perhaps a custom serialization format / a different format from what GPG uses.
One of the reasons why I encrypt my keyring with GPG (and I use a tool that uses/wraps GPG) is because I can recover the keyring then with only GPG: I don't need the actual keyring program, just GPG and the password.
"Instead" here seems to imply that GPG cannot securely store data in a password-protected file, which it can. (See the --symmetric option.)
It just simply uses a library, and perhaps a custom serialization format / a different format from what GPG uses.
One of the reasons why I encrypt my keyring with GPG (and I use a tool that uses/wraps GPG) is because I can recover the keyring then with only GPG: I don't need the actual keyring program, just GPG and the password.
For newbies, it would be helpful to explain how to retrieve the encrypted password, aka ./passgo www.example.com. Didn't see it listed on the help and github page.
Yay a password manager I might actually use, very impressed so far.
If you don't mind me asking, what's the features you're interested in that other managers don't have?
I've been tinkering away on my own password manager for a while, but since it's not made in a hype language, it gets zero exposure on HN.
I've been tinkering away on my own password manager for a while, but since it's not made in a hype language, it gets zero exposure on HN.
Off the top of my head it should:
- Work offline
- Work on multiple platforms
- Encrypt the passwords
- Backups/distribution should not be dependent on a single provider
- Ease of use (command line is fine, great even, but for the love of god make it simple)
- Not require me to remember to copy around an encryption key
- Open source is a great bonus
- Work offline
- Work on multiple platforms
- Encrypt the passwords
- Backups/distribution should not be dependent on a single provider
- Ease of use (command line is fine, great even, but for the love of god make it simple)
- Not require me to remember to copy around an encryption key
- Open source is a great bonus
Hm, seems my solution ticks all checkboxes except multi-platform availability (python in e.g. Windows is… not fun). I'll keep that in mind for the inevitable rewrite, thanks for the feedback.
I'm still on the fence about password managers. I always worry that I'll end up on a computer without my passwords and not be able to logon.
I'd have to be without my phone, my tablet, and my laptop, while needing to be able to log into something. I can't think of a situation in the last couple years where I've not had at least one of those things, to say nothing of not having one of those things and needing to log into something.
Very nice. I like the key feature being that your encrypted vault can be publicly posted. In a team environment, does it make sense to share the master password with all team members? Or is passgo designed for just the individual in mind?
I have been looking at https://www.vaultproject.io for team credential storage and sharing.
I have been looking at https://www.vaultproject.io for team credential storage and sharing.
Sharing a password is bad for several reasons.
I plan to build sharing in to passgo, since I realize it would simplify things for a lot of teams
I plan to build sharing in to passgo, since I realize it would simplify things for a lot of teams
Sharing a password can be a good thing in some circumstances. My CO-founder has all my passwords to my encrypted backups and important business accounts. Just in case I perish, for example. Or in case I forget my backup password at an inconvenient time.
Sharing the password informally generally leads to bad practices, like a group email with the password, or multiple sticky notes.
A password sharing solution I have no problem with since there are real reasons to share
A password sharing solution I have no problem with since there are real reasons to share
As a Go developer, I'm curious. Why is it that whenever a project built in Go is submitted to HN, the title mentions that it's built in Go? What makes the language special that it's worth mentioning?
This question comes up every time a "X written in Y" is submitted. Some times the language implementation is a novelity, but usually it's just a non-redundant piece of information.
Many people on this site care about the language, so why should we not include it? People who dislike the Y ecosystem are free to ignore it, and people who have been looking for an X implementation save some brain cycles figuring out what it's written in.
Personally I think more articles should include this. I'm always disappointed when a cool-sounding project is written in Node..
Many people on this site care about the language, so why should we not include it? People who dislike the Y ecosystem are free to ignore it, and people who have been looking for an X implementation save some brain cycles figuring out what it's written in.
Personally I think more articles should include this. I'm always disappointed when a cool-sounding project is written in Node..
It reads to me, in one simple word, as "not Node, so you don't need tens of megabytes worth of node modules and you don't need a working C compiler in case some of these modules want to compile stuff natively (something that is more and more common in my experience). Also, performance and startup time (!) will be good."
I'm not sure why that happens, but for me the language gives me 2 extra bits of information.
1. Cool, it'll run anywhere i need it to (presumably) without dependencies.
2. Cool, I love that language, I wonder how they did it.
For many other languages, the checkbox for 2 will be ticked as well though.
1. Cool, it'll run anywhere i need it to (presumably) without dependencies.
2. Cool, I love that language, I wonder how they did it.
For many other languages, the checkbox for 2 will be ticked as well though.
Because "… in Go" gets more upvotes.
A neat idea, but then I think wouldn't it be clever to introduce such a tool with a backdoor, and then convince people to use it to store their passwords publicly? I'm not accusing this project of anything nefarious, but bugs happen, and a security review wouldn't be a bad idea. Not to mention some unit tests, maybe? :)
When I use passgo, how do I collect my $200?
edit: Now that I've read the commit message; :(
edit: Now that I've read the commit message; :(
Seems interesting but why not to use GPG?
I went with a master password and AEADs because I don't like GPG.
It appeals to a bigger number of people, too, since not all devs understand GPG and shouldn't be expected to.
It appeals to a bigger number of people, too, since not all devs understand GPG and shouldn't be expected to.
Saltpack.org?
Users are encouraged to store their password files publicly, and yet the files contain a plaintext list of sites that the user has logins to!
Seems a serious privacy breach.