I think they meant it would autoinvalidate the tokens which might be valid.
I think the math on an AWS secret and access key would be ridiculous to brute force.. but other types of keys might be an interesting attack vector.
Bypassing rate limits and amplification, presumably. Just generate a huge list of keys and push once to attack many services at once with the whole set.
what about the birthday paradox however? i.e. the attacker doesn’t need to brute force a specific key, but just any key... I guess for AWS the search space is still huge enough for it not to be a problem still (but didn’t do the math)
I believe AWS secrets are 240 bits. That is a pretty massive space. I don't know how many active secrets are out there, but I think someone would need to get very lucky to collide before the attack was noticed and stopped.
Other partner's secrets may be more susceptible.
Edit: I did not consider the paired access key which is another 70 or so bits. I think you'd need to collide on both to make someone have a bad day.
You need to guess both to use them, but you only need to guess the secret to get it revoked. GitHub does not check that the corresponding access key is somewhere in the repo too before taking action. You are right about this being impractical though.
I suspect this is relying more on a "birthday paradox" approach. The goal wouldn't be to invalidate a particular secret, but rather that with a relatively small number of randomly generated secrets, you would be taking advantage of this setup to invalidate at least some.
Trying to use millions of generated tokens is not really feasible.
Most services will throttle or block you quickly. Also often you would need to know the permissions the token has to get any access.
Writing millions of generated tokens to a text file and pushing them to Github is easy.
There is obviously no meaningful benefit to doing this, except potentially breaking some random deployments until they can replace the keys.