tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hart, Justin" <JH...@sfa.com>
Subject RE: Security Hole - server.xml
Date Wed, 26 Nov 2003 18:35:00 GMT
No prob, good luck.

-----Original Message-----
From: Curley, Thomas [mailto:thomas.curley@euroconex.com]
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:JHart@sfa.com]
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:thomas.curley@euroconex.com]
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:RJacoby@tceq.state.tx.us]
Sent: 26 November 2003 17:10
To: tomcat-user@jakarta.apache.org
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

>>> Greg.Cope@pfizer.com 11/26/03 08:09AM >>>
> From: Curley, Thomas [mailto:thomas.curley@euroconex.com]

> 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:funkman@joedog.org]
> 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> **************************************************************
> *******************************
> 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 emailadmin@euroconex.com 
> 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
*********************************************************************************************
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 emailadmin@euroconex.com 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

*********************************************************************************************
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 emailadmin@euroconex.com 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message