I also can’t wait until people base64 their creds to get past this. Explaining to some that base64 isn’t encryption tends to be hard so I imagine people will feel safe just base64 and checking it in.
I also can’t wait until people base64 their creds to get past this. Explaining to some that base64 isn’t encryption tends to be hard so I imagine people will feel safe just base64 and checking it in.
Thankfully, the alert was sent to enough people it was caught by someone else, and the key was destroyed before someone outside could have fun with it.
A similar story from my work: "I didn't read the contents of the red warning screen because I knew I wanted to release my code".
So, they fixed it.
1. If you are worried about the people who have access to your codebase abusing a secret, you have a serious people problem that needs to be solved immediately and unambiguously. A motivated internal attacker can do almost anything. Organizations live or die on trust. One doesn’t need to scour for keys break in when they have a badge (or their mate’s) and they built the lock.
2. If you are concerned the secret will be discovered by a generic threat, it won’t, not with this string concatenation. It’s so rare. Should this become a common practice this would be over, retroactively even. We all saw this unfold with with m y e m a I l at y dot com obscurity, until the fine folks who worked on ScrapeBox turned up the right regex to start scraping those too.
3. Nothing else. You are right and responded right. Don’t put keys in code kids. Nobody likes having to erase history in their codebase, especially because of a careless mistake or a deliberate workaround.
I’m just saying… of all the dumb shortcuts that can break stuff, this one is one the mostly harmless end of the spectrum.
Most of the people in my area don’t lock their doors. A decade ago in a very different neighborhood we had locks, alarm systems, and hyper-vigilance, and still lost thousands via property theft and damage. 5 miles away.
It would be maladaptive of me to bring the same level of vigilance to a different setting. It wastes resources and clouds one’s ability to trust. It slows you down every day.
I don’t know how I could have been more clear that I don’t endorse committing secrets to code, in fact I’ve been a champion for code hygiene and security everywhere I work. I just recognize and think others should as well that there are diminishing returns for precautions where they aren’t used. The returns can diminish so low that they go negative.
Even in the safe neighborhood, one might lock up when they leave for a trip, or make other reasonable preparations to increase security and obscurity.
Yes, I said everywhen, and yes I am asserting that I just coined it and that it’s brimming with greatness :P
Agreed there are many ways that working with public repos makes everything dramatically more difficult. I’m pleased to see GHAS secret scanning become free. I’m not clear if that would include the pre-push secret scanning feature. If so you have a really decent toolset for prevention and detection. Remediation should be as easy as key rotation. Except keys get reused and rotation affects all users... if the keys can’t be rotated it’s a big chore for private repos owners, but de facto impossible with public codebases. There is no way of knowing who has cloned it (without paying for enterprise audit logs).
That seems to be quite high risk hack to rely on such security through obscurity.
;)
It was the first time for me having to even argue about this.
Also, at the risk of being pedantic, yes, some semblance of the password is definitely there. Someone can happily go off and try to brute force it.
You are confusing hashing with encryption. There is no general way to reverse a hash, be it brute force or an algorithmic method. There are an infinite number of strings that will generate the same MD5 hash. My point is, your for loop may eventually find a string, but it won't be the original AWS secret, so it won't work.