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]
RE: Security Hole - server.xml
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 ? 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]
Re: Security Hole - server.xml
To connect to a database, you need the *real* userid password. (IIRC) SHA1 and MD5 are both one way hashes so you can't use it to for database connectivity. The only feasible alternative (which isn't present in tomcat) is too force a password to be entered by keyboard on tomcat startup to allow decryption of passwords. (Like protected keys for ssl) -Tim Curley, Thomas wrote: 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 ? 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]
Re: Security Hole - server.xml
If a hacker gets root privileges, the username and password for tomcat are the least of your concerns. On Wednesday 26 November 2003 08:53 am, Curley, Thomas wrote: 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 ? 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] -- Ben Souther F.W. Davison Company, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Security Hole - server.xml
You're not reusing the passwords anywhere else in the system (IE, you don't have a multi-tier login, do you?) If you do, you can quite feasibly shadow the passwords. I don't know if such an implementation exists in tomcat, but I would assume that someone, somewhere, has written a realm implementation that works with a .htaccess file, if not, you can always connect Tomcat to Apache. Having written a customized realm implementation only yesterday, I can assure you that it isn't too terribly difficult to do so, as the security is pretty well laid out in Tomcat. Justin -Original Message- From: Curley, Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 8:53 AM To: Tomcat Users List Subject: RE: Security Hole - server.xml 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 ? 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]
Re: Security Hole - server.xml
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 The Password can be digested. See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html#Digested%20Passwords -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security Hole - server.xml
The link below is for users logging-in (FORM or BASIC). Not for database connections. -Tim [EMAIL PROTECTED] wrote: 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 The Password can be digested. See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html#Digested%20Passwords - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Security Hole - server.xml
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]
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]
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
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
RE: Security Hole - server.xml
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
RE: Security Hole - server.xml
No prob, good luck. -Original Message- From: Curley, Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 1:21 PM To: Tomcat Users List Subject: RE: Security Hole - server.xml 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
Re: security of server.xml
Well, if you put in code, then every time it changes you need to recompile your code, and redeploy your application. If you put it in server.xml, you don't ever have to do that. The security on server.xml is easy: chmod 700 TOMCAT_USER TOMCAT_USER = whatever user Tomcat runs as John On Thu, 5 Jun 2003 10:40:21 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: Hi, Is there any way of taking the password and username for connecting to a database out of the server.xml, and placing it in code before the lookup is done on this?? As having the username and password as plain text is not very secure.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security of server.xml
TC 3.3.x has a variable-replacement option, which is very nice for this sort of thing. Unfortunately, it hasn't been ported to TC 4.x. Mohamed Tagari [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, Is there any way of taking the password and username for connecting to a database out of the server.xml, and placing it in code before the lookup is done on this?? As having the username and password as plain text is not very secure.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security of server.xml
HI, the database contains sensitive information and so the password and username should not be available even as a read only.. Due to the sensitivity of the data it could be seen viable to recompile the code, and redeploy your application. mo On Thu, 5 Jun 2003, John Turner wrote: Well, if you put in code, then every time it changes you need to recompile your code, and redeploy your application. If you put it in server.xml, you don't ever have to do that. The security on server.xml is easy: chmod 700 TOMCAT_USER TOMCAT_USER = whatever user Tomcat runs as John On Thu, 5 Jun 2003 10:40:21 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: Hi, Is there any way of taking the password and username for connecting to a database out of the server.xml, and placing it in code before the lookup is done on this?? As having the username and password as plain text is not very secure.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - 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]
Re: security of server.xml
Java code can be decompiled. Easily. Rogue classes can be inserted into improperly configured packages. There's plenty more. If your UNIX-like OS is unstable enough to allow a file owned by root with permissions of 700 be viewable to various untrusted users, you've got bigger concerns on your hands besides hiding the database connection password. Keep in mind, too, that the password is most like going to be transmitted in the clear...its trivial to have a packet sniffer retrieve it. I hate to self-promote, but perhaps you might want to consider picking up a copy of the Apache Tomcat Security Handbook from Wrox Press, ISBN 1861008309. John On Thu, 5 Jun 2003 16:04:43 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: HI, the database contains sensitive information and so the password and username should not be available even as a read only.. Due to the sensitivity of the data it could be seen viable to recompile the code, and redeploy your application. mo On Thu, 5 Jun 2003, John Turner wrote: Well, if you put in code, then every time it changes you need to recompile your code, and redeploy your application. If you put it in server.xml, you don't ever have to do that. The security on server.xml is easy: chmod 700 TOMCAT_USER TOMCAT_USER = whatever user Tomcat runs as John On Thu, 5 Jun 2003 10:40:21 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: Hi, Is there any way of taking the password and username for connecting to a database out of the server.xml, and placing it in code before the lookup is done on this?? As having the username and password as plain text is not very secure.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - 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] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: security of server.xml
Is your book out? I couldn't find in local bookstore. -Original Message- From: John Turner [mailto:[EMAIL PROTECTED] Sent: June 6, 2003 2:19 PM To: Tomcat Users List Subject: Re: security of server.xml Java code can be decompiled. Easily. Rogue classes can be inserted into improperly configured packages. There's plenty more. If your UNIX-like OS is unstable enough to allow a file owned by root with permissions of 700 be viewable to various untrusted users, you've got bigger concerns on your hands besides hiding the database connection password. Keep in mind, too, that the password is most like going to be transmitted in the clear...its trivial to have a packet sniffer retrieve it. I hate to self-promote, but perhaps you might want to consider picking up a copy of the Apache Tomcat Security Handbook from Wrox Press, ISBN 1861008309. John On Thu, 5 Jun 2003 16:04:43 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: HI, the database contains sensitive information and so the password and username should not be available even as a read only.. Due to the sensitivity of the data it could be seen viable to recompile the code, and redeploy your application. mo On Thu, 5 Jun 2003, John Turner wrote: Well, if you put in code, then every time it changes you need to recompile your code, and redeploy your application. If you put it in server.xml, you don't ever have to do that. The security on server.xml is easy: chmod 700 TOMCAT_USER TOMCAT_USER = whatever user Tomcat runs as John On Thu, 5 Jun 2003 10:40:21 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: Hi, Is there any way of taking the password and username for connecting to a database out of the server.xml, and placing it in code before the lookup is done on this?? As having the username and password as plain text is not very secure.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - 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] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security of server.xml
Yes, its out. It's only one-third mine, though...there were several authors, as is the custom with Wrox Press. I'm not surprised your local store doesn't have a copy...its a fairly esoteric subject, all things considered. Probably explains the 34K+ sales ranking on Amazon, too. LOL John On Fri, 6 Jun 2003 14:24:34 -0400, Phillip Qin [EMAIL PROTECTED] wrote: Is your book out? I couldn't find in local bookstore. -Original Message- From: John Turner [mailto:[EMAIL PROTECTED] Sent: June 6, 2003 2:19 PM To: Tomcat Users List Subject: Re: security of server.xml Java code can be decompiled. Easily. Rogue classes can be inserted into improperly configured packages. There's plenty more. If your UNIX-like OS is unstable enough to allow a file owned by root with permissions of 700 be viewable to various untrusted users, you've got bigger concerns on your hands besides hiding the database connection password. Keep in mind, too, that the password is most like going to be transmitted in the clear...its trivial to have a packet sniffer retrieve it. I hate to self-promote, but perhaps you might want to consider picking up a copy of the Apache Tomcat Security Handbook from Wrox Press, ISBN 1861008309. John On Thu, 5 Jun 2003 16:04:43 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: HI, the database contains sensitive information and so the password and username should not be available even as a read only.. Due to the sensitivity of the data it could be seen viable to recompile the code, and redeploy your application. mo On Thu, 5 Jun 2003, John Turner wrote: Well, if you put in code, then every time it changes you need to recompile your code, and redeploy your application. If you put it in server.xml, you don't ever have to do that. The security on server.xml is easy: chmod 700 TOMCAT_USER TOMCAT_USER = whatever user Tomcat runs as John On Thu, 5 Jun 2003 10:40:21 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: Hi, Is there any way of taking the password and username for connecting to a database out of the server.xml, and placing it in code before the lookup is done on this?? As having the username and password as plain text is not very secure.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - 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] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: security of server.xml
We have the people who deploy to our servers use the AES routines from http://www.bouncycastle.org/ and create encrypted username and passwords to place in the server.xml or web.xml and then decrypt in the java. Have not kept up to date on what routines sun provides in its packages these days. Of course you have to store the keys some place, keystore I guess would be the best, and if someone is capable of spending enough time on your server to track down all the file locations needed to crack the code, you have other worries. This does not solve any insecure transmission to and from the database but with luck you have that behind a firewall. Jeff -Original Message- From: Mohamed Tagari [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 9:05 AM To: Tomcat Users List Subject: Re: security of server.xml HI, the database contains sensitive information and so the password and username should not be available even as a read only.. Due to the sensitivity of the data it could be seen viable to recompile the code, and redeploy your application. mo On Thu, 5 Jun 2003, John Turner wrote: Well, if you put in code, then every time it changes you need to recompile your code, and redeploy your application. If you put it in server.xml, you don't ever have to do that. The security on server.xml is easy: chmod 700 TOMCAT_USER TOMCAT_USER = whatever user Tomcat runs as John On Thu, 5 Jun 2003 10:40:21 +0100 (BST), Mohamed Tagari [EMAIL PROTECTED] wrote: Hi, Is there any way of taking the password and username for connecting to a database out of the server.xml, and placing it in code before the lookup is done on this?? As having the username and password as plain text is not very secure.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
