thanks for your time Justin - I will look into this - T -----Original Message----- From: Hart, Justin [mailto:[EMAIL PROTECTED] Sent: 26 November 2003 18:17 To: Tomcat Users List Subject: RE: Security Hole - server.xml
Well, right, but if you were to inherit from the realm that you wanted to use, you can manipulate the password field in any way that you wish. Unix password shadows are plantext, as are MD5 hashes. All you do now is run MD5 over the password field in the authenticate method, and viola, you have MD5 to store your passwords with. Justin -----Original Message----- From: Curley, Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 1:13 PM To: Tomcat Users List Subject: RE: Security Hole - server.xml Note - in reply to Justin - I don't have a multi-tier login So to sumarise I guess the ansswer to this is that Tomcat currently does not support encrypted datasource user/passwd or does not allow the option to enter user/passwd at startup The most one can do is to apply strict unix permissions to server.xml Thomas -----Original Message----- From: Bob Jacoby [mailto:[EMAIL PROTECTED] Sent: 26 November 2003 17:10 To: [EMAIL PROTECTED] Subject: RE: Security Hole - server.xml I consider things like this. By encrypting the password I'm protecting against casual learning of the password. I'm not really referring to hackers, but administrators of the system. There's a big difference between a hacker and an administrator. What if I need the administrator to add a new entry? Do I tell him to not look at the other entries or hold up some Men in Black gizmo after he's done to make him forget what he saw? How can I prove that the admin knowingly looked at the file to get the passwords as opposed to just making a mistake? If the passwords are encrypted the administrator would have to take a deliberate action to learn the passwords that generally can't be chalked up to a mistake. I think a similar argument applies to why Unix passwords are encrypted. By some of the arguments I've seen in response to the original post people seem to think that if a specific security precaution doesn't absolutely protect the system there's no point in doing it. By that argument, and given that there are no absolutes with respect to security, what's the point of implementing any security in the first place? This question is to those who say it's pointless to encrypt the passwords since they can be discovered via some means - not a general question of why any security should be implemented. :) Bob >>> [EMAIL PROTECTED] 11/26/03 08:09AM >>> > From: Curley, Thomas [mailto:[EMAIL PROTECTED] > I'd feel more secure with an MD5 or SHA1 encrypted user and > password that relying on unix file level security - what > happens if a hacker gets root priv's ? Er ... Without wishing to flame, but if they've got root priv's they can do what they like! They could still sniff the network and get this info what ever the app server, unless you DB server supports SSL in which case it becomes more complex..... Although weblogic appears to encrypt this, if you script the startup, the admin username/password is still avaliable and hence the encrypted passwords can be unencrypted (as the app server has to send the password to the DB) - so you just slow someone down, but if they have some brains will get through eventually. Greg > > thanks > > Thomas > > -----Original Message----- > From: Tim Funk [mailto:[EMAIL PROTECTED] > Sent: 26 November 2003 13:51 > To: Tomcat Users List > Subject: Re: Security Hole - server.xml > > > The username and password still need decrypted at some time. > It just makes > the attacker jump through 1 hoop. > > Using file permissions on the config file as well and server > security are the > ways to go. > > -Tim > > Curley, Thomas wrote: > > > Hi all, > > > > A direct question arising from a security review :- > > > > Using a datasource it is possible to remove the > 'username', 'password' or at least encrypt them using > someting like MD5 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ************************************************************** > ******************************* > This email and any attachments are confidential and intended > for the sole use of the intended recipient(s).If you receive > this email in error please notify [EMAIL PROTECTED] > and delete it from your system. Any unauthorized > dissemination, retransmission, or copying of this email and > any attachments is prohibited. Euroconex does not accept any > responsibility for any breach of confidence, which may arise > from the use of email. Please note that any views or opinions > presented in this email are solely those of the author and do > not necessarily represent those of the Company. This message > has been scanned for known computer viruses. > ************************************************************** > ******************************* > > --------------------------------------------------------------------- > 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] ********************************************************************************************* This email and any attachments are confidential and intended for the sole use of the intended recipient(s).If you receive this email in error please notify [EMAIL PROTECTED] and delete it from your system. Any unauthorized dissemination, retransmission, or copying of this email and any attachments is prohibited. Euroconex does not accept any responsibility for any breach of confidence, which may arise from the use of email. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Company. This message has been scanned for known computer viruses. ********************************************************************************************* --------------------------------------------------------------------- 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] ********************************************************************************************* This email and any attachments are confidential and intended for the sole use of the intended recipient(s).If you receive this email in error please notify [EMAIL PROTECTED] and delete it from your system. Any unauthorized dissemination, retransmission, or copying of this email and any attachments is prohibited. Euroconex does not accept any responsibility for any breach of confidence, which may arise from the use of email. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Company. This message has been scanned for known computer viruses. ********************************************************************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
