Does git history compromises files encrypted with OpenSSL?

Viewed 172

I encrypt a file with sensitive data using OpenSSL:

openssl enc -aes-128-cbc -a -d -salt -pass pass:<my_custom_password> -in <file_path> -out "<out_file_path>" -md md5

Of course, the password is not stored in the repo.

Sometimes I need to decrypt this file, make changes to it, encrypt it back and push to the repo.

Is there a way to crack my security if I use over 40-characters long password?

2 Answers

If you can avoid it, it's better to keep sensitive data outside of the repository (in your CI system's secret store, for example). That's because usually it's copied around less and therefore has less possibility to leak.

If you pick a strong password and a strong algorithm, it will be secure for a long time to come. But if you make a mistake, and accidentally pick a weak algorithm, like RC4, or you make some other bad decision, it's hard to undo without rewriting your entire history. If you did pick a weak choice, and an attacker got a hold of your repository (which does sometimes happen), they could attack the weakest version of your data.

As for the algorithms and tool you've chosen, there's no reason to use MD5 for any reason, whether or not it's weak in this particular case. The default in modern versions of OpenSSL is SHA-256, and you should specify it explicitly. AES-128 is fine, but because openssl enc doesn't support any message integrity, an attacker can tamper with the data. This probably isn't a problem because Git stores data in a structure much like a Merkle tree, and you'd be able to detect it as long as you could verify your history was intact.

So while what you're doing is okay, and is commonly used for large secrets, it's better to store it outside of the repository in a purpose-dedicated secret store if that's possible.

This can be generalized to a question of: Is there any such thing as a perfectly secure hashing/encryption? And the answer is no.

This can also be generalized as "is X secure?" and the answer is also no.

Assume insecurity, and assume that there is a brilliant, motivated, and malicious hacker who is actively devoting limitless resources to gathering your data, and then make the most secure setup that you can.

When you're done, re-assess your security regularly to determine if you can improve it.

There are counterbalances to this:

If your security is so strong that it is nearly impossible for you and your employees to gain access, and it's severely hampering your productivity, then you probably need to think of a better way to accomplish your security goals, or make some tradeoffs.

The important mindset to have with security, is that nothing is actually ever secure. If you assume that your data is secure, you become complacent, and that complacency leads to data breaches.

Related