Hacker News Reader

Comment by emptysongglass | Hacker News Reader

I don't see how age solves any of the problems of GPG that really matter i.e. how to write a simple secrets manager that can scale from 1 to enterprise.

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

View on HN

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

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.

Could it work by using 2FA with a key, and the employee has to return the key when leaving the company? (in the sense that you wouldn't have to rotate the passwords then)

No. You have to assume that the employee copied the password to a place that you have no control over - for example a browser-based password manager attached to a private sync account, possibly enrolled a second token that you have no control over. You don’t even have to assume malice for that to happen.

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.

Most services don't have a good way to restrict 2fa to certain keys which would be required for that.

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.

How is an encryption backend supposed to fix this?

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.

With Mozilla's SOPS, one can simply swap out GPG or age for AWS KMS or Vault as its encryption backend as one matures. SOPS is more or less ideal but doesn't have the ecosystem built around it pass does (Password Store for Android just one example of easily using your pass secrets everywhere).

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.

> how to write a simple secrets manager that can scale from 1 to enterprise.

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

I only recently added a second key to my password store, and ran pass init to "rotate" the encryption and add a 2nd key.

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.

Yes, but this doesn't lock people out of decrypting old copies, it's git, they can rolllback to before their key was removed, and decrypt every old secret they had access tobwhich hasn't been rotated yet. The key-rotation on every employee-change is the hard part.

You have to assume in any case and for any password manager that they retain a decrypted copy - worst case manually copying the secret to a text file.

I don't think age, pass, etc. have ever claimed to be an enterprise solution. It sounds like you want Hashicorp's Vault or even a managed secret offering like what AWS, GCE, Azure, etc. all sell.

Reply on news.ycombinator.com