You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Edmon Begoli <eb...@gmail.com> on 2005/02/27 04:08:30 UTC
Question for Tomcat Developers - How to Plug In Encryption for JDBC
passwords
Hi,
I an using Tomcat 5.5.7, and I am planning on upgrading as needed.
As we all know Tomcat enables me to configure JDBC resources
that my app can use through the JNDI. My problem is that these passwords
have to be stored as a plain text
which is a very bitter pill in my environment.
What is the Tomcat class that reads in those plain text values?
I would like to override this behavior and to enable this class to read
digests/encrypted passwords.
I would also contribute this code to Tomcat code base if desired.
Please advise,
Edmon
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Question for Tomcat Developers - How to Plug In Encryption for
JDBC passwords
Posted by Shankar Unni <sh...@netscape.net>.
George Sexton wrote:
> If you really want to do this, then you will need to have your application
> startup have a method that permits an operator to enter in the password for
> the JDBC information at startup.
Whatever - the key is to be able to insert an application-defined
processing step between the reading of the DBCP properties, and sending
the username and password to the JDBC driver.
This additional step could be:
* nothing (cleartext username and password)
* trivial decryption of a trivially encrypted string (not
cryptographically safe, but Dilbert's-boss-safe).
* True encrypted strings that require a password-protected opening of a
private-key file to decrypt.
* True password-protected external storage of encrypted data.
Whatever. The key is to be able to do a two-way processing of the
username, password, and other sensitive data (even the JDBC url). A tool
to "encode" the data into the JDBC properties, and a code callback to
"decode" the properties when reading them from the file.
How easy is this to do? Where would such a hook go?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
Posted by Parsons Technical Services <pa...@earthlink.net>.
I won't argue any of these points. They are all valid. Often the request for
encryption comes from individuals who want to lock there goods in a safe but
leave the safe in the back of a truck with the keys in the ignition. In your
case you want to hide the keys and disable the truck.
Since time is the goal here and not ultimate security, then playing an
encryption game would help. Also think of moving the username and passwords
into separate files located in different locations. As for the encryption,
you could do it twice. Once when the xml is parsed and read in and again
when the database is being contacted.
Now the real issue is that since time is your real goal, the last thing you
want to do is contribute the code back to the project. This would give the
hacker a road map where everything is and with a simple script, in less than
a second, he or she would have your info.
Also consider encrypting the username. Why give them half of your
information.
I have read the code for the call to the database and there are a couple
ways to do it there. As for the other end during the file read, I haven't
mess with that end yet.
Again secrecy is you ally here. Yes, it would make your install custom, but
that would be a good thing in your case. Why do you think M$ gets hacked so
much?
Doug
----- Original Message -----
From: "Edmon Begoli" <eb...@gmail.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Sunday, February 27, 2005 3:14 AM
Subject: Re: Question for Tomcat Developers - How to Plug In Encryption for
JDBC passwords
>
> Please do not start the flame war. Check what I have to say. I am really
> not a beginner in this area.
>
> First, feature I mentioned is commonly implemented on every major
> application server platform that I know- JBoss, WebSphere, WebLogic,
> Oracle AS.
> It's purpose is not to permanently protect the credentials, but to
> minimize or prevent the damage
> from a short duration attack - i.e. to minimize chances of a breach into a
> data tier.
> I am quite aware of all the other best security engineering practices, but
> in this case
> I am really addressing one pretty significant scenario - a short duration
> attack where the application server host machine
> has been completely compromised by an external or lateral attack.
>
> You attacked and fully breached the machine that is hosting Tomcat, and as
> you've done so you have triggered various trip wires. So you have
> only few minutes before the attack is confirmed.
>
> If the Tomcat password is in clear, you just need to connect to the
> database using the connection string provided and you can start pulling
> the data out.
> For the person skilled in the target database 5 min would be more then
> enough for all kinds of catastrophically damaging activities -
> primarely finding and reading the sensitive data. It is commonly
> recognized in the security circles that the application server's JDBC
> rights are
> achilles heel of the application. With clear passwords - there is nothing
> in your way.
>
> If you have 5 min on the Tomcat that has a connection password encrypted -
> you have to spend time to decrypt it - no matter how trivial that task may
> be, or how
> well known the algorithm may be. In a sophisticated, secured environment
> this time required to break even the most simplistic encryption algorithm
> can be sufficient
> enough for the intrusion detection and prevention mechanims to kick in and
> stop the show before any of the data has been read, exported or
> transported.
>
> Of all the elements in the distributed systems with relational backends -
> the most senstive part of it is a relational backend itself. Not a web
> server, root account,
> not a shadow files, but the database itself because if somebody gets hold
> of even one social security number, mother's maiden name, medical record,
> salary, ...
> the targeted business (and the people who implemented the application) may
> need to put a "Closout Sale" sign on their shop soon.
>
>
> Sample of JDBC configuration entry in BEA WebLogic 9
>
> | <jdbc-driver-params>
> <url>jdbc:pointbase:server://123.123.123.123:9092/demo</url>
> <driver-name>com.pointbase.xa.xaDataSource</driver-name>
> <properties>
> <property>
> <name>user</name>
> <value>examples</value>
> </property>
> <property>
> <name>databaseName</name>
> <value>jdbc:pointbase:server://123.123.123.123:9092/demo</value>
> </property>
> </properties>
> <password-encrypted>eNEVN9dk4dEDUEVqL1</password-encrypted>
> </jdbc-driver-params>|
>
>
>
>
>
> Parsons Technical Services wrote:
>
>> Okay, I know I am starting a flame war but why go through the effort?
>>
>> If I can see your encrypted passwords, then I can see the code that
>> decrypts them. And with that I have your passwords. It only adds a step
>> to my effort to crack your security.
>>
>> The only way to really secure them is to secure the files they are stored
>> in. If you are on Linux or Windoze with NTFS this can be done. Then only
>> you and Tomcat can see them. This of course does not exclude the
>> admin/root, but if you can't trust them then you have bigger issues.
>>
>> So in reality don't bother with what is in the files, instead secure the
>> files.
>>
>> If you disagree, then explain how you are going to send the password to
>> MySQL? And some more info on your environment may help us give you some
>> other suggestions.
>>
>> Please don't take this the wrong way. This has been discussed many times
>> before and there is no real solution other than as stated above. If you
>> have a different idea, please post it. We are open to new ideas and
>> suggestions, but with this one, I feel the solution lies in the
>> environment. Please feel free to prove me wrong. And yes it has been done
>> before, for I am far from perfect.
>>
>> Doug
>>
>> ----- Original Message ----- From: "Edmon Begoli" <eb...@gmail.com>
>> To: "Tomcat Users List" <to...@jakarta.apache.org>
>> Sent: Saturday, February 26, 2005 10:08 PM
>> Subject: Question for Tomcat Developers - How to Plug In Encryption for
>> JDBC passwords
>>
>>
>>> Hi,
>>>
>>> I an using Tomcat 5.5.7, and I am planning on upgrading as needed.
>>>
>>> As we all know Tomcat enables me to configure JDBC resources
>>> that my app can use through the JNDI. My problem is that these passwords
>>> have to be stored as a plain text
>>> which is a very bitter pill in my environment.
>>>
>>> What is the Tomcat class that reads in those plain text values?
>>>
>>> I would like to override this behavior and to enable this class to read
>>> digests/encrypted passwords.
>>> I would also contribute this code to Tomcat code base if desired.
>>>
>>> Please advise,
>>> Edmon
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
RE: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
Posted by George Sexton <gs...@mhsoftware.com>.
Your argument about short duration attacks is optimistic at best. Most
systems are so poorly secured and monitored, that breakins aren't detected
anywhere near that quickly.
Let's face reality here. The only safe way to hide the JDBC information is
to have the SECRET (encryption password) not available on the server. Any
other method is not secure, it is just obfuscation. The tomcat developers
quite rightly are refusing to implement any kind of scheme that isn't
correct.
Look at the startup sequence for Apache using SSL certificates. You have to
type in the password for the private key.
If you really want to do this, then you will need to have your application
startup have a method that permits an operator to enter in the password for
the JDBC information at startup. This means that every time your application
is re-started, an operator will have to re-enter the information before the
application can run.
I'd really suggest you purchase and read Bruce Schneir's book Applied
Cryptography. Plan on spending a several evenings with it.
Just for grins, here's a link to a Javadoc for a crypto system that I
designed for a shopping cart. The overriding design goal was to ensure that
credit card data would not be revealed even if the database were
compromised. I don't see any shortcomings in it, but I haven't opened it up
to public review before.
http://www.mhsoftware.com/~gsexton/Crypto.html
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
> -----Original Message-----
> From: Edmon Begoli [mailto:ebegoli@gmail.com]
> Sent: Sunday, February 27, 2005 1:15 AM
> To: Tomcat Users List
> Subject: Re: Question for Tomcat Developers - How to Plug In
> Encryption for JDBC passwords
>
>
> Please do not start the flame war. Check what I have to say.
> I am really
> not a beginner in this area.
>
> First, feature I mentioned is commonly implemented on every major
> application server platform that I know- JBoss, WebSphere, WebLogic,
> Oracle AS.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Question for Tomcat Developers - How to Plug In Encryption for
JDBC passwords
Posted by Edmon Begoli <eb...@gmail.com>.
Please do not start the flame war. Check what I have to say. I am really
not a beginner in this area.
First, feature I mentioned is commonly implemented on every major
application server platform that I know- JBoss, WebSphere, WebLogic,
Oracle AS.
It's purpose is not to permanently protect the credentials, but to
minimize or prevent the damage
from a short duration attack - i.e. to minimize chances of a breach into
a data tier.
I am quite aware of all the other best security engineering practices,
but in this case
I am really addressing one pretty significant scenario - a short
duration attack where the application server host machine
has been completely compromised by an external or lateral attack.
You attacked and fully breached the machine that is hosting Tomcat, and
as you've done so you have triggered various trip wires. So you have
only few minutes before the attack is confirmed.
If the Tomcat password is in clear, you just need to connect to the
database using the connection string provided and you can start pulling
the data out.
For the person skilled in the target database 5 min would be more then
enough for all kinds of catastrophically damaging activities -
primarely finding and reading the sensitive data. It is commonly
recognized in the security circles that the application server's JDBC
rights are
achilles heel of the application. With clear passwords - there is
nothing in your way.
If you have 5 min on the Tomcat that has a connection password encrypted
- you have to spend time to decrypt it - no matter how trivial that task
may be, or how
well known the algorithm may be. In a sophisticated, secured environment
this time required to break even the most simplistic encryption
algorithm can be sufficient
enough for the intrusion detection and prevention mechanims to kick in
and stop the show before any of the data has been read, exported or
transported.
Of all the elements in the distributed systems with relational backends
- the most senstive part of it is a relational backend itself. Not a web
server, root account,
not a shadow files, but the database itself because if somebody gets
hold of even one social security number, mother's maiden name, medical
record, salary, ...
the targeted business (and the people who implemented the application)
may need to put a "Closout Sale" sign on their shop soon.
Sample of JDBC configuration entry in BEA WebLogic 9
| <jdbc-driver-params>
<url>jdbc:pointbase:server://123.123.123.123:9092/demo</url>
<driver-name>com.pointbase.xa.xaDataSource</driver-name>
<properties>
<property>
<name>user</name>
<value>examples</value>
</property>
<property>
<name>databaseName</name>
<value>jdbc:pointbase:server://123.123.123.123:9092/demo</value>
</property>
</properties>
<password-encrypted>eNEVN9dk4dEDUEVqL1</password-encrypted>
</jdbc-driver-params>|
Parsons Technical Services wrote:
> Okay, I know I am starting a flame war but why go through the effort?
>
> If I can see your encrypted passwords, then I can see the code that
> decrypts them. And with that I have your passwords. It only adds a
> step to my effort to crack your security.
>
> The only way to really secure them is to secure the files they are
> stored in. If you are on Linux or Windoze with NTFS this can be done.
> Then only you and Tomcat can see them. This of course does not exclude
> the admin/root, but if you can't trust them then you have bigger issues.
>
> So in reality don't bother with what is in the files, instead secure
> the files.
>
> If you disagree, then explain how you are going to send the password
> to MySQL? And some more info on your environment may help us give you
> some other suggestions.
>
> Please don't take this the wrong way. This has been discussed many
> times before and there is no real solution other than as stated above.
> If you have a different idea, please post it. We are open to new ideas
> and suggestions, but with this one, I feel the solution lies in the
> environment. Please feel free to prove me wrong. And yes it has been
> done before, for I am far from perfect.
>
> Doug
>
> ----- Original Message ----- From: "Edmon Begoli" <eb...@gmail.com>
> To: "Tomcat Users List" <to...@jakarta.apache.org>
> Sent: Saturday, February 26, 2005 10:08 PM
> Subject: Question for Tomcat Developers - How to Plug In Encryption
> for JDBC passwords
>
>
>> Hi,
>>
>> I an using Tomcat 5.5.7, and I am planning on upgrading as needed.
>>
>> As we all know Tomcat enables me to configure JDBC resources
>> that my app can use through the JNDI. My problem is that these
>> passwords have to be stored as a plain text
>> which is a very bitter pill in my environment.
>>
>> What is the Tomcat class that reads in those plain text values?
>>
>> I would like to override this behavior and to enable this class to
>> read digests/encrypted passwords.
>> I would also contribute this code to Tomcat code base if desired.
>>
>> Please advise,
>> Edmon
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
Posted by Parsons Technical Services <pa...@earthlink.net>.
Okay, I know I am starting a flame war but why go through the effort?
If I can see your encrypted passwords, then I can see the code that decrypts
them. And with that I have your passwords. It only adds a step to my effort
to crack your security.
The only way to really secure them is to secure the files they are stored
in. If you are on Linux or Windoze with NTFS this can be done. Then only you
and Tomcat can see them. This of course does not exclude the admin/root, but
if you can't trust them then you have bigger issues.
So in reality don't bother with what is in the files, instead secure the
files.
If you disagree, then explain how you are going to send the password to
MySQL? And some more info on your environment may help us give you some
other suggestions.
Please don't take this the wrong way. This has been discussed many times
before and there is no real solution other than as stated above. If you have
a different idea, please post it. We are open to new ideas and suggestions,
but with this one, I feel the solution lies in the environment. Please feel
free to prove me wrong. And yes it has been done before, for I am far from
perfect.
Doug
----- Original Message -----
From: "Edmon Begoli" <eb...@gmail.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Saturday, February 26, 2005 10:08 PM
Subject: Question for Tomcat Developers - How to Plug In Encryption for JDBC
passwords
> Hi,
>
> I an using Tomcat 5.5.7, and I am planning on upgrading as needed.
>
> As we all know Tomcat enables me to configure JDBC resources
> that my app can use through the JNDI. My problem is that these passwords
> have to be stored as a plain text
> which is a very bitter pill in my environment.
>
> What is the Tomcat class that reads in those plain text values?
>
> I would like to override this behavior and to enable this class to read
> digests/encrypted passwords.
> I would also contribute this code to Tomcat code base if desired.
>
> Please advise,
> Edmon
>
> ---------------------------------------------------------------------
> 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
RE: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
Posted by "Richard Mixon (qwest)" <rn...@qwest.net>.
Edmon,
I am not sure if I understand, but perhaps you should tak a look at Matt
Raible's Appfuse application framework at: https://appfuse.dev.java.net/
His solution uses:
- SSL (optional of course, just a servlet parameter);
- Container Managed Authentication;
- a custom login servlet that encrypts the passwords (SHA is the
default, but algorithm can vary);
- username and password stored in a database (the password is encrypted
using SHA).
The only exposure of the passwords might be in your web server "access"
logs. If that too is a concern, you could also take a look at trying to
do SHA encryption of the password on the client web browser using
Javascript - not sure if that's feasible or not. The login servlet would
then need to be adjusted appropriately (i.e. it would not need to do the
SHA encryption).
HTH - Richard
Edmon Begoli wrote:
> Hi,
>
> I an using Tomcat 5.5.7, and I am planning on upgrading as needed.
>
> As we all know Tomcat enables me to configure JDBC resources
> that my app can use through the JNDI. My problem is that these
> passwords have to be stored as a plain text
> which is a very bitter pill in my environment.
>
> What is the Tomcat class that reads in those plain text values?
>
> I would like to override this behavior and to enable this class to
> read digests/encrypted passwords.
> I would also contribute this code to Tomcat code base if desired.
>
> Please advise,
> Edmon
>
> ---------------------------------------------------------------------
> 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