You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kelly J Flowers <fl...@dteenergy.com> on 2007/04/30 22:31:52 UTC

Encrypting passwords in the connection pool setup

I'm using Tomcat 5.5 to run a web application.  I have the connection pools
set up and working in the context.xml but the password is in plain text.
Does anyone know of a way to encrypt the password and username to the
database?

Re: Encrypting passwords in the connection pool setup

Posted by David Smith <dn...@cornell.edu>.
Just to add to this discussion ...

First, let me say I don't think encrypting the password would in any way 
add significantly to tomcat's security or the security of the database.  
What I'm offering is just a possibility from a purely academic 
standpoint.  Two solutions that can be taken separately or together:

1. Public key encrypt the db password:

Generate a public key/private key pair like a self-signed cert.  Encrypt 
your db password with the public key and secure the private key the way 
you would for running SSL/TLS.  Then a modified version of your favorite 
database pooling software would have to accept a new property like 
sslPassword="..."  Easy enough just by extending the DataSource 
implementation and adding a setter for the new property.  The setter 
decrypts the password using the SSL private key.  You could even hand 
the encrypted password to your developers without them being able to 
gain access unless they get a hold of the server's private key.

2. Put the password in a separate file:

Exend the DataSource implementation in your favorite db pooling package 
to have a passwordFile attribute.  Developers are only given the path to 
the password file and do not have direct access (read/write/any) to the 
file.  It's owned by the tomcat process and read only by that user 
similar to an SSL private key.  On the plus side, there's no 
distribution.  Sys admins can change the db password at any time and 
without notice except to let everyone know when the server's being 
restarted.

Again, just offering it for the ambitious and the paranoid.  I make no 
offers to write code for either of these ideas.

--David

Darren wrote:
>> Why wouldn't we at least store the MD5 hash of the passwords
>> instead of the password in clear text, or use a scheme similar to the
>> Unix /etc/passwd file?
>
> You've not thought this through.  Tomcat needs to decrypt or somehow 
> have the credentials in cleartext so it can pass them to the database 
> to establish a connection (MD5 is one way).  If it were possible to 
> create the connection with an encrypted password, it would be just as 
> sensitive as the unencrypted version.
>
>
>>> Also,  The encryption doesn't have to be full proof, it just needs 
>>> to be a deterrent.  For the most part it is the people with shell 
>>> access that I want to remove the ability to read the passwords 
>>> from.  Sometimes security through obscurity is enough.
>
> How would this work?  Something like
>
> <Resource name="jdbc/db" auth="Container" type="javax.sql.DataSource"
>               driverClassName="com.mysql.jdbc.Driver"
>               username="user" obfuscated="true" password="sh7dhkaDaS"
>               
> url="jdbc:mysql://localhost:3306/appraisal?autoReconnect=true" />
>
> If so, how do you propose to generate the obfuscated password?  Maybe 
> a utility app that ships with the tomcat distribution?  If so a 
> de-obfuscater would appear somewhere on the internet in a very short 
> space of time.
>
> Don't get me wrong, I'd like to see something done which could improve 
> on the current cleartext situation, but I can't think of a sensible 
> solution that would warrant a developers time.
>
> Darren
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Encrypting passwords in the connection pool setup

Posted by "Raghupathy, Gurumoorthy" <Gu...@nielsen.com>.
Hi,
	If you want to do something like that you can then extend 

	"org.apache.commons.dbcp.BasicDataSourceFactory" to
encrypt/decrypt 
	the password...   


	And put it in a package jar and put it in common lib and setup
the 
	datasource as described in JNDI datasource ..... 

	Not an easy solution but can be achieved :) 


Regards
Guru 	

-----Original Message-----
From: Darren [mailto:darrenslists@googlemail.com] 
Sent: 01 May 2007 16:10
To: Tomcat Users List
Subject: Re: Encrypting passwords in the connection pool setup

> Why wouldn't we at least store the MD5 hash of the passwords
> instead of the password in clear text, or use a scheme similar to the
> Unix /etc/passwd file?

You've not thought this through.  Tomcat needs to decrypt or somehow  
have the credentials in cleartext so it can pass them to the database  
to establish a connection (MD5 is one way).  If it were possible to  
create the connection with an encrypted password, it would be just as  
sensitive as the unencrypted version.


>> Also,  The encryption doesn't have to be full proof, it just needs  
>> to be a deterrent.  For the most part it is the people with shell  
>> access that I want to remove the ability to read the passwords  
>> from.  Sometimes security through obscurity is enough.

How would this work?  Something like

<Resource name="jdbc/db" auth="Container" type="javax.sql.DataSource"
               driverClassName="com.mysql.jdbc.Driver"
               username="user" obfuscated="true" password="sh7dhkaDaS"
               url="jdbc:mysql://localhost:3306/appraisal? 
autoReconnect=true" />

If so, how do you propose to generate the obfuscated password?  Maybe  
a utility app that ships with the tomcat distribution?  If so a de- 
obfuscater would appear somewhere on the internet in a very short  
space of time.

Don't get me wrong, I'd like to see something done which could  
improve on the current cleartext situation, but I can't think of a  
sensible solution that would warrant a developers time.

Darren


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Darren <da...@googlemail.com>.
> Why wouldn't we at least store the MD5 hash of the passwords
> instead of the password in clear text, or use a scheme similar to the
> Unix /etc/passwd file?

You've not thought this through.  Tomcat needs to decrypt or somehow  
have the credentials in cleartext so it can pass them to the database  
to establish a connection (MD5 is one way).  If it were possible to  
create the connection with an encrypted password, it would be just as  
sensitive as the unencrypted version.


>> Also,  The encryption doesn't have to be full proof, it just needs  
>> to be a deterrent.  For the most part it is the people with shell  
>> access that I want to remove the ability to read the passwords  
>> from.  Sometimes security through obscurity is enough.

How would this work?  Something like

<Resource name="jdbc/db" auth="Container" type="javax.sql.DataSource"
               driverClassName="com.mysql.jdbc.Driver"
               username="user" obfuscated="true" password="sh7dhkaDaS"
               url="jdbc:mysql://localhost:3306/appraisal? 
autoReconnect=true" />

If so, how do you propose to generate the obfuscated password?  Maybe  
a utility app that ships with the tomcat distribution?  If so a de- 
obfuscater would appear somewhere on the internet in a very short  
space of time.

Don't get me wrong, I'd like to see something done which could  
improve on the current cleartext situation, but I can't think of a  
sensible solution that would warrant a developers time.

Darren


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by David Wall <d....@computer.org>.
Martin,

All encryption systems need a way to boot themselves.  This either means 
you store the password somewhere so the program can self-boot itself, or 
you need user intervention, such as typing in the password (or inserting 
a dongle or other security hardware device).

Once the system has booted itself, then it can store things safely using 
encryption.  A hash value is simply a transformation of one string into 
another, so if the program that retrieves the password retrieves the 
real password or its hash, there is no added security, the hash has 
simply become the password (after all, you cannot go from the hash to 
the password value, at least not easily with a good hash, as that's it's 
main reason for being).

Hashed passwords are very useful if you have others who will be entering 
the password in, since you can then store only hashes, and when you need 
to verify the password entered, you create a hash of the entered 
password and then compare it to the stored hashed value.

This isn't the case for applications that need to bootstrap themselves.  
You really either need to require manual intervention to start it (and 
enter the password), or it will be stored in the clear somewhere.

David


Martin Dubuc wrote:
> Chris,
>
> I am not sure I buy your argument that because there is somewhere else
> in an implementation that is as insecure as cleartext password, then
> there is no point in fixing the cleartext password issue. With this
> argument, we would never care about fixing any security holes, because
> one can always find a new security hole to exploit. Plus, well, the
> assumption that someone is using a password-less key with Apache
> running with SSL is pretty weak, because there are ways to avoid using
> password-less key.
>
> As far as the UNIX password analogy, tomcat may be seen as a user, not
> UNIX, but it still performs authentication. So in my mind, it is
> filling in for both roles (UNIX and user). I have the impression that
> using MD5/SHA hashing would be a good option, because it would be
> simple, would not require any additional key, would provide some sense
> of security. Not the silverlining, but better than cleartext, for
> sure.
>
> Martin
>
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin,

Martin Dubuc wrote:
> I am not sure I buy your argument that because there is somewhere
> else in an implementation that is as insecure as cleartext password,
> then there is no point in fixing the cleartext password issue. With
> this argument, we would never care about fixing any security holes,
> because one can always find a new security hole to exploit.

Of course I could never say that security measures are never useful.
What I'm saying is that /this/ one isn't (useful).

Writing your password on your monitor is a bad idea. Writing it on a
sheet of paper in your desk is slightly better, but remembering it is
the best solution. I'm asking you to consider looking for the best
solution instead of the deployment equivalent of putting your password
in your desk drawer.

> Plus, well, the assumption that someone is using a password-less key
> with Apache running with SSL is pretty weak, because there are ways
> to avoid using password-less key.

Right. You can either enter the password on startup (a maintenance
headache) or you can put the key somewhere (plaintext, I might add).

> As far as the UNIX password analogy, tomcat may be seen as a user,
> not UNIX, but it still performs authentication.

No, it doesn't. Tomcat is a user of the database. It is never performing
database authentication. Tomcat may be performing /user/ authentication,
but that unrelated.

> I have the impression that using MD5/SHA hashing would be a good
> option, because it would be simple, would not require any additional
> key, would provide some sense of security.

Note that hashing the password is the same as using a plaintext
password. I'll leave the reason for this as an exercise for the reader.

My belief is that this gives the illusion of security. Bruce Schneier
calls this "security theater" because you are essentially making a
symbolic yet meaningless gesture towards security.

Please don't hear me saying that what you are proposing is a bad idea,
or that security isn't worth it. I'm merely suggesting that there are
better ideas than the one you are proposing.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGN3bs9CaO5/Lv0PARAnqYAJ9BCqofhNRgLUcCO8z/ei8momv45wCfahQI
J+EbhfxBN+FpWkiqZIRR8rw=
=bFGf
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Martin Dubuc <ma...@gmail.com>.
Chris,

I am not sure I buy your argument that because there is somewhere else
in an implementation that is as insecure as cleartext password, then
there is no point in fixing the cleartext password issue. With this
argument, we would never care about fixing any security holes, because
one can always find a new security hole to exploit. Plus, well, the
assumption that someone is using a password-less key with Apache
running with SSL is pretty weak, because there are ways to avoid using
password-less key.

As far as the UNIX password analogy, tomcat may be seen as a user, not
UNIX, but it still performs authentication. So in my mind, it is
filling in for both roles (UNIX and user). I have the impression that
using MD5/SHA hashing would be a good option, because it would be
simple, would not require any additional key, would provide some sense
of security. Not the silverlining, but better than cleartext, for
sure.

Martin

On 5/1/07, Christopher Schultz <ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin,
>
> Martin Dubuc wrote:
> > But it strikes me that Tomcat
> > is the only application I know where passwords are stored in clear
> > text.
>
> I'll bet that Tomcat is the only application that needs to know its own
> passwords. Do you have Apache running with SSL? Where do you store the
> password for the SSL key? I'll bet that you have a password-less key,
> which is just about the same as a cleartext password lying around.
>
> > Why wouldn't we at least store the MD5 hash of the passwords
> > instead of the password in clear text, or use a scheme similar to the
> > Unix /etc/passwd file?
>
> Because UNIX password files are used to authenticate a user typing their
> password. In this analogy, Tomcat isn't UNIX, Tomcat is /the user/.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGN2H+9CaO5/Lv0PARAqqrAKDAc7F2rge4Xl0UaND7rhGicN3DYQCdEi4V
> c9p5LvXt+HudZAMm/98Y3b4=
> =FqMz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin,

Martin Dubuc wrote:
> But it strikes me that Tomcat
> is the only application I know where passwords are stored in clear
> text.

I'll bet that Tomcat is the only application that needs to know its own
passwords. Do you have Apache running with SSL? Where do you store the
password for the SSL key? I'll bet that you have a password-less key,
which is just about the same as a cleartext password lying around.

> Why wouldn't we at least store the MD5 hash of the passwords
> instead of the password in clear text, or use a scheme similar to the
> Unix /etc/passwd file?

Because UNIX password files are used to authenticate a user typing their
password. In this analogy, Tomcat isn't UNIX, Tomcat is /the user/.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGN2H+9CaO5/Lv0PARAqqrAKDAc7F2rge4Xl0UaND7rhGicN3DYQCdEi4V
c9p5LvXt+HudZAMm/98Y3b4=
=FqMz
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Martin Dubuc <ma...@gmail.com>.
Mark,

I also don't feel quite at ease to see passwords in clear text in the
server.xml file. True, if the protection on that file is set up
properly, there shouldn't be much issue. But it strikes me that Tomcat
is the only application I know where passwords are stored in clear
text. Why wouldn't we at least store the MD5 hash of the passwords
instead of the password in clear text, or use a scheme similar to the
Unix /etc/passwd file? I do agree with Richard that there is more to
it than protecting from hackers. Enforcing the responsabilities
between different roles is also very important.

Martin

On 5/1/07, Richard DeGrande <RD...@co.jefferson.co.us> wrote:
> Mark,
>
> The ability to store encrypted passwords doesn't necessarily have to be used to protect the system from hackers.  This would be a GREAT feature to enforce the responsibilities between different roles in a development environment.  Also,  The encryption doesn't have to be full proof, it just needs to be a deterrent.  For the most part it is the people with shell access that I want to remove the ability to read the passwords from.  Sometimes security through obscurity is enough.
>
> >>> Mark Thomas <ma...@apache.org> 4/30/2007 5:30 PM >>>
> Kelly J Flowers wrote:
> > I'm using Tomcat 5.5 to run a web application.  I have the connection pools
> > set up and working in the context.xml but the password is in plain text.
> > Does anyone know of a way to encrypt the password and username to the
> > database?
>
> This is nearly always pointless. A couple of points to consider:
> 1. If the password is encrypted, where do you store the decryption key?
> 2. If an attacker can read the context.xml file they probably have
> shell access to your box. In this case you have bigger problems.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard,

Richard DeGrande wrote:
> The ability to store encrypted passwords doesn't necessarily have to
> be used to protect the system from hackers.  This would be a GREAT
> feature to enforce the responsibilities between different roles in a
> development environment.

I solve this problem by using a replaceable set of credentials in the
context.xml file (where I set up my connection pool). When I deploy
using ant, the values are pulled-in from ~/.ant.properties which can be
set per user. In production, the installing user has their own set of
credentials. The creds are left out of revision tracking, so "mere"
developers never know the production creds.

> Also,  The encryption doesn't have to be
> full proof, it just needs to be a deterrent.

The point is that encryption such as this only protects against
accidental disclosure of a password. The password must be decrypted
using a key which is in plain text, so there's no effective security.

> For the most part it is
> the people with shell access that I want to remove the ability to
> read the passwords from.

Then make your files readable only by the user under which Tomcat is run.

> Sometimes security through obscurity is enough.

No. Security through obscurity only protects against accidental
disclosure among friendly users. There are better ways to achieve this
goal (such as using file permissions).

The bottom line is that I don't know of any connection pool that
supports encrypted passwords in the configuration, so this discussion is
entirely academic.

- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGN2GB9CaO5/Lv0PARAkh7AJ4y+XtFehqMEPsH2N5gxU8pORFxNACcCKni
5gAw3sITPMr0lFhzGwSDHQQ=
=C5m4
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Richard DeGrande <RD...@co.jefferson.co.us>.
Mark,

The ability to store encrypted passwords doesn't necessarily have to be used to protect the system from hackers.  This would be a GREAT feature to enforce the responsibilities between different roles in a development environment.  Also,  The encryption doesn't have to be full proof, it just needs to be a deterrent.  For the most part it is the people with shell access that I want to remove the ability to read the passwords from.  Sometimes security through obscurity is enough.  

>>> Mark Thomas <ma...@apache.org> 4/30/2007 5:30 PM >>>
Kelly J Flowers wrote:
> I'm using Tomcat 5.5 to run a web application.  I have the connection pools
> set up and working in the context.xml but the password is in plain text.
> Does anyone know of a way to encrypt the password and username to the
> database?

This is nearly always pointless. A couple of points to consider:
1. If the password is encrypted, where do you store the decryption key?
2. If an attacker can read the context.xml file they probably have
shell access to your box. In this case you have bigger problems.

Mark



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org 
For additional commands, e-mail: users-help@tomcat.apache.org 



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Len Popp <le...@gmail.com>.
Mark, I've heard that argument before, and it has never made sense to
me. If an attacker has read access to one box, that box had better not
have passwords for all the other servers in plain text files!

Security isn't all-or-nothing. There are levels of security, and you
want to get as much security as you reasonably can. Encrypting
passwords or hiding them in compiled code certainly raises the bar for
someone trying to access something they shouldn't - instead of just
reading the password, they'd have to hack the program or break the
encryption. Most people don't have the skill to do that. Not all
security breaches are caused by genius hackers who know every security
hole in every OS. You also have to consider people such as the company
insider who searches the network for credit card records he can sell.

To put it another way, why do you bother locking the front door of
your house? It's completely insecure compared to a bank vault, so why
worry about security at all?
-- 
Len

On 4/30/07, Mark Thomas <ma...@apache.org> wrote:
> Kelly J Flowers wrote:
> > I'm using Tomcat 5.5 to run a web application.  I have the connection pools
> > set up and working in the context.xml but the password is in plain text.
> > Does anyone know of a way to encrypt the password and username to the
> > database?
>
> This is nearly always pointless. A couple of points to consider:
> 1. If the password is encrypted, where do you store the decryption key?
> 2. If an attacker can read the context.xml file they probably have
> shell access to your box. In this case you have bigger problems.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Mark Thomas <ma...@apache.org>.
Kelly J Flowers wrote:
> I'm using Tomcat 5.5 to run a web application.  I have the connection pools
> set up and working in the context.xml but the password is in plain text.
> Does anyone know of a way to encrypt the password and username to the
> database?

This is nearly always pointless. A couple of points to consider:
1. If the password is encrypted, where do you store the decryption key?
2. If an attacker can read the context.xml file they probably have
shell access to your box. In this case you have bigger problems.

Mark



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Encrypting passwords in the connection pool setup

Posted by Darren <da...@googlemail.com>.
I commented on this in the following article - http://www.owasp.org/ 
index.php/Securing_tomcat#Cleartext_Passwords_in_CATALINA_HOME.2Fconf. 
2Fserver.xml

In short, no.

There was also some further discussion on one of the OWASP list  
recently - https://lists.owasp.org/pipermail/java-project/2007-April/ 
000150.html


On 30 Apr 2007, at 21:31, Kelly J Flowers wrote:

> I'm using Tomcat 5.5 to run a web application.  I have the  
> connection pools
> set up and working in the context.xml but the password is in plain  
> text.
> Does anyone know of a way to encrypt the password and username to the
> database?


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org