Mark, Bernard, I think you make a good point here. I would like to clarify my purpose. I do not need to hide my passwords from people who maintain the servers - in fact they enter passwords into plain text config files which are encrypted on tomcat startup and stay encrypted. I need to make sure that if the server is compromised no password info should be gathered from its config files
I would like to add that there could be two levels of security 1. Naïve - key is stored on tomcat server and therefore context file can be decrypted by the hacker. While it is naïve and can be broken (if hacker finds key in one of java classes) it is zero maintenance and can be used by people who accept this level of security 2. Better one - key is stored on removable media (USB disk, Smart Card ....) which is required to be present for tomcat to start >From management prospective it is a royal pain to encrypt each password so I >prefer to encrypt entire file. I have this setup working but there is one weak >link - I can not integrate well with tomcat. I am forced to have Host listener >which decrypt all files on start, let contexts start and then delete decrypted >copies. Not good - there is window of vulnerability, there is small chance >encrypted file will get stuck on tomcat crash (although it will be cleaned up >on next restart) plus deleted files can be recovered :-( Anyway I am looking for second line of defense here not an absolute solution. If I could only integrate with tomcat tightly I would be happy :-) PS: I am not asking tomcat developers to develop encryption - just open up file loading process. This pluggable config file loading can be useful for other things besides encryption (eg custom XML entity resolver which able to read some bits of XML from shared repositories (e.g. LDAP)for big installs with many similar configurations) Thanks again Alex Date: Thu, 06 Jan 2005 17:46:00 -0500 From: Durfee, Bernard <[EMAIL PROTECTED]> Subject: Pluggable mechanism for loading context config files Content-type: text/plain; charset=us-ascii Mark, I disagree, I have always felt it would be a good idea to have the database passwords and such encrypted when in the context files. Those context files fly all around stuffed in WAR files and stored in CVS repositories and 'Hey Bob, does this context file look right?'. That's an awful lot of chances for someone to 'see' a plain-text password, whether by malicious activity or a simple 'over the shoulder' accidental glance. If the password was encrypted using a method where the encrypted string can only be decrypted by Tomcat using a key stored safely on the Tomcat server. A key which can sit on the server and does not ever need to leave the server. The key can be used to encrypt passwords, which can then be put in the context files. Now the risk of someone 'seeing' the password in the context file is not as damaging, because the encrypted password won't be useful. In fact this could be used to encrypt the password, username, SID, etc. so that these details would be obscured as the context files go from the developer's workstation to home to their laptop to the test environment, etc. This is at best a strategy of obfuscation, but I think it is a worthy feature. Bernard Durfee -----Original Message----- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, January 06, 2005 5:25 PM To: Tomcat Developers List Subject: Re: Pluggable mechanism for loading context config files Alex, I would vote '-1' for any such addition Tomcat. Let me explain why by way of a simple example. Let us assume that Tomcat requires a plain text user name and password to connect to a database. First of all, consider the security risks if the information is stored in an unencrypted file somewhere on the server. Assuming that this file is not publicaly available, only users with access to the machine can access the file. With a little more configuration and possibly some network security only users with physical access to the machine can access the file and read the password. If one or more 'untrusted' users has physical access to the machine it is pretty much game over from a security point of view. With physical access there are a whole host of potential attacks I can think of that would enable an attacker to gain access to the file. Therefore, all we are trying to do is protect the contents of a file from a group of users all of whom are authorised to see it. What is the point? Looking at it from another perspective, lets say we do encrypt the file. How does Tomcat decrypt it? Tomcat needs access to the decryption key. If this is in a file, the file needs to be protected. How do you do this? This is the same problem we had before. We have just added another layer. It is a chicken and egg situation with no solution. The same applies to providing the password via some 'service'. How does the Tomcat process authenticate to this service to retrieve the password? It needs some credentials. Where are these stored? In a file... and so we start all over again... One thing that could work is not placing the password in a file at all but requiring it to be entered at start up. However, this exchanges a confidentiality security problem for an availability one - if the system fails it can only be restarted when there is someone present who knows the password. Also, people being people, there is a strong chance this password will get written down and your security has just got worse rather than better. Ultimately, the best thing you can do is leave the password unencrypted in a file and make sure the machine is electronically and physically secured with the right policies and procedures to ensure that it remains secure. Regards, Mark Roytman, Alex wrote: > Dear Tomcat developers, > > I would like to implement context config file encryption. It is a > pretty useful feature since passwords to various resources are stored > in those files Unfortunately the way how context config files are read > is hard coded (InputSource for Digester is created from > FileInputStream) and does not let me do so. > > It would be great if tomcat 5.5 provided some pluggable > ConfigFileLoader in HostConfig (and may be on Engine level as well) to > return InputStream for a given config file name (or decorator for > FileInputStream ). It would be also great if it were possible to > register context config file extensions other then *.xml - it would > allow to use *.exml for encrypted XML config files (will save us a > test of the file to se if it is encrypted or plain text) > > If it is not possible to make this enhancement may be you could > re-factor ContextConfig class so it can be effectively subclassed and > its input stream logic altered > > All you would need to do is to factor out > > protected void processContextConfig(InputStream) { > > } > > > from > > protected void processContextConfig(File file) { > > if (log.isDebugEnabled()) > log.debug("Processing context [" + context.getName() + "] > configuration file " + file); > > // Add as watched resource so that cascade reload occurs if a default > // config file is modified/added/removed > context.addWatchedResource(file.getAbsolutePath()); > > InputSource source = null; > InputStream stream = null; > try { > if (file.exists()) { > stream = new FileInputStream(file); > source = > new InputSource("file://" + file.getAbsolutePath()); > } else if (log.isDebugEnabled()) { > log.debug("Context [" + context.getName() + "] configuration file " + file + " not found"); > } > } catch (Exception e) { > log.error(sm.getString("contextConfig.defaultMissing") + file); > } > if (source == null) > return; > if (contextDigester == null){ > contextDigester = createContextDigester(); > } > synchronized (contextDigester) { > try { > source.setByteStream(stream); > > ..... > > If processContextConfig(InputStream) is available, we can override > this method, read from encrypted stream, decrypt create decrypted > stream in memory and pass it to the original (superclass) > processContextConfig(InputStream) > > > Thank you very much for your assistance > > Alex Roytman > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
