51–60 of 68 posts
Earlier quoted context omitted.
Selecting (reading) data is very fast most of the time. So if no token matches I don't think this will result in a DOS.
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.
Earlier quoted context omitted.
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.
The point still stands: If you could do that, you would use them, not invalidate them.
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.
Earlier quoted context omitted.
Do you also scan when a private repo is changed to public?
I think so, and we 100% should do, but I just did a test and the secret I committed was still working a full minute after I converted the repo. Could be that the scan was in a queue, could be that it didn't trigger. I'll dig into it and make sure this is working and is fast - it's a critical time to do a full scan of the repo's git history.
Earlier quoted context omitted.
Why secret scanning is enabled only for public repos but not for private ones?
Private repos need a different approach, but committing secrets to them can still be a problem. If a secret is committed to a private repo then anyone with read access to that repo could use it. That might give those users more permissions than they're supposed to have. It's particularly a problem in large organisations, where thousands of developers may have access to a private repo, but should not necessarily have…
Thanks!
Earlier quoted context omitted.
Because it should be OK to commit secrets to private repos - that's why they're _private_, after all, right?
No, that's not not why. If you have secrets, encrypt them. Private repos can be turned public, intentionally or by mistake. Repos can be exported to give software to third parties. Also, git users clone repos, which means that those secrets are copied every where. Can you make sure those stay private too? Do you make your developers encrypt their laptops or delete repos from them before they leave their house or offi…
Also, when an attacker gets access to one private repo by some means, you don't want him to pwn your whole organization.
For example, I recently configured something to use the Google calendar API from JavaScript on the client. It's fully safe to check in this key, since it is intended to be run in client-side JavaScript anyway, but I was still nagged about it.
Earlier quoted context omitted.
Or post it on Reddit or Medium or whatever if you can't be bothered with a blog. Twitter "threads" need to die.
Reddit and Medium are no better in terms of weight and complexity.
Then everyday they email you to see if you made any progress rotating the keys.
I made this meme about it that my boss didn't find funny.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.