Comments on: Spring and encrypted DataSource passwords http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/ In the kingdom of hope, there is no winter. Fri, 28 Oct 2011 16:23:11 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Dmitri Maximovich http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/comment-page-1/#comment-4480 Dmitri Maximovich Tue, 16 Aug 2005 16:31:25 +0000 http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/#comment-4480 http://en.wikipedia.org/wiki/Security_by_obscurity http://en.wikipedia.org/wiki/Security_by_obscurity

]]> By: Dmitri Maximovich http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/comment-page-1/#comment-4479 Dmitri Maximovich Tue, 16 Aug 2005 16:28:33 +0000 http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/#comment-4479 Vinny, I hear what you saying but for me false sence of security is actually worse than no security at all ;-) Users looking at *Secure*DriverManagerDataSource would assume that they're much better protected when in reality this won't stop anybody who even little determined to break into this. Following your logic, whole application context could be placed in the directory where you can use persmissions to restrict access to it (but app. server still going to need read permissions) ;-) PS Java keystore, though not ideal in may ways, was designed to prevent keys from being kept in open. Vinny,

I hear what you saying but for me false sence of security is actually worse than no security at all ;-) Users looking at *Secure*DriverManagerDataSource would assume that they’re much better protected when in reality this won’t stop anybody who even little determined to break into this.

Following your logic, whole application context could be placed in the directory where you can use persmissions to restrict access to it (but app. server still going to need read permissions) ;-)

PS Java keystore, though not ideal in may ways, was designed to prevent keys from being kept in open.

]]> By: Vinny Carpenter http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/comment-page-1/#comment-4478 Vinny Carpenter Tue, 16 Aug 2005 16:08:03 +0000 http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/#comment-4478 Hi Dmitri. I agree with you in principal but the idea of using 2-way encryption is part of the '<a href="http://en.wikipedia.org/wiki/Defense_in_depth" rel="nofollow">Defense in depth</a>' strategy. Encrypting the password and separating the key makes it a little harder for someone to get access to the database. The key needed to decrypt could be placed in a directory where you can use UNIX permissions to restrict access - It's not perfect but you are adding layers of security. Hi Dmitri. I agree with you in principal but the idea of using 2-way encryption is part of the ‘Defense in depth‘ strategy. Encrypting the password and separating the key makes it a little harder for someone to get access to the database. The key needed to decrypt could be placed in a directory where you can use UNIX permissions to restrict access – It’s not perfect but you are adding layers of security.

]]> By: Dmitri Maximovich http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/comment-page-1/#comment-4477 Dmitri Maximovich Tue, 16 Aug 2005 15:38:18 +0000 http://www.j2eegeek.com/blog/2005/08/15/spring-and-encrypted-datasource-passwords/#comment-4477 As I commented on Matt's blog - what's the point to encrypt password with reversible algorithm and keep the key as an open string? Does it adds security really? As I commented on Matt’s blog – what’s the point to encrypt password with reversible algorithm and keep the key as an open string? Does it adds security really?

]]>