Christopher Schultz wrote: > Andrew, > > Andrew Hole wrote: >> Is it possible encrypt password on Resource setup? > > No (still).
And for good reason. First off all, why does the resource password need to be encrypted? The threat is that an attacker gains unauthorised access to the box locally or remotely and reads the file. If they can gain this much access to the box it is already badly compromised. An attacker that could do this can almost certainly add a malicious web application, add a filter that sniffs user passwords, read the private SSL key etc. There are very few circumstances where an attacker that has compromised the Tomcat server (and can hence add code etc) can do more damage with the resource password that they couldn't do by writing a malicious web application and deploying it. All that being said, lets assume that the resource password needs to be protected after the box has been compromised. How to protect it? If the resource password is encrypted Tomcat has to be able to decrypt it in order to use it. Where does Tomcat get the decryption key from? The options are: 1. a file on disk 2. entry by system admin on startup 3. some hardware device 1. is pointless. If the attacker can read the file with the encrypted password, they can read the file with the decryption key. 2. This is better but has a number of issues. If the service fails, an admin has to be present to restart it. You have just swapped a confidentiality issue for an availability one. 24x7 operation will require 5 admins that know this password. The password will probably be written down somewhere in plain text and is likely to be less well protected than if it was just left on the file system in the first place. This of course doesn't take account of the time taken for an admin to notice the service is down, go to the box and restart it. Further, the password will almost certainly still be cached for later reuse, eg when creating a new connection for a database connection pool. If our attacker has already compromised the box, a malicious web app and careful use of reflection will yield the password. At the cost of some resources and some custom code, you could avoid most caching issues but closed source code (database drivers etc) will still be a risk. 3. Essentially the same set of problems as 2 but with added complexity. It all comes down to a proper threat assessment. Given what an attacker who has access to the box is able to do, there are extremely few cases where protecting the password after the box is compromised is worth the effort and not enough to make this even appear on anyone's to-do list. If someone can come up with a reasonable scenario that makes encrypting the resource password necessary then I am happy to add an implementation of password on startup to my list of things to do. Mark --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
