Passage: A fork of password-store that uses age instead of GnuPG • Hacker News Board

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

#41

Post by withinboredom » Sat, Dec 18, 2021, 5:56 AM UTC

ulrikrasmussen wrote: post #36

FiloSottile wrote: post #28

Earlier quoted context omitted.

I mean, most users don't root-install, but anyway the GUI application can drop a different age binary higher on the user's PATH. Or change their shell. Or a million other things. There really isn't a point to defending against code running unsandboxed on a single-user machine.

I password protect my key for the sole threat model of me physically losing my device. I am aware that all other threat models that involve someone taking remote control of my device are not fully protected against, but it at least requires significantly more effort on their part versus just doing a scan for private keys on the file system.

> Why not use disk encryption for this threat model?

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.

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

#42

Post by emptysongglass » Sat, Dec 18, 2021, 7:13 AM UTC

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

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

#43

Post by chx » Sat, Dec 18, 2021, 7:14 AM UTC

_wldu wrote: post #14

I wrote a short blog post comparing PGP and Age a few weeks ago. Some may find it of interest: https://www.go350.com/posts/age-file-encryption/

As I was reading this, my thinking was

1. What's your threat model?

2. Have you read James Mickens: This World of Ours?

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

#44

Post by darkwater » Sat, Dec 18, 2021, 7:46 AM UTC

FiloSottile wrote: post #25

jeremyw wrote: post #23

Earlier quoted context omitted.

Can you clarify re not password-protecting keys? 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.)

Yes, and they can also replace the age binary with one that uploads the password as soon as you type it. There is no meaningful security boundary to defend. We implemented support for password-encrypted keys for the cases where you store the key file in, say, Dropbox.

But in the "age binary replaced" threat scenario, isn't just gameover even with hardware keys? Eg. the same exact age code with an extra call after the print password to stdout that uploads it somewhere?

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

#45

Post by qbasic_forever » Sat, Dec 18, 2021, 7:46 AM UTC

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

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

#46

Post by aborsy » Sat, Dec 18, 2021, 7:53 AM UTC

What benefits do I get if I use Passage instead of Pass?

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

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

#47

Post by Xylakant » Sat, Dec 18, 2021, 8:20 AM UTC

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…

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

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

#48

Post by gregoriol » Sat, Dec 18, 2021, 10:11 AM UTC

Xylakant wrote: post #47

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…

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

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

#49

Post by INTPenis » Sat, Dec 18, 2021, 10:22 AM UTC

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

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

#50

Post by FiloSottile » Sat, Dec 18, 2021, 10:27 AM UTC

darkwater wrote: post #44

FiloSottile wrote: post #25

Earlier quoted context omitted.

Yes, and they can also replace the age binary with one that uploads the password as soon as you type it. There is no meaningful security boundary to defend. We implemented support for password-encrypted keys for the cases where you store the key file in, say, Dropbox.

But in the "age binary replaced" threat scenario, isn't just gameover even with hardware keys? Eg. the same exact age code with an extra call after the print password to stdout that uploads it somewhere?

The difference with hardware keys is that the primary key can’t be exfiltrated, and only one secret can be decrypted per physical touch, so rotation and recovery are possible without invalidating all secrets.