How are secure database connections usually implemented in JAR files?

Question

I\'m not a Java developer, but my client has hired one to update some JAR files on their site. Prior to doing so, we audited the existing code and found a number of security

Answer 1

I'll begin my answer by stating something often stated: "any person can create a security scheme that he/she cannot break".

Now, taking note of the update where the mention of encryption and obfuscation is made in the same update, it would be wise to note that encryption is not the same as obfuscation. Technically, encryption involves the use of a key to transform some plaintext into ciphertext, with the plaintext recoverable only with knowledge of the original key. Obfuscation is nowhere close to encryption by definition - it involves the removal of information from executable source code, that renders the executable supposedly "difficult" to reverse-engineer. Usually, obfuscation involves replacement of symbols by smaller ones, and sometimes, reordering of source code that makes the reverse-engineered source code difficult to read, while retaining the execution profile of the original (obfuscated source code has the same code and data flow paths as the original).

Of importance here, is the fact that the password is coded into the source code. It is reasonable to assume that the obfuscated source code will also contain the hard coded password. This assumption is reasonable since most obfuscators have never attempted to mutate the constant pool within a class file - mutating a constant pool is dangerous for it can result in changes in runtime behavior. If the password has been hard-coded into the source code as a String, then the class file (obfuscated or not) will have the password in the String constant pool, which will be loaded into memory by the JVM (with no decryption or decoding process in between).

The best practice in this case is to get the end-users to specify the database user ID and password (if they're managing the application setup), to store these user provided credentials securely (this depends on the nature of the application; Java EE applications should attempt to have the container manage these credentials), and manage these credentials securely when they're retrieved from the secure store. You might want to take a look at the OWASP article on Insecure Storage for more pointers.

Given the use of an applet, it is not recommended to have the database user ID and password in the applet. This needs to be done for various reasons - good applications allow for changing the database user ID and password with mere configuration changes to the application. Hard coding the password in source code is bound to increase management overhead; you might have to get end-users to clear their Java applet cache every time the DBA chooses to change the password (and this is bound to happen occasionally in a sane data center). Moreover, you might also need to protect against database account lockouts, when the changes to the applet are being deployed. Like other recommendations posted, it would make a good deal of business sense to manage the database connections from within the middle tier.