Mark, First of all, let me thank you for your detailed response. This list contains lots of qualified people, and I'm really glad I'm part of it because I'm learning more and more everyday.
All the reasons you mentioned are reasonable, but there are some pointes that makes me think a lot (and I must assume I don't have the right answers). Here they are: 1) Can I assume things in terms of security? For a matter of an example, should I always assume that the resources that my application access (like a database for example) doesn't need additional security, because it is hosted in a server, and if this so called server was attacked them worse things could actually happen? In this case, should I assume as a developer (not as a system admin), that my network is safe, that my web server is safe? 2) Whenever I think of security, I'm not only considering a hacker attack. In terms of security, is it right to delegate a web system administrator the right to know my application's database user and password? I know that security recommendations in database side tells us that an application users should only have access to what they need, in terms of commands, tables and so on, but again, should I always assume that as a developer? In my point of view, I think my application server should take care of all these issues for me... How? I don't know. In fact my only suggestion is: My app. Server should ask for a 'key' (besides the manager password) whenever I install a new application. This key could be used to encrypt all my application files, preventing anyone to open them. I know there are issues like 'Where should this key be stored?', 'Who should type this key ?' and I know that, but I can't find a good answer... I'm just exposing some ideas. Thank you all for your attention once more. This community is really great.. Yours, Marcus Milanez -----Mensagem original----- De: Mark Thomas [mailto:[EMAIL PROTECTED] Enviada em: sábado, 18 de agosto de 2007 00:31 Para: Tomcat Users List Assunto: Re: Resource Security 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] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
