tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parsons Technical Services" <parsonstechni...@earthlink.net>
Subject Re: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
Date Sun, 27 Feb 2005 15:23:54 GMT
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" <ebegoli@gmail.com>
To: "Tomcat Users List" <tomcat-user@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" <ebegoli@gmail.com>
>> To: "Tomcat Users List" <tomcat-user@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


Mime
View raw message