Hacker News Reader

Comment by justizin | Hacker News Reader

> We cram our secrets into git

Excuse me?!

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.

For your home desk? I can buy that. But for your work desk? No way is that even remotely more acceptable than having a memorizable password.

You don't leave them on the desk. Lock them up with a key. Every office gives you file cabinet that locks.

That's basically an analog password manager, we have gone full circle.

Or we return the metaphor to github repos, having a separate cabinet is like having a secret vault so that secrets are not directly in plain view in the repo itself, which is exactly what you should be doing.

Not quite full circle as we have now agreed that writing your passwords down on paper is acceptable.

I'll grant you that, it's not the medium that matters. But pen on paper wasn't my objection, it was the post-it note on the bezel of your monitor.

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.

Just don't store secrets in version control.

That one has an easy fix: store secrets in a separate repo that you never roll back. That's not the reason to avoid storing secrets in git. You might be giving some junior dev here the idea that if they can solve this issue, then storing secrets in git will be ok. Obviously it's not; it's still a bad idea after you've solved this minor annoyance and, indeed, this annoyance had nothing to do with the security reason why you don't store secrets in git.

This assumes that the secrets are deployed along with everything else in the repository. Even if the same repository contains your app, they needn't be deployed together. And as far as old secrets go, they are at most as sensitive as current secrets.

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?

It’s slightly annoying when someone blunts doing something dumb by declaring some form of “we all do it.”

If source code isn't public, it's a secret by the traditional definition of the word.

> by the traditional definition of the word.

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.

1 https://docs.github.com/en/authentication/keeping-your-accou...

Yes, they happened in the past. Over 3 years back. Times change.

You can use this and crenedials rotation, amazing, I know...

https://docs.github.com/en/code-security/secret-scanning/abo...

https://docs.gitlab.com/ee/user/application_security/secret_...

https://circleci.com/blog/detect-hardcoded-secrets-with-gitg...

https://www.gitkraken.com/media/events/azure-spring-clean-20...

edit: used config/secrets management for as long as I can remember doing this cloud stuff (several years), so the excuses are very, very poor imho.

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.

Reply on news.ycombinator.com