Seriously though if you are letting agents do whatever they want without a PR process that requires hardware authentication or proof of presence, you are putting your code and your org at high risk.
> want without a PR process that requires hardware authentication or proof of presence
Just curious, what do you use for this?
I built OTP Guard [1] a few years ago for exactly this problem, although I haven't seen any alternatives in the space. Does GitHub have something built-in now?
The original framing was more "local malware compromising your GitHub account" ... it never occurred to me that the malware could be a LLM. I really should update the page.
0) agent gets its own separate git user and ssh key, separate from mine
1) branch protection rules on main, only I can approve merges into main
2) any other ssh key uses (interactive login, direct git access, etc.) are ed25519-sk keys and require a touch on yubikey.
TBH, the biggest hole is that it can be unclear exactly what process is requesting a touch on the yubikey. Apple has a head start here because they can lock down the TouchID UX relatively well, but unfortunately they don’t seem to care about building a polished developer experience for 2FA on sensitive tasks.
They are probably waiting for someone else to build the right solution and then copy/steal it.
No, that would almost certainly defeat the point of selling the models.
Hardware 2FA is not a new concept and is recommended by many people for many purposes. Only the authentication token is attested, and that is the purpose of an authentication token.
> No, that would almost certainly defeat the point of selling the models.
If the best models are so anticipated that people do anything to get them, seems like remote attestation fits perfectly here. There is no need to use it for lower quality models which are used by masses. Instead, it even works for marketing narrative where they do everything they can that their great models are used only those devices they allow, and no <name your country> can't easily use them. Maybe even helps setting higher price.
Does this apply to anyone who verified their ID to get access to the slightly less restricted Codex versions, or only to security professionals who have the almost-entirely unrestricted version?
I tried enabling their "advanced security" programme on my account and it's currently refusing to continue without at least 2 keys configured.
The first "hardware key" is actually my Bitwarden faking a hardware key (I'm sure they'll start blocking BW because of this in the future) but it doesn't let me add a second one unfortunately.
It’s a security feature, Apple does the same when you register a security key. You must register two.
If you’re using real yubikeys, it’s protection against losing one. If you had two from the start, you’re not at risk of losing your only way into your account when one goes missing or is stolen.
Cobranded YubiKeys? Weird flex but ok.
Seriously though if you are letting agents do whatever they want without a PR process that requires hardware authentication or proof of presence, you are putting your code and your org at high risk.
> want without a PR process that requires hardware authentication or proof of presence
Just curious, what do you use for this?
I built OTP Guard [1] a few years ago for exactly this problem, although I haven't seen any alternatives in the space. Does GitHub have something built-in now?
The original framing was more "local malware compromising your GitHub account" ... it never occurred to me that the malware could be a LLM. I really should update the page.
[1] https://otpguard.com
My simple process is:
0) agent gets its own separate git user and ssh key, separate from mine
1) branch protection rules on main, only I can approve merges into main
2) any other ssh key uses (interactive login, direct git access, etc.) are ed25519-sk keys and require a touch on yubikey.
TBH, the biggest hole is that it can be unclear exactly what process is requesting a touch on the yubikey. Apple has a head start here because they can lock down the TouchID UX relatively well, but unfortunately they don’t seem to care about building a polished developer experience for 2FA on sensitive tasks.
They are probably waiting for someone else to build the right solution and then copy/steal it.
> Cobranded YubiKeys
More interesting than that even, a tier of YubiKeys that does not exist outside of this cooperation.
The supported features sit between a YubiKey 5C and a Security Key C and I did not find any other way to purchase this tier.
Cobranding is just good marketing at minimal incremental spend when you're running off a batch of hardware.
https://news.ycombinator.com/item?id=13635798
I hope that at some point this is not developing to remote attestation when only "permitted" devices can use the models.
Or even only letting the model be used via remote desktop style access.
We all know that's where they are going with this.
No, that would almost certainly defeat the point of selling the models.
Hardware 2FA is not a new concept and is recommended by many people for many purposes. Only the authentication token is attested, and that is the purpose of an authentication token.
> No, that would almost certainly defeat the point of selling the models.
If the best models are so anticipated that people do anything to get them, seems like remote attestation fits perfectly here. There is no need to use it for lower quality models which are used by masses. Instead, it even works for marketing narrative where they do everything they can that their great models are used only those devices they allow, and no <name your country> can't easily use them. Maybe even helps setting higher price.
If they're not useful they can't sell them. If Mythos only runs on iPhone, what good is it for cyber security research?
If it will, it will be with smartphones. YubiKeys don't quite have the properties sought here.
It could be the first step. Suddenly remote attestation "solves" the UX problem with YubiKeys as you don't need to plug them in anymore.
Does this apply to anyone who verified their ID to get access to the slightly less restricted Codex versions, or only to security professionals who have the almost-entirely unrestricted version?
This is what I want to know too. I already gave them my ID, and I won't be happy if they put more barriers to my usage
It’s an advertisement by Yubikey - the hardware key manufacturer
I tried enabling their "advanced security" programme on my account and it's currently refusing to continue without at least 2 keys configured.
The first "hardware key" is actually my Bitwarden faking a hardware key (I'm sure they'll start blocking BW because of this in the future) but it doesn't let me add a second one unfortunately.
It’s a security feature, Apple does the same when you register a security key. You must register two.
If you’re using real yubikeys, it’s protection against losing one. If you had two from the start, you’re not at risk of losing your only way into your account when one goes missing or is stolen.
Dumb question: is using the built in passkey support on my iPhone not considered “hardware-backed”, even though iPhone is using device biometrics?
I was actually thinking they would have to do this. Having to mail a physical token to a valid address is a extremely powerful access control method.