On 29/10/2010 14:53, Ronald Klop wrote: > If you have a webapp where users log in you can use there login/password > to login on the database. A little bit inconvenient for the DBA but you > don't have passwords on your servers.
It isn't quite that clear cut. There are some trade-offs to make with this approach (and I'm not sure I like them). 1. The user's password has to be available in plain text. That prevents you from storing digested passwords in the realm. 2. All the users' passwords are in memory and that is still vulnerable to an attacker. 3. If the username/password is held in the session: a) it could get persisted to disk b) it could get replicated in a cluster both of which may, or may not, be an issue. 1 bothers me the most. For the the others, once an attacker has reached the point where they have shell access as the Tomcat user (or have some other way to extract data from the heap) then it is game over for all data that passes through that Tomcat instance. As with anything security related the right solution is going to vary from environment to environment and it is always going to involve some form of trade-off. Mark > > Ronald. > > > Op vrijdag, 29 oktober 2010 15:42 schreef Rainer Frey > <rainer.f...@inxmail.de>: >> >> >> On Friday 29 October 2010 15:34:29 Mark Thomas wrote: >> > If Tomcat has access to a database and the attacker has access to a >> > shell prompt (or similar) with the same privileges as Tomcat then the >> > attacker has access to the database and there is absolutely nothing you >> > can do to prevent that. >> >> In theory, there is a way Tomcat could implement. You could >> interactively ask for all needed passwords when starting Tomcat and >> keep them only in memory. httpd does that by default for encrypted SSL >> primary keys. But in practice the userbase that would accept the >> inconvenience and the impossibility to automatically start tomcat >> would be too small to spend time for that. And the practical security >> gain is small. >> >> > Mark >> >> Rainer >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
