I read recently about whether you should store your database passwords in config files, environment variables, docker secrets, etc. But if somebody can steal it from those places, then s/he can already inject code into your system, so they can easily use an existing database connection for example instead of looking for the database password. So why would a hacker bother with stealing your database password?
-
What if you've checked your config file into your public Github repo by accident? Or you've got a status page which includes your environmental variables? Neither case would require code injection to the system– MatthewFeb 7, 2019 at 15:19
-
@Matthew I don't have the config files in the same folder as the code...– inf3rnoFeb 7, 2019 at 15:59
-
Very sensible - but there are a lot of devs who aren't!– MatthewFeb 7, 2019 at 16:07
-
@Matthew Sure, I understand.– inf3rnoFeb 7, 2019 at 16:07
Add a comment
|
1 Answer
But if somebody can steal it from those places, then s/he can already inject code into your system
This premise is wrong. Especially for a config file, there are multiple ways the password could be stolen without the attacker having the ability to modify code. Some examples:
- From old backups of the source code.
- Accidental check in of the config file into a public repo (as per Matthews comment)
- Any situation where the attacker can read but not write to files.
For environment variables and docker secrets, the risk of an attacker gaining read access is much lower. A more serious compromise would be needed, and that would increase the likelihood that the attacker could also modify the source code. This, inscidentally, is exactly why these methods of storing passwords are prefered over the simple config file!
Anyway, from a practical point of view it is much less of an headache for the attacker to connect directly to the database with the password, then having to modify an existing application to do the work for you. But you are right, once the attacker have gotten that far you are already owned any way.
-
Well I don't version control my config files and I don't store them in the same directory as the code, so I cannot backup them with the code or push them to a public repo by accident. I think the 3rd point makes sense only if the database has some sort of public interface where they can login with the stolen credentials. Thanks! I think the conclusion that if you do it properly then storing them in config files is ok too. Ofc. if you can use docker secrets, then probably that is better.– inf3rnoFeb 7, 2019 at 16:07
-
1@inf3rno I would not be so sure about those config files. Even if you do everything correctly, who knows if everybody else will in the future. But that is a separate question. :-)– AndersFeb 7, 2019 at 16:11
-
1I don't know whether this is a webapp or what you're building but filesystem vulnerabilities in webapp are a pretty common issue. Something like mistakenly setting read permissions for everyone on your config file, or a directory traversal bug could expose your config file along with your password. Also, you asked about the benefits of these approaches, not about your particular implementation. I've encountered many times where a ../ in a URL exposes secrets. It's all about defense in layers.– DaisetsuFeb 7, 2019 at 20:05