Vtyjkyuk

The way I see it, not storing passwords in Git (or other version control) is a convention. I suppose one could decide not to enforce it with various results, but here's why this is generally frowned upon:

1. Git makes it painful to remove passwords from source code history, which might give people a false idea that the password was already removed in the current version.


2. By putting the password in source control, you basically decide to share the password with anyone who has access to the repository, including future users. This complicates establishing roles within a developer team, which might have different privileges.


3. Source control software tends to get pretty complicated, especially "all-in-one" systems. This means that there's a risk this system might eventually get compromised, leading to password leakage.


4. Other developers might be unaware that the password is stored and might mishandle the repository - having keys in the source means that extra care would have to be taken when sharing the code (even within the company; this might create a need for encrypted channels).

I cannot say that every pattern related to infosec is good, but before breaking them it's always a good idea to consider your threat model and attack vectors. If this particular password got leaked, how difficult would it be for an attacker to use it to harm the company?

First, the non-security reason:

Password Change Workflow

Passwords change independently of a software application code. If a DBA changes a database password, does it make sense for developers to have to update the code, get a new build and release to production, and try to time it all? Passwords are a runtime configuration artifact, not development artifact. They should be injected via configuration files, environment variables, or whatever configuration paradigm you are using.

Authorization scope

Generally, version control systems provide authorization control so only authorized users can access it. But within a repository, permissions are generally either read/write, or read-only, or possibly some bells and whistles like GitHub provides. You're unlikely to find security constraints that let developers get source code, but not passwords. If you can clone a repo, you can clone a repo. Period. In many environments, developers don't have full access to production. Sometimes they have read-only access to production databases, sometimes no access. What if developers do generally have access, but you don't want all of the interns, new hires, etc. to have access?

Environments

What if you have multiple environments, like a development environment, QA environment, staging, and production? Would you store all of their passwords in version control? How would the app know which one to use? The app would need to have a way to know the environment, which would end up being a configuration setting. If you can make the environment name a configuration setting, you can make the database password a configuration setting (along with the connection string, username, etc.)

History

As others have mentioned, version control is designed to preserve history. So older passwords will still be retrievable, which may not be the best thing.

Compromise

How many times have we seen headlines in the news about source code for some product being leaked to the world? Source code is whatever is in version control. This is probably the top reason to not put passwords in version control!

However...

That said, passwords need to be stored somewhere. What the above concerns are alluding to is not necessarily that they shouldn't be stored in version control at all, rather, that they should not be stored in the product's source code repository in version control. Having a separate repo for config management, operations, etc. is very reasonable. The key is to split operations from development when it comes to security credentials, not necessarily to avoid version control altogether.

Also, for non-production environments, I've stored passwords and API keys for external systems in configuration files within the product source code as defaults. Why? To make it painless when a developer checks out the code, they can just build and run it and not have to go fetch extra config files. These are credentials that rarely change and do not lead to any trade secrets. But I would never do this with production secrets.

So the bottom-line is... it depends.

It's always important to keep in mind that suggestions do have to be tailored to fit your use-case. Security safeguards taken by, say, the NSA to protect all the zero-days they keep around for a rainy day should be much more stringent than security safeguards taken to protect up-votes on a cat-picture-posting site. On one extreme, I can think of an example when keeping passwords/tokens/etc in a private git repository might be reasonable:

If that repository is only accessed by one person and the application doesn't store any information of any value.

In that case, go to town! Just keep in mind what @d33tah said in his answer - scrubbing things out of a git repository can be surprisingly difficult (the whole point, after all, is to keep a history of everything forever) so if down the road you decide you want to collaborate with more people but don't want them gaining full access to all your systems, then you're going to have a bit of a head-ache on your hands.

That is what it really comes down to. Your code repository is in some way "public", even if only shared with collaborators. Just because you want to collaborate with someone doesn't mean you want to give them full access to your infrastructure (which is effectively what happens when you put passwords/tokens in your code repository). It is easy to think "yes, but I trust the people that I'm collaborating with!", but that is simply the wrong way to look at the scenario, for a number of reasons:

1. In actual practice a large fraction of data leaks start with internal actors (collaborators, employees). By one study about 43% of data breaches started with an internal actor. Half of those were intentional, and half accidental.


2. That last point is important and why this isn't just about trust. Roughly 20% of data breaches are accidental and caused by internal people. I'm smart enough to know that I'm not smart enough to get everything right all the time. What if I turn my repository public to make room for some fun integration tool and forget that I have credentials in it? What if I have a backup hard drive that I forgot to encrypt and it walks out of my office? What if one of my passwords gets leaked and someone uses it to guess the password for the account to my git repository (cough gentoo github repository cough)? There are any number of accidental mistakes that I can make that might result in my git repository being exposed, and if that happens and I have credentials in there and the person who finds them knows what they are looking at, I might very well be hosed. That sounds like a lot of and's but the reality is that this is how breaches happen.


3. Even if I trust someone, that doesn't mean that I have to give them full access to everything [Insert cheesy quote about how power corrupts]. Again, putting credentials in a git repository means that I am potentially giving full access to all of my infrastructure to all of my collaborators. There is always the chance that you don't know that person as well as you think, and they might decide to do something they shouldn't. Even if you personally know and trust everyone one of your collaborators with your life, that doesn't mean that they won't make some of the above mistakes (or any of the endless options that I didn't mention) to accidentally release your code.

In short, good security is about having layered defenses. Most hacks happen because hackers find weaknesses in one area that allows them to exploit weaknesses in another area, which leads somewhere else, which finally takes them to the big payoff. Having as many security safeguards in place as makes sense for your situation is what keeps the whole thing secure. This way when a backup-harddrive walks out of your office, and you realize that it wasn't encrypted, you don't have to ask "Was this a targeted attack and do I now have to change every single credential I have everywhere because they were all in the git repository on that backup drive?". Again, depending on your situation this may not apply to you, but hopefully this helps explain in what scenarios this might matter.

This convention, like many other security "best practices" is a handy way of making sure that things don't go wrong because of bad habits or routine.

If you always remember that your sensitive passwords are in your version control system and
if you never give anyone who shouldn't have the password access to the repository and
if your repository is stored as safely as these secrets require and
if your deployment process is likewise safe, secure and protected from unauthorized people and
if you can be sure that all the backups and copies of your repository are and... you can probably add a couple more "if"s specific to your context.

...then you can well store your passwords in your version control system.

Under most circumstances, at least one of those "if"s is either not sufficiently compliant to your conditions, or is outside of your control.

For example, in many settings your developers should not have access to the production database. Or the backup system is outsourced to another department. Or your build process is outsourced to the cloud.

That is why in general, not storing your passwords in your version control system is a best practice that makes sure you don't fall into one of those traps because you didn't think about them. "no passwords in git" is easier to remember than a long list of conditions that you need to satisfy to safely store passwords under version control.

Keeping secrets (passwords, certificates, keys) separate from source code makes it possible to manage source and secrets according to different policies. Like, all engineers can read the source code, only the people who are directly responsible for production servers can access the secrets.

This makes life easier for developers because they're not bound by the strict security policies that are needed to protect the secrets. Source control policies can be made much more convenient for them.

Other answers are great, but consider also the problem of backups. You have much more flexibility on where, how, and for how long you store your code repository backups if they don't contain sensitive information about how to access your server or admin accounts.

From another more security-focused angle, just your code backup might be an interesting target for unethical competitors in your business. Depending on your business, most competitors in a "rule of law" country wouldn't touch it anyway. A code backup with passwords will be a target for any criminal organization interested in your users' data, or interested in blackmailing your company.

The damage from a code repository breach would be greater with the passwords for similar reasons. Would you rather have your source code stolen and published, or have all your users exposed to identity theft, with a potential lawsuit or even criminal case against you for failing to secure their private data (think GDPR)?

"why is it actually that bad to put your keys directly in your main door, when we live far away from civilization?"

Because people who want to do bad things, will do easilly and the cost of doing hard for them is not too high. Keep your keys with you not next to the door. Common sense.

Private repo? How many people have access to download it? And how many people are connected to its computers? And then... Are all they free from danger?

It also depends on the source code control system.

Git has the attitude that the source code control system should give you a reliable history of the project. Which is not a bad attitude to have. But there's the effect that if you checked a password into git, it's very hard to remove it from your repository.

Perforce has a command "obliterate" for that purpose. If you checked in a password, or someone checks in an 8 gigabyte uncompressed video file, or someone checked in some third party code that is infringing someone's copyright and should never have been checked in, or someone who got fired checked in lots of porn on their last day at work, you can "obliterate" it. It's completely gone from the repository and from the history.