Re: How to hide the keystorePass at the server.xml
TC 3.3.x had an optional module to do this. It never got ported. I generally agree with most of the people that say that this is the least of your problems. If you are usings a self-signed cert, then you are just getting what you deserve. Otherwise, you simply contact the CA and revoke the cert: At least this problem solved :). Now, how to deal with the fact that the hacker just uploaded 10,000 credit-card numbers, since my jdbc password was in the clear :). Dickson Lam (dilam) [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I am using Tomcat 5.5.16 window version. When I configure Tomcat to use SSL, I need to put the keystorePass password on the Tomcat server.xml file which is in plain text format. Is it anyway I can hide the keystore password from the server.xml? or configure Tomcat to read in an encrypted keystorePass password and decrypted the password during startup? Regards Dickson - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to hide the keystorePass at the server.xml
On 6/2/06, Bill Barker [EMAIL PROTECTED] wrote: TC 3.3.x had an optional module to do this. It never got ported. I generally agree with most of the people that say that this is the least of your problems. If you are usings a self-signed cert, then you are just getting what you deserve. Otherwise, you simply contact the CA and revoke the cert: At least this problem solved :). Now, how to deal with the fact that the hacker just uploaded 10,000 credit-card numbers, since my jdbc password was in the clear :). Actually you are not allowed to save credit card numbers unless you are a certified payment provider (which implies major security constraints). Even a certified payment provider is not allowed to store cvc codes, and without the codes the credit card numbers are useless. (amazon of course is an exception to this rule...) However, if you saving cc-numbers or bank accounts or any other payment related data in your database unencrypted you belong in jail :-) But please feel free to tell us that you are doing one of the above, so we know which sites to avoid :-) regards leon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to hide the keystorePass at the server.xml
Leon Rosenberg wrote: On 6/2/06, Bill Barker [EMAIL PROTECTED] wrote: TC 3.3.x had an optional module to do this. It never got ported. I generally agree with most of the people that say that this is the least of your problems. If you are usings a self-signed cert, then you are just getting what you deserve. Otherwise, you simply contact the CA and revoke the cert: At least this problem solved :). Now, how to deal with the fact that the hacker just uploaded 10,000 credit-card numbers, since my jdbc password was in the clear :). Actually you are not allowed to save credit card numbers unless you are a certified payment provider (which implies major security constraints). Even a certified payment provider is not allowed to store cvc codes, and without the codes the credit card numbers are useless. (amazon of course is an exception to this rule...) However, if you saving cc-numbers or bank accounts or any other payment related data in your database unencrypted you belong in jail :-) But please feel free to tell us that you are doing one of the above, so we know which sites to avoid :-) Somewhat true, but nearly every site that collects payment information and charges at a later date stores that information until the card is actually processed, and many businesses do not charge the card until the product/service has been delivered. Furthermore, that simply begs the issue, since it could be SSN, salaries, student loan info, job histories, etc. that become vulnerable. I don't think there's much argument that allowing the option to manually enter the keystore password is a bad thing, just that protecting an SSL cert is only a small concern if your filesystem has been compromised. David - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to hide the keystorePass at the server.xml
Robert Harper wrote: One thing to think of is that if you have to do that to protect it, then everything else on that system is suspect. Yeah, yeah. I used to use this argument a lot, too. But that's like saying: if your harness isn't secure, then why bother with an additional safety net below you? You might as well fall and die.. It's not that obfuscating or encrypting the keystorePass is a fool-proof answer, but that it adds an additional step of complexity in the way of anyone who might crack your system. Stuff happens. Just because a burglar got past your front door doesn't mean that you have to lay out your valuables in the foyer.. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to hide the keystorePass at the server.xml
Shankar Unni wrote: Robert Harper wrote: One thing to think of is that if you have to do that to protect it, then everything else on that system is suspect. Yeah, yeah. I used to use this argument a lot, too. But that's like saying: if your harness isn't secure, then why bother with an additional safety net below you? You might as well fall and die.. It's not that obfuscating or encrypting the keystorePass is a fool-proof answer, but that it adds an additional step of complexity in the way of anyone who might crack your system. Stuff happens. Just because a burglar got past your front door doesn't mean that you have to lay out your valuables in the foyer.. The problem is that if you encrypt the keystore password somewhere (or even still embedded in the server.xml file), how do you tell Tomcat how to decrypt that? In the end, you have to enter a password or other credential into the system. A possible sounding solution would be to have tomcat start in a protected mode that requires an admin connect and enter a password before TC would allow the webapps to load. But even this would require that TC be configured to do so since most would not want this. And if you can access the filesystem, then you could change that configuration so that TC would start and NOT require that. You can even change the java security policy file. So you'd need to create a forked TC that always requires the password to be entered. But then again, if they can access the filesystem, they could just change out the version of TC. And if they can work on your file system, they can probably insert new code into the WEB-INF/lib or WEB-INF/classes or any of the JSPs. And if they can do all that, you probably have no security to begin with. In the end, a secure version of Tomcat that always required a password or other credential be provided before it starts, with an encrypted JSP and configuration file store, etc. would be needed. David - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
