RE: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
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. Is that strictly true? If you use the method that is used to encrypt Unix passwords (google for JCrypt for an implementation) then isn't this a one-way hash and you can't decrypt the passwords by reversing the algorithmn? Regards Roger __ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
Tomcat must send the unencrypted password to the database. Thus it must decrypt it. The whole issue is that Tomcat must act like a user in the role of the database. So it must know the password. The best method is to lock the user away in a room, then it doesn't matter if the password is written all over his hands. The next trick is to make him put it on a piece of paper and hide it. Then you could make him put it down in code, but he can't remember how to decode it so that has to be written down too. Doug - Original Message - From: Varley, Roger [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Monday, February 28, 2005 4:34 AM Subject: RE: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords 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. Is that strictly true? If you use the method that is used to encrypt Unix passwords (google for JCrypt for an implementation) then isn't this a one-way hash and you can't decrypt the passwords by reversing the algorithmn? Regards Roger __ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 urljdbc:pointbase:server://123.123.123.123:9092/demo/url driver-namecom.pointbase.xa.xaDataSource/driver-name properties property nameuser/name valueexamples/value /property property namedatabaseName/name valuejdbc:pointbase:server://123.123.123.123:9092/demo/value /property /properties password-encryptedeNEVN9dk4dEDUEVqL1/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 [EMAIL PROTECTED] 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:
Re: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
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 [EMAIL PROTECTED] 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 urljdbc:pointbase:server://123.123.123.123:9092/demo/url driver-namecom.pointbase.xa.xaDataSource/driver-name properties property nameuser/name valueexamples/value /property property namedatabaseName/name valuejdbc:pointbase:server://123.123.123.123:9092/demo/value /property /properties password-encryptedeNEVN9dk4dEDUEVqL1/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
RE: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
Why do you give your webapp access to a sql user with all this dangerous and unneccessary access? The user name / password on the externally-accessible machine could have a sql login that only granted access to views (or better yet) procedures, that allowed for the minimal necessary access: that's hardly 'enough access to dump all the credit card numbers'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question for Tomcat Developers - How to Plug In Encryption for JDBC passwords
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
