3 ms·

Would a hardware token have prevented this (noob question)?

dijit 4y ago
It's a fair question, but likely not. There are "application credentials" or "API tokens" that get generated for various purposes and live long. There are many programs that do not support "credential helpers", abd those would need you to input an API token that is generated usually just once and has almost always has enough permission to clone a repository (at a minimum). The `hub` and `lab` CLI tools work exactly in this manner. If you are familiar with intellij: certain plugins that integrate with github or gitlab also require the generation of an access token so that you can do API calls to see merge requests and such: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token https://docs.github.com/en/authentication/keeping-your-accou... & https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html https://docs.gitlab.com/ee/user/profile/personal_access_toke... Applications that support credential helpers are docker (for optionally authenticating with docker registries) and git itself.
- KingOfCoders 4y ago
  I thought "Maybe" because it mentioned "Slack employee tokens".
jchw 4y ago
Is it possible for a hardware token to prevent this in theory? You could use a hardware token to compute challenge-response answers without having external access to the private key matter, as opposed to using simple secret API keys like we do today. This is basically how an HSM works too. But does it solve the problem? It prevents the keymatter from leaking, but the problem is that the API key was put somewhere sensitive and then stolen. Presumably you'd need access to be able to use the keymatter from any location where you'd normally need API keys: CI machines, developer workstations, production, etc. Worse, if you have some machines (CI, HSM) that are accessed over network traffic and that traffic is secured with an API key, you are back to square one again, where a stolen API key allows for continuous access. Would this help for auditing? No, not really. You can already have plenty of auditing and alerting to try to prevent exfiltration anywhere an API key is used. In other words, probably not. It might help a little bit just by making exploitation harder, in optimal circumstances, but it doesn't fundamentally change the problem; if dev workstations or CI are compromised, you're going to have a bad time.
TacticalCoder 4y ago
For example using private bare Git repositories hosted internally at the company with mandatory OpenSSH U2F authentication (requiring a physical key like a Yubikey) would go a long way and requires two minutes to setup. Or a VPN. Pick your poison. But then you lose convenience. Slacked picked convenience and it led to the headline: "Slack's private GitHub code repositories stolen over holidays" and the top voted HN comment so far is: "Slack is selectively and deliberately limiting public access (discoverability) to the security breach announcements.". The question is: was convenience worth it? There are other tools. There are other ways to host. There are other ways to do CI/CD. But it's less convenient. It's a tradeoff.
- KingOfCoders 4y ago
  If CEOs pressure me to neglect security, I always tell them "Do you want to be on the top of the German news magazine Der Spiegel with a bad headline?".

It's a fair question, but likely not. There are "application credentials" or "API tokens" that get generated for various purposes and live long. There are many programs that do not support "credential helpers", abd those would need you to input an API token that is generated usually just once and has almost always has enough permission to clone a repository (at a minimum). The `hub` and `lab` CLI tools work exactly in this manner. If you are familiar with intellij: certain plugins that integrate with github or gitlab also require the generation of an access token so that you can do API calls to see merge requests and such: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token https://docs.github.com/en/authentication/keeping-your-accou... & https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html https://docs.gitlab.com/ee/user/profile/personal_access_toke... Applications that support credential helpers are docker (for optionally authenticating with docker registries) and git itself.

KingOfCoders 4y ago
I thought "Maybe" because it mentioned "Slack employee tokens".

jchw 4y ago

Is it possible for a hardware token to prevent this in theory? You could use a hardware token to compute challenge-response answers without having external access to the private key matter, as opposed to using simple secret API keys like we do today. This is basically how an HSM works too. But does it solve the problem? It prevents the keymatter from leaking, but the problem is that the API key was put somewhere sensitive and then stolen. Presumably you'd need access to be able to use the keymatter from any location where you'd normally need API keys: CI machines, developer workstations, production, etc. Worse, if you have some machines (CI, HSM) that are accessed over network traffic and that traffic is secured with an API key, you are back to square one again, where a stolen API key allows for continuous access. Would this help for auditing? No, not really. You can already have plenty of auditing and alerting to try to prevent exfiltration anywhere an API key is used. In other words, probably not. It might help a little bit just by making exploitation harder, in optimal circumstances, but it doesn't fundamentally change the problem; if dev workstations or CI are compromised, you're going to have a bad time.

TacticalCoder 4y ago

For example using private bare Git repositories hosted internally at the company with mandatory OpenSSH U2F authentication (requiring a physical key like a Yubikey) would go a long way and requires two minutes to setup. Or a VPN. Pick your poison. But then you lose convenience. Slacked picked convenience and it led to the headline: "Slack's private GitHub code repositories stolen over holidays" and the top voted HN comment so far is: "Slack is selectively and deliberately limiting public access (discoverability) to the security breach announcements.". The question is: was convenience worth it? There are other tools. There are other ways to host. There are other ways to do CI/CD. But it's less convenient. It's a tradeoff.

KingOfCoders 4y ago
If CEOs pressure me to neglect security, I always tell them "Do you want to be on the top of the German news magazine Der Spiegel with a bad headline?".