Only 48 hours left in the trailboss' kickstarter!

New rewards and stretch goals. CLICK HERE!



  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How to “hide” sensitive system properties like passwords set by Java applications?  RSS feed

 
Subhayan Mukherjee
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 10878
158
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We use Jasypt on our projects: http://www.jasypt.org/encrypting-configuration.html
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!