One of the limitations of using Spring outside of the traditional J2EE container is hard-coding database information inside the Spring configuration file. If you are deploying the application inside the container, you can simply reference the DataSource via JNDI and not have to provide login, password information about the database connection. To work around that issue, Matt has extended Spring implementation of javax.sql.Datasource and added support for hashing/encrypting the database password. Permalink to Matt’s blog is here .
Spring, DataSource, Encryption
Vinny Carpenter's blog 
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?
LikeLike
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.
LikeLike
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.
LikeLike
http://en.wikipedia.org/wiki/Security_by_obscurity
LikeLike