tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Jacoby" <>
Subject RE: Security Hole - server.xml
Date Wed, 26 Nov 2003 17:10:06 GMT
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. :)


>>> 11/26/03 08:09AM >>>
> From: Curley, Thomas []

> 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

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


> thanks
> Thomas
> -----Original Message-----
> From: Tim Funk []
> 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:
> For additional commands, e-mail:
> **************************************************************
> *******************************
> 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 
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message