A related
thread, although it has some diversions in it:
https://coderanch.com/t/307198/JDBC/java/Encrypted-Password-Oracle-JDBC
Placing an encrypted password in a file is of limited benefit, because as long as someone is using the same mechanism, they can copy the encrypted password, paste it in their malware, and gain just as much benefit as if it was unencrypted. You could, perhaps subclass the dbcp class to take an encrypted password, but that subclass would then have to locally decrypt the password, and therefore you risk having the cleartext password go down the network anyway.
The best protection for production database passwords (and other production resources) is to seal off the internal production environment from outside access, both in-house and global.
Perhaps a more practical approach is to override the dbcp config at the server level. If you provide a copy of the context.xml file in the
Tomcat servers conf/Catalina/localhost directory, that copy can contain the password in a more secure location. At a minimum, it wouldn't be as easy to pass around as a WAR file. I do this sometimes. Because I don't do separate builds for
test and production, the context.xml in the WAR is for the test system and I override it for production.
Incidentally, it's convenient, but not essential to put a context.xml in a WAR. The META-INF/context.xml file is Tomcat-specific, and not only not required by
J2EE, but other appservers have their own deployment descriptors which usually have different names and different locations.