[Webappsec] Fwd: [Java-project] Fwd: Java security & tomcat with DB credentials

[Stephen de Vries]

Excuse the cross-list forwarding, but it's good stuff:


Begin forwarded message:

> From: "Jeff Williams" <jeff.williams at owasp.org>
> Date: 19 April 2007 19:32:14 GMT+02:00
> To: "'Stephen de Vries'" <stephen at twisteddelight.org>, <java- 
> project at lists.owasp.org>
> Subject: RE: [Java-project] Fwd: [Webappsec] Java security & tomcat  
> with DB credentials
> Reply-To: <jeff.williams at owasp.org>
>
> This is a great question that applies to all web app environments.  
> One way
> or another, you must have a "master key" that is available to the
> application. You can't encrypt this key, because that implies that  
> you have
> another key to decrypt it.  A commercial product vendor I was  
> working with a
> few weeks ago went through three levels of this shell game before  
> telling me
> where the actual master key was stored.  Just keep asking, "where  
> is the key
> for that stored"?
>
> So where should you store this master key?  Some environments have  
> protected
> locations, such as the WebSphere configuration files, or the system
> registry.  You can use a file in a protected location, that uses OS  
> access
> control to limit access to only the application.  You could put the  
> key in
> the code, but that makes it difficult to change and deploy  
> securely.  You
> can also force the master key to be entered when the system boots  
> up so it's
> only in memory, but that means you lose automatic reboot. You can  
> even split
> the key and put parts in more than one of these locations.
>
> Think through the threats you're trying to counter here:
> - insider steals master key during development, compromises db
> - insider steals master key in production, compromises db
> - hacker guesses password because it wasn't changed, compromises db
> - hacker compromises system, steals master key, compromises db
>
> The insider threat seems more likely to me, assuming you're doing  
> other
> things to harden the environment. I'm always *very* emphatic about the
> importance of changing the key between development and production.
>
> In any case, once you have a master key, then you can use it to  
> create an
> encrypted properties file.  I just put up this article on how to do  
> this
> easily...
>
> https://www.owasp.org/index.php/How_to_encrypt_a_properties_file
>
> --Jeff
>
> Jeff Williams, Chair
> The OWASP Foundation
> "Dedicated to finding and fighting the causes of insecure software"
>
>
> -----Original Message-----
> From: java-project-bounces at lists.owasp.org
> [mailto:java-project-bounces at lists.owasp.org] On Behalf Of Stephen  
> de Vries
> Sent: Thursday, April 19, 2007 10:47 AM
> To: java-project at lists.owasp.org
> Subject: [Java-project] Fwd: [Webappsec] Java security & tomcat  
> with DB
> credentials
>
>
> Good question about securing DB credentials:
>
> Begin forwarded message:
>
>> From: "Steven Whatmore" <Stevenw at sigmasoft.ca>
>> Date: 19 April 2007 16:35:33 GMT+02:00
>> To: <webappsec at lists.owasp.org>
>> Subject: [Webappsec] Java security & tomcat with DB credentials
>>
>> Good morning,
>>
>> I am looking for some strategies for maintaining the security of
>> the DB
>> credentials in a Tomcat Java / JSP application.
>>
>> As is the standard in almost all Java / JSP application running in  
>> the
>> context of a Tomcat server, the credentials for connecting to the
>> database are maintained in some form in a properties file, whether
>> that
>> is the context.xml or some other properties file. These credentials
>> are
>> maintained in clear text, so that if the security of the application
>> server is breached, any informed hacker would only have to look in
>> these
>> property files to gain the credentials for accessing the DB.
>>
>> The question then is how to properly secure these credentials so that
>> the application can still connect to the DB securely, while at the
>> same
>> time allowing the application to be started / restarted without
>> operator
>> intervention (i.e. on server crash and restart having the application
>> start up automatically without an operator having to key in the
>> credentials manually).
>>
>> Any thoughts or strategies?
>>
>> Thanks in advance.
>>
>> Whatty
>>
>> _______________________________________________
>> Webappsec mailing list
>> Webappsec at lists.owasp.org
>> http://lists.owasp.org/mailman/listinfo/webappsec
>
> -- 
> Stephen de Vries
> Corsaire Ltd
> E-mail: stephen at corsaire.com
> Tel:	+44 1483 226014
> Fax: 	+44 1483 226068
> Web: 	http://www.corsaire.com
>
>
>
>
> _______________________________________________
> Java-project mailing list
> Java-project at lists.owasp.org
> http://lists.owasp.org/mailman/listinfo/java-project
>

-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com