Kevin:
That works for remote user accounts logging into tomcat webapps, but
does not work for database pools, etc., ... where tomcat the service has
to perform a login to gain access to protected resources.
Marcus:
If the admins who are making noise ever really thought about the
problem, they would know better. You could hash the passwords, but then
there would have to be some code somewhere to unhash them with
potentially yet another password to unhash that. And if you don't
unhash the password before using it to access the resource, it's the
same as a clear text password. You really never get away from having a
password of some form sitting around somewhere.
Besides, have you ever asked them how they handle the private key for
their SSL certificate? That has to sit on the server in the clear.
It's certainly not encoded in any way that would stop a hacker and I
would argue it's more important to keep that safe than the password your
webapp uses to access protected resources.
Regarding malicious superuser, if they let an untrusted party gain that
level of access on their server they have *MUCH* bigger problems than
your tomcat service.
Tomcat should only be using accounts with minimum access rights anyway
(as we all should if you really want to get down to best practice). And
if the resource is of a sensitive nature, it should be behind a firewall
limiting availability to the outside world.
--David
Kevin Williams wrote:
How about hashing the passwords with a known forumla and storing them
in this intermediate format. App would need to hash the user input
and compare. This might give ur security czars a warmer feeling and
get them off ur back.
-Kevin
On 5/13/08, Milanez, Marcus <[EMAIL PROTECTED]> wrote:
Filip thanks for your reply,
1. make sure tomcat runs as an account that can't login
Right, that is done
2. make any file that contains secure information readonly, and readable
only by the tomcat user
Done too
if someone gets onto your machine as an super user, you have bigger
problem than the password being in clear text
That is the answer everyone gives in tomcat forums all over the internet, so
it seems to me that no possible solution is available. On the other hand, is
it right to stay behind a possible security fault (malicious super user
performing login) in order to say I'll not correct known security issues in
my application? The thing is I'm not responsible for the servers but the
ones who are, keep arguing that this is a crictical security problem. Are
they seeing a big problem in a small one?
Thanks a lot!
Marcus
-----Mensagem original-----
De: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Enviada em: terça-feira, 13 de maio de 2008 12:37
Para: Tomcat Users List
Assunto: Re: Once again, clear text passwords in context.xml files
it's a wasted effort, the one way it could be truly secure, was if tomcat
asked you for a key upon startup. this wouldn't work very well in a 1000
tomcat instance server farm.
any other effort simply masks the problem, letting you think it is secure,
when it isn't.
what you should do is this
1. make sure tomcat runs as an account that can't login 2. make any file
that contains secure information readonly, and readable only by the tomcat
user
if someone gets onto your machine as an super user, you have bigger problem
than the password being in clear text
Filip
Milanez, Marcus wrote:
Hello everyove,
We were asked to eliminate clear text passwords associated to database
pooled connections in context.xml files... I know it has been
discussed a lot, but I would like to ask once again whether someone
has a simple, clean solution for that. We are using Windows server and MS
SQL 2005.
One of the options I came across is to use Windows Integratd
authentication instead of database users. Is there any other ideas to
overcome this situation?
Thanks a lot,
Marcus Milanez
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
