What can be done to secure passwords that might be stored in plain text or hashed inside a git repository?

Question

I've heard a lot lately about coders being really bad at security. For one they store passwords and sensitive information inside Git repos which are often not secured well enough. Someone then comes along and makes a copy of the repo, and in turn gets all the usernames and password or hashes for a corporate network.

What can be done to secure a Git repo? One thing I can think of off the top of my head would be to use a commit hook that checks for that sort of thing. But that could be easily by passed.

Answer 1

One thing you could do is store the passwords inside a configuration file (for example Laravel stores it inside .ENV) and then avoid committing it to the repo, by adding it to .gitignore.

Users will have to create one manually after downloading the repo.

Answer 2

Well, all of the sensible answers can be summed up in one simple rule:

• Don't do that!

There is just no safe way to commit passwords or other sensitive values into a Git repository that will be cloned by a rotating cast of developers. And there is no foolproof automated way of catching such mistaken commits. So all the advice has to be built around these concepts:

1. Preventing your developers from doing this;
2. Detecting it quickly when they do;
3. Remediating any lapses that get past your measures.

So the advice I can give is:

You need developers who give a damn

If your developers just don't give a damn about correctness and security, then abandon all hope. You can lead a horse to water but you can't make it drink.

Careful, thorough code review

Even if you have a developers who do give a damn, they will likely still slip up now and then. This means that your developers need to review each other's code, spot the mistakes and require them to be fixed.

Top-notch developer automation

Why do your developers need sensitive passwords in the first place? In my experience, this is a symptom that the developer automation is lacking. For example, a common scenario is that the application interacts with an RDBMS and so, a shared database is created somewhere and developers need credentials to log on to that.

So fix that. Use a tool like Docker or Vagrant so that your build scripts provide your developers with local, throw-away instances of all the external resources the application needs, with minimal need to configure connection strings or usernames or passwords or anything.

Code analysis tools

There are analysis tools that are able to assist such a review process by inspecting your code and guessing spots where there might be trouble. These tools can never be completely reliable; they will produce some false positives and miss some real issues. Some of the tools are also just bad, so evaluate anything carefully before you commit to it. I evaluated SonarQube on Java programs and was generally impressed with it; it does contain some rules to search for possible security weaknesses. (I have no affiliation with the company.)

Secret management tools

Instead of writing your programs so that they read secrets from environment variables or configuration files (or even worse, hardcoded secrets!), write them so that they obtain them from a secret management system like Vault or Keywhiz. This does however require your developers to work a bit harder to learn the tool and integrate with it—which in turn requires them to give a damn.

Standardize secret management

If you don't adopt a tool like Vault or Keywhiz, you should still nevertheless standardize the mechanism whereby your applications access passwords and other secrets. For example, require all of your applications to read their passwords from a file named appname-credentials.json. Then you can:

1. Have your code reviewers reject any code that doesn't follow the practice;
2. Add a rule to .gitignore to reject any file names that meet that pattern.

Structure your codebase to provide a "safe" location for sensitive files

("Safe" in scare quotes because while this is incrementally safer than lots of codebases I see, it's not really all that safe...)

One problem I keep seeing in many Java applications is that they obtain all their configuration from configuration files that get bundled with the application's JAR or WAR archive. They do this because:

1. Popular Java build tools like Maven or Gradle provide a default, conventional mechanism for bundling such configuration files;
2. Popular Java frameworks make extensive use of such files and make it very easy to access them;
3. Developers, more often than not, just don't give a damn about security or correctness.

One trick that has been used in many projects that I've been part of is to configure the build tool so that it, in addition to the default locations, it also bundles configuration files from an another, project-standard location that has a .gitignore file that prevents anything in there from ever being checked in.

This still has a weakness: the passwords don't get checked in, but they get bundled into the application archive files that your developers build. If they then hand those out to external people, they've disclosed passwords.

Answer 3

Many code static analysis tools will support searching for hard coded passwords and flagging them - this could happen early in the continuous integration process, which would at least make it less likely for code with hardcoded passwords to be merged to master.

https://www.owasp.org/index.php/Source_Code_Analysis_Tools

Ultimately, though, this is a developer education opportunity - if a developer wants to sneak in hardcoded passwords, they probably can, despite any automated blocks. Process, policy and procedure do have their place - and I think this is where they are the real answer.