Chris - Thanks for adding some more well-thought-out reasoning to this discussion. You've pointed out some issues that the rest of us had addressed, or even thought about, and pointing out that real security is always about more than just the simplified checkbox requirements that some security wonkos live by. This "plaintext password" discussion happens on this list about once every other month on this list in response to someone querying about it. The argument usually comes down to "if the hacker can read the config file, you've already got bigger problems." You've actually added some points that I've not seen before that deserve some serious consideration. Kudos. Jeff p.s. top-posting because it's a commentary on all that follows. You don't have to read to the bottom to see my minor comments.
> -----Original Message----- > From: cjder...@gmail.com [mailto:cjder...@gmail.com] On Behalf Of chris > derham > Sent: Friday, February 25, 2011 3:55 AM > To: Tomcat Users List > Subject: Re: [OT] Memory Leak in Tomcat > > 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 __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
