I am maintaining an existing Java product (which has a HUGE code-base). I discovered that it is setting (and getting) two of its internal passwords as Java system properties, at no less than 4-5 different places (methods). Now, the problem is, the passwords are being stored as plain text in the Java system properties, and so, the same is visible to external entities, as the application is not using any Java Security Manager. For example, if the application (process) is running on port number 1234, we can run the Java command:
jinfo -sysprops 1234
to view both the passwords as values of the corresponding Java system properties. I wish to ask if there is any remedy to this without changing the existing code-base too much? The desired effect would be to "hide" the two Java system properties (denoting the two passwords) from all external entities.
It may be noted that introducing a Java Security Manager into the application may not be a solution, as if we revoke read permissions from the said two Java system properties using the Java Security Manager, the application codes which read those properties would crash. Same is applicable for storing the passwords in encrypted form, as that would crash all codes within the application which are expecting to read the passwords in clear text form.
To give a bit more context, the said two passwords we are storing as Java system properties are actually passwords to access two key-stores, and Tomcat requires that we store the said two passwords in plain-text format. Given this, can anyone suggest any workarounds, such that only Tomcat will be able to see the two passwords as-is, while they will be invisible to all other external entities?
Or, is there any way to place the said passwords in other in-memory locations (like static variables) which only Tomcat can (be made to) read instead of placing them as system properties which is exposed to anyone?
So you're trying to guard against an attacker who has access shell control over the machine (because only then could he run Java tools)? If an attacker gets that far, you have much bigger problems than passwords in some properties, wouldn't you agree?
The J2EE standard for security would never expose passwords to the web application. That's one of the things that "container managed" means. The container (Tomcat) manages the password checking and the webapps not only don't get involved, they don't even get informed when you login.
The passwords for the keystore for Tomcat are defined in plain text in the Tomcat server.xml file, but as Ulf pointed out, if people can see that file, the game is already over. The Tomcat keystore only holds SSL security certs, however. The passwords for user logins are not held anywhere within the system - they're checked by the Realm module. Note that there's one exception: tomcat-users.xml, but that's not a recommended option for production servers anyway. And you can swap Realms without making any application changes.
On the other hand, if you aren't using J2EE standard security and are instead using a roll-your own login/security system... well, that's one of about 11 reasons why I don't recommend using a roll-your-own security system.
Any other security systems you're working with, such as having a need for an application to invoke a secured external service, you're on your own. You can use JNDI to keep them from being actually stored within the webapp, you can put them in properties under the WEB-INF directory to protect them from direct external access via URL request, but these are all application design considerations.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.
Ulf Dittmer wrote:So you're trying to guard against an attacker who has access shell control over the machine (because only then could he run Java tools)? If an attacker gets that far, you have much bigger problems than passwords in some properties, wouldn't you agree?
Information Assurance (IA) doesn't care. I've argued and argued "You have to be ROOT to even see this file...if they've gotten that far, you've lost already!" It falls on deaf ears every time. In the end, it's more about defeating the security scanners than actually protecting your passwords from hackers.
The only reason why I'm posting here is that I'm faced with this same problem because a security scan found DB passwords in one of our properties files and this thread is 5th on the Google search I performed.