Yeah, I reacted to that too. It's like nonchalantly saying that you have all your passwords written on post-it notes at your desk.
The topic of discussion shouldn't be how to secure your desk from spying eyes, but about why having post-it notes with passwords is bad practice and just a bad idea overall.
If your private github repo accidentally goes public, the response should be "that's annoying but ultimately harmless", anything else is misguided.
Postits for passwords are better practice than memorizing passwords. If you can memorize it, it is a bad password. Password managers are better yet, but you still need the master password.
The problem is not keeping those passwords in a secure location, treat it like a stack of $100 bills.
Some folks use tools like https://github.com/mozilla/sops to store most secrets (besides the sops key, of course) in source control. Of course, you aren't committing the cleartext but if the repo gets published you should probably rotate your keys just to be safe...
Even this I would consider to be bad practice. Old versions of secrets are never relevant. Easy way to break your system:
1. Write code v1
2. Add secret
3. Write code v2
4. Rotate secret
5. Oops, some kind of problem, let's go back to known-good and redeploy (2). Broken because it tries the older secret, not the rotated secret.
What for? I've seen this happening and if there would not have been a review, it would have stayed there unnoticed.
/edit:
Also what someone considers a secret and then not, is often not well defined. If management has no clue what this is about, it is often better to only commit and push on direct and simple work order, because these need to be well understood and you have the paper trail (as that author also suggests blameful retrospectives - IMHO hilarious).
Or do we have forgotten about the basic rules sending data over the interwebs to other people computers?
Sure, but in computer programming “secrets” is also industry jargon for small strings of characters that enable authentication, like passwords or private keys, which have much higher standard of secrecy than the rest of the codebase.
A secret is something that you go out of your way to keep private. But there are a lot of other things that are private by default, but aren't really secrets, like "the brand of toilet paper I use".
This. Every CI platform under the sun has support for secrets and config that should never live in git. It's worth ensuring people know this, of course, but I'm not sure storing secrets in git is all that prevelant. Many platforms also have secrets scanning to ensure you don't accidentally do this too.
> Many platforms also have secrets scanning to ensure you don't accidentally do this too.
The reason secrets scanning even became a thing is because of how often secrets get committed to git. Some of them even lead to intrusions.
Uber (2016) – Attackers gained unrestricted access to Uber’s private Github repositories, found exposed secrets in the source code, and used them to access millions of records in Amazon S3 buckets.
Scotiabank (2019) – Login credentials and access keys were left exposed in a public GitHub repo.
Amazon (2020) – Credentials including AWS private keys were accidentally posted to a public GitHub repository by an AWS engineer.
Symantec – Looking at hardcoded AWS keys in mobile apps, discovered they had a much wider permissions scope and led to a significant data leakage.
GitHub – Over 100K public repositories on GitHub were found to contain access tokens.
I've worked at companies with developers who didn't know that once committed, the secret remains in the history even if a subsequent commit removes it. It's not trivial, and involves rewriting the history[1]. There's also no way to fix clones of the repo, and there are a handful of other ways secrets can still leak.
The most secure way to deal with secrets accidentally committed to git is to rotate the secret.
OP's target audience, judging by all the emojis and the subject matter, seems to be a pretty green junior devs who might not know any better. OP is putting themselves in their shoes as a rhetorical device, the author isn't saying that they themselves put secrets into git.
Drakim|2 years ago
The topic of discussion shouldn't be how to secure your desk from spying eyes, but about why having post-it notes with passwords is bad practice and just a bad idea overall.
If your private github repo accidentally goes public, the response should be "that's annoying but ultimately harmless", anything else is misguided.
bluGill|2 years ago
The problem is not keeping those passwords in a secure location, treat it like a stack of $100 bills.
sobellian|2 years ago
solatic|2 years ago
1. Write code v1 2. Add secret 3. Write code v2 4. Rotate secret 5. Oops, some kind of problem, let's go back to known-good and redeploy (2). Broken because it tries the older secret, not the rotated secret.
Just don't store secrets in version control.
hakre|2 years ago
/edit:
Also what someone considers a secret and then not, is often not well defined. If management has no clue what this is about, it is often better to only commit and push on direct and simple work order, because these need to be well understood and you have the paper trail (as that author also suggests blameful retrospectives - IMHO hilarious).
Or do we have forgotten about the basic rules sending data over the interwebs to other people computers?
Waterluvian|2 years ago
cobbal|2 years ago
snowwrestler|2 years ago
Sure, but in computer programming “secrets” is also industry jargon for small strings of characters that enable authentication, like passwords or private keys, which have much higher standard of secrecy than the rest of the codebase.
falcor84|2 years ago
_joel|2 years ago
cratermoon|2 years ago
The reason secrets scanning even became a thing is because of how often secrets get committed to git. Some of them even lead to intrusions.
Uber (2016) – Attackers gained unrestricted access to Uber’s private Github repositories, found exposed secrets in the source code, and used them to access millions of records in Amazon S3 buckets.
Scotiabank (2019) – Login credentials and access keys were left exposed in a public GitHub repo.
Amazon (2020) – Credentials including AWS private keys were accidentally posted to a public GitHub repository by an AWS engineer.
Symantec – Looking at hardcoded AWS keys in mobile apps, discovered they had a much wider permissions scope and led to a significant data leakage.
GitHub – Over 100K public repositories on GitHub were found to contain access tokens.
I've worked at companies with developers who didn't know that once committed, the secret remains in the history even if a subsequent commit removes it. It's not trivial, and involves rewriting the history[1]. There's also no way to fix clones of the repo, and there are a handful of other ways secrets can still leak.
The most secure way to deal with secrets accidentally committed to git is to rotate the secret.
1 https://docs.github.com/en/authentication/keeping-your-accou...
electroly|2 years ago
unknown|2 years ago
[deleted]