All, I've only been on this mailing list for a couple of weeks, so am still not quite sure of the etiquette. I know people get upset about top posting or replying to an existing email and changing the subject only. Not sure about the intricacies of when people should attempt to help others on the list. I assume anybody can chip in at anytime - please let me know otherwise.
Having said this, I can't bear to see this thread anymore without chipping in. I understood from the original post that this inquiry was about a problem whereby a move from having db credentials stored in tomcat config to having windows service credentials used to log into the database. Once this happened, a memory leak occurred. Some suggestions were made as to how to track this down, and since then the thread has drifted into a discussion about the merits of this approach, and now seems to be tittering on the edge of a discussion about the merits of true SSO. I just wanted to address the first two points. The posts indicate that the service was run as local system. Moving to a domain user to make things simpler doesn't really add up for me. You've now exposed the whole network to the hacker - if they can break into the tomcat process, any action they perform will potentially have access to any network resource as the process is a domain user. The OP didn't detail the topology of the network, and if the webserver is on a DMZ with a firewall between it and the rest of the network. This may or not be more worrying than having the ability to read the password. If a hacker gets onto your webserver, there are a couple of scenarios. Either they break into the tomcat process and are constrained in it, or get full control of the whole server. The thought process of all people discussing this on this thread is that if they can read the password to the db, they can then get into the database and do bad things. Hackers are human, and as such lazy. It is far simpler to craft a fairly simple jsp page, that allows posting arbitrary SQL to the same jsp, which then asks tomcat for a connection, and then runs the SQL and displays the results. Doesn't matter how you store the password/token to access the database, once this jsp is in place they still got the ability to execute arbitrary SQL. So any discussions about which method is better to store the password are something of a moot point. Security recommendations suggest that you should secure the db to least privs. So the db should only accept connections from the webserver IP. So the ability to read the password really isn't such a big thing - if they can read it, they can only access the db from the webserver. Security recommendations suggest that you should secure the webserver to run tomcat with least privs. If you store username and password using plain text, you can run the service as a dedicated local user on the machine. When configured correctly, this will constrain what the hackers can do if they break into the tomcat process - e.g. they can only access tomcat files and no other files on the webserver. This is less risk than running as a domain account IMHO > I trust the people in the company, but the company's work is with sites that > any user all over the internet can access. so we want to perform a damage > control if some hacker would gain access to our web server, so if he can - > he won't get access to the DB, at least not with our help of displaying the > user and password to access the DB :]. So secure these other sites, such that they can't access this website. e.g. run the other sites as local user A and run your site as local user B. That way your concern is potentially mitigated, as long as the hacker only takes control of the other sites process. An alternative would be to separate the two sets of sites, either on separate physical machines, or using a virtual machine and a physical machine, or multiple virtual machines. That way if they break into these other sites, they won't have access to your site or its configuration. There is a tool http://www.jasypt.org/encrypting-configuration.html which allows you to store the configuration information in an encrypted form. I mention it as this might appease some less technical/ceo/manager type people and it might help you to tick any security check list that says "no passwords in clear text". However be sure to understand this won't make your site any more secure. If someone can obtain access to the config file containing plain text password, when the setting is encrypted they would still be able to access the encrypted one and find the key used to unencrypt it. Hope that helps Chris
