Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passage: A fork of password-store that uses age instead of GnuPG

github.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Passage: A fork of password-store that uses age instead of GnuPG

#51

Post by FiloSottile »

tex0 wrote: post #40
FiloSottile wrote: post #19

Earlier quoted context omitted.

We designed the plugin protocol ( https://hackmd.io/@str4d/age-plugin-spec ) and generally the age recipient/identity structure specifically to enable the use of hardware or remote keys! 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…

Really looking forward to age 1.1.0 so we can give gopass mature age support as well. Stupid question: Are only YubiKeys supported or also other hardware tokens?

age-plugin-yubikey supports all PIV tokens. There are other 3rd party plugins in development for other hardware tokens. The v1.1.0 Go API will be able to drive arbitrary plugins, so you should be able to integrate with all of them!

Re: Passage: A fork of password-store that uses age instead of GnuPG

#53

Post by FiloSottile »

emptysongglass wrote: post #42

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…

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.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#54

Post by Xylakant »

gregoriol wrote: post #48
Xylakant wrote: post #47

Earlier quoted context omitted.

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

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.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#55

Post by SahAssar »

gregoriol wrote: post #48
Xylakant wrote: post #47

Earlier quoted context omitted.

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

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)

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.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#56

Post by emptysongglass »

FiloSottile wrote: post #53
emptysongglass wrote: post #42

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…

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.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#57

Post by Ar-Curunir »

emptysongglass wrote: post #42

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…

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

Re: Passage: A fork of password-store that uses age instead of GnuPG

#58

Post by sig-io »

INTPenis wrote: post #49
emptysongglass wrote: post #42

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…

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 te…

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.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#59

Post by Xylakant »

sig-io wrote: post #58
INTPenis wrote: post #49

Earlier quoted context omitted.

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 te…

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.

Re: Passage: A fork of password-store that uses age instead of GnuPG

#60

Post by timvisee »

endymi0n wrote: post #8

> The age backend is an experimental crypto backend [for gopass] based on age. It adds an encrypted keyring on top (using age in scrypt password mode). It also has (largely untested) support for specifying recipients as github users. This will use their ssh public keys for age encryption. It is well positioned to eventually replace gpg as the default crypto backend. https://github.com/gopasspw/gopass/blob/master/docs…

I'm in the process of implementing it in prs as well.

https://github.com/timvisee/prs

Post reply on HN