|
»
»
»
« Return to Thread: Clustering Tomcat - StandardManager loaded instead of DeltaManager
Re: Once again, clear text passwords in context.xml files
by David Smith-2
::
Rate this Message:
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 <Marcus.Milanez@...> 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:devlists@...]
>> 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@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
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 <Marcus.Milanez@...> 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:devlists@...]
>> 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@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: Clustering Tomcat - StandardManager loaded instead of DeltaManager
| Free Forum Powered by Nabble | Forum Help |