Committing encrypted passwords but not usernames

Question

I’m arguing with a colleague about the security of storing encrypted password on GitHub.

Our process is currently to commit a configuration file with environment variables including username and passwords. Username and passwords are opaque information in the file. They are then read by third party server who has the key to read it.

First of all, since the server is able to decrypt the password, it’s clear how this discussion might be irrelevant if we don’t trust the security of the server.

I would like to focus only on the particular file, assuming that the server is impenetrable.

My opinion is that the file should be commented to identify the various passwords and what their purpose is. Also I would leave usernames in clear text. This will make it slightly easier to maintain the file and update the relevant field if necessary. Without these pointers the configuration file looks like a wall of identical lines, each with opaque informations.

My colleague argues that this might give a hint to a hypothetical attacker.

Let’s leave aside the fact that if an attacker has access to our private repositories those passwords are the least of our problems.

Do you think that commenting the file gives away too much information or that it might make it easier to have a security hole?

Answer 1

You should never be committing secrets to source code of any kind, encrypted or not. The username to authenticate into your server is probably a bit much in terms if sensitivity on its own, let alone a password even if it is encrypted. (As an aside, it sounds like you’re storing your password insecurely - more on that below.)

I would highly recommend integrating instead with a secret storage system.

This is for a few reasons. First and foremost, source code can get lost. You can make the repo public accidentally, an attacker can get access to it while private, you can accidentally give the wrong person access, etc. - and the beauty of version control is that it’s a permanent record, so as long as a secret is in your version history once, it’s there forever.

Furthermore, humans are exceptionally bad at managing information - bad enough to need an entire highly skilled industry on simply information security - and very very prone to making mistakes. So as long as a human can touch it, and mess it up, and possibly steal it, it’s wise to build as though they will. The solution then is to reduce the number of humans who have access to the tasty treats, and the best way to do that is to automate it.

Also, you may want to reconsider how you’re protecting your passwords. Although private key encryption is strong and AES-256 is, of course, quite cryptographically secure, hashing and salting passwords is generally better practice. Aside from being more performant, you never want to be able to decrypt a password like this (because if you can do it, then the decryption key can get lost and someone else can now do it too). Salting and hashing (using a standard library like bcrypt, scrypt, PBKDF2, etc.) is better practice.

Finally, passwords are scary and this sort of thing matters. Please keep in mind this is only general information, varies by system, and might be entirely wrong if applied to your situation. So take this information with a grain of salt and skepticism and don’t make any decisions off of it.

Good luck!

Answer 2

If you are talking about the distribution of configuration secrets, I would argue that the password is the secret, not the username or a comment which describes, what it can be used for.

It's true, that this might help an attacker and you can therefore call it a defense-in-depth measure to encrypt usernames and comments, which only adds some more work for an attacker as it is a security by obscurity approach. But then you should also delete all comments from your source code and obfuscate it.