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.
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.
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.
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.
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?
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.
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.
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!
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).
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.
> 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.
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.
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'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?
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.
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..
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."
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? :)
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.