Java config file security

The article Encrypt Sensitive Configuration Data with Java reminded me of one of the drawbacks of Java.

Java is a [JoATMoN] good programming language, a reasonable platform but a feable operating system. And in terms of the article above the way to protect your application from being tampered with or scanned is with the real operating system, not with the application itself.

Having said that no security is perfect and system administrators should always assume that they will get hacked. Once in the back door a hacker normally roots around quickly to find useful information for the next system step, they know that their presence is likely to be detected eventually and so go for the quick and easy option rather than the long and tedious hack.

The article and the subsequent note correctly identify Java config files as being at risk of divulging sensitive information. The methods described in the article would protect things like database passwords and network addresses, but would not help for license keys etc. Your typical hacker will take a copy of these file for later anaylsis and if the hacker neither has the tools or the knowhow to crack the config files then they will attack something else. Even if the hacker did have a 'JavaKit' and could crack at will a good security policy like 'change the database password every day' (even though there are technical issues associated with this) would limit any exposure. Even something as simple as hiding an unencrypted file in a jar works because hackers would not want to upload Mb of data to scan later as it might be noticed and would be equally wary of expanding it locally.

For any system security is a holistic issue. Fixed passwords and un-proxied un-firewalled network connections are just asking for trouble. Encrypting the files that hold the passwords is a step forward, but it is like locking the door of a tent - a deterrent only. Developers will hate an implementation of this because the config files will have to be generated (usually as an extra build step).

For programatic access to secure systems the most effective solutions involve a whole mixture of techniques, so that no one technique can have access on its own. Recent examples of this are the 'knock-knock' port access techniques (where you connect to various ports in sequence and then you get let in) and the challenge-response verification techniques.

In short, you should not need to put complete passwords in your config files if you system as a whole is built with security in mind. Dynamic passwords and reverse connections work well as long as you have designed them into your systems. If you must put a password in a config file then make it hard for the hacker, but make sure your overall security processes are in place to detect intrusion and protect systems.

A side note. 'use the file-system permissions to prevent access to the file' will be no use when the operating system has already been compromised.