[ckwalsh]

> the legitimate ones I’d initially generated still worked

This spooks me. I take this to mean either:

- They are still using the compromised key for validation, meaning if you have access to any old token, you can still mutate that, maybe needing to play around with the issuing times

- They built an allowlist of all permitted tokens, and check that list first. In which case, might as well use random session ids instead of JWTs, and at the same point where the allowlist is being checked, mutate the request to inject a JWT that the backend can use.

Also, kind of curious why the switch to RSA4096 instead of elliptic curves, since they are generally faster / smaller.

[ryan-c]

I think very few customers had ever generated API keys, and as best I can tell they made an allowlist for them.

One of my suggestions to them was to switch to elliptic curve, but I imagine RSA 4096 "just worked".

I suspect they'll rework it later now that it's not "on fire".

[ckwalsh]

Ah that makes sense. For sufficiently small values of N, a hardcoded allowlist isn't a problem.

You're probably right that RSA 4096 "just worked", and some library in their stack doesn't have elliptic curve support. And again, if N is small, the verification performance doesn't matter that much.

Nice find and writeup!

[selecsosi]

My guess is they are still accepting keys signed with the old 512 key but are currently generating new tokens with a 4096 key.

[rahkiin]

No because Ryan says he is not able to create his own tokens anymore. And he has the same private key as the supplier.