Passage: A fork of password-store that uses age instead of GnuPG
github.com
github.com
https://github.com/gopasspw/gopass/blob/master/docs/backends...
We used gopass at one of the earliest startups I worked for until we realized that all secrets needed to be manually rotated every time an employee left. I still use gopass for personal use but the idea of using it in a teams environment is just untenable unless you have nothing more than a handful of secrets to worry over.
Age doesn't fix this. It just tries to make things simpler but in return you lose out on a bunch of standard interops that have propagated around GPG.
I was legitimately excited about a new secrets backend until I understood nobody is actually writing it to solve real world problems. It largely appears to be a case of "writing it to do fewer things because that's what Unix hackers like".
No password manager that I’m aware of solves this or even claims to. When an employee leaves, you need to assume that they retain control of all passwords they previously had access to. They could have made a copy that’s beyond the control of your password manager (for example saved the password in the browser). What helps are reducing shared passwords, relying less on passwords in general (SSO, IAM, …) but for some cases you just have to bite the bullet and rotate the credentials.
Using hardware based keys for accounts that require shared access is a pain, sometimes even effectively impossible (AWS allows a single U2F token on its root account, effectively making it impossible to grant 2 or more people access to it, if using a hardware token)
And then, not all services provide 2fa, less with a physical key and for some, 2fa is comparatively easy to circumvent. But all of that holds true for every password management solution that manages long-term credentials (that is: including api tokens, access keys, certificates, …)
The only thing that saves you is personalized accounts that you can deprovision - from a management perspective I love SCIM and SAML, even with all their technical flaws.
Also that would still mean rotating any tokens/m2m keys that have been issued.
The "proper way" would be to try to minimize how many tokens/keys are readable by employees (they should probably be only read by deployment jobs etc.) and use SSO for interactive logins. When offboarding a user it should be enough to remove the user from the SSO provider and rotate any tokens/m2m keys that the employee actually had access to (as long as the employee did not get access to issue new tokens).
Unfortunately a lot of services treat SSO as a "premium" feature and require "call us" enterprise plans for it.
It’s not really clear to me how it could be even expected to do so, or what gives the impression that the goal of a 650-lines bash script would be to scale “from 1 to enterprise”.
Still, asserting that only your problems are real world problems and worth solving is pretty reductive.
So, yes, it is possible and we don't need yet another encryption backend that already does what the existing backend does just because it's "lighter/sexier".
What we should be doing with GPG is building abstractions (Keybase) and contributing to modernization efforts like Sequoia. Age is disruptive without showing its value to that disruption.
It's not clear that this is a problem for a non-enterprise use case, so I wouldn't make strong claims like "age is not solving any problems that really matter".
It's my impression that you push these changes to the git repo, so any other employee would pull and the files would already be fixed to exclude the former employee.
So it's not a case of each employee having to run pass init, they just pull from git and get the updated files.
I believe pass for teams requires a key manager who does this and pushes to git for all employees. The optimal security would be that employees only have read access but that's not very practical.
One thing that wasn't mentioned is whether or not private keys can be stored in HSMs with age. I'm guessing since the authors recommend against password-protecting private keys that the answer is "no" but that's one reason that I pick GPG for things.
For example, https://github.com/str4d/age-plugin-yubikey makes it very easy to use PIV tokens, including YubiKeys, with age. (Well, for now with rage, since plugin support is coming in age v1.1.0.)
I argue against password-protecting keys by default because, unlike using hardware tokens, it doesn't protect against many threat models.
If I run GUI applications, let's say, as my user -- as is the default in most operating systems -- they have general access to my files, including my keys-as-files, no? (Putting aside some minor restrictions MacOS and others are slowly making.)
We implemented support for password-encrypted keys for the cases where you store the key file in, say, Dropbox.
There really isn't a point to defending against code running unsandboxed on a single-user machine.
Most people don’t add a password to the disk encryption, meaning the keys can “easily” be extracted by MITM the contacts on the chip.
Stupid question: Are only YubiKeys supported or also other hardware tokens?
1. What's your threat model?
2. Have you read James Mickens: This World of Ours?
I get that it uses only one algorithm and does one thing. But that’s not a benefit impacting the end user in practice. Actually, my Pass also uses CV25519. It’s just, one is written in Go, one in C/bash.
Looking at the list of CVEs for SSH, OpenVPN, OpenSSL and GPG, the latter has stood up pretty well. Plus, OpenPGP is a standard heavily audited which is important for interoperability (and arguably security).
It's a useful tool regardless of how widely it's used. Would it become better if others used it as well?