Hacker News Reader

Comment by pestaa | Hacker News Reader

Is there a risk with not using different keys for work and personal?

The private bits are all in the same place: if one is compromised, so are the rest.

Your key cannot be tied to more than one identity, and if you use GitHub Enterprise, your work identity may be restricted from contributing to repos outside of the Enterprise. This is to prevent cloning private code into public spaces. For this reason, you need to have separate keys.

Interesting!

Curious though that the compliance rules are strict enough it warrants distinct keypairs, but not that strict for the devs to use dedicated hardware.

It's not a compliance rule that requires different keypairs. It's just that GitHub doesn't support using the same keypair for different GitHub users.

If you have a GitHub Enterprise user for internal code development, that GitHub Enterprise user is restricted from interacting outside of the GitHub Enterprise/ If you also need to contribute to OSS projects as part of your job, you have to use a different GitHub user, and therefore a different keypair.

If both of your keys are on the same computer they would most likely be compromised simultaneously, or not at all.

However if you're worried about this then you should probably be using a hardware token anyway - something that supports SSH authentication via FIDO2, GPG, or smart card interface.

There is also a risk using the same machine for work and personal. I’d address that first.

Right? I can’t believe how many people seemingly use the same machine for both.

About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job.

Your signing key for personal projects probably has a different temporality.

> About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job.

What does this achieve exactly?

Nobody can steal it and sign it with your key for a commit to appear as if it was signed by a regular committer to a work project that would pass the verification if there is any on the repo or CI/CD side (if that's not restricting keys by the time period). The scenario is certainly a bit far-fetched and contorted, but it is possible.

Reply on news.ycombinator.com