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

To put it in plain text is (i think) serious vulnerable. Indeed, one can extract the jar and read what's written in that plain text.

If using a jar is a must, i will recommend to create a class (just a simple class) which contains the username, password, url, etc with final keyword. Even though this method is not really secure, at least a compiled class cannot be easily read. Another advantage (or perhaps disadvantage) is the 'hard-coded' connection properties cannot be easily modified. Even if you have the source code, you still need to re-compile it and re-jar it.

Answer 2

I think the convention for that kind of thing for most developers is to store a configuration file outside of the root of the web directory. Of course if this is a desktop application and not web that's not possible. Something I've done before in a SWING based MySQL driven app with limited number of users was instead of using a middle tier for authentication and presenting data as a service, using MySQL's built in authentication so that all of the security would be defined in the schema and then duplicating the permission settings for every user. Kind of a hackish but reliable approach.

Answer 3

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.

Answer 4

Yes, JARs are just ZIP files, so it's entirely possible to open one using WinZip and look at the contents. If you know what you're doing, you can find a plain text password inside.

It sounds like your JAR contains a client that connects directly to a database. You don't say whether this is done over the Internet or a VPN or a LAN. Is the database deployed remotely from the client?

This is one reason why client/server apps went away: it's hard to secure them over the Internet.

Your app sounds like classic client-server to me. Do I have that right?

A middle tier is usually introduced between the client and the database to check security, validate and bind inputs, and shuttle requests to the appropriate handler for fulfillment. Have users present credentials that your middle tier has to validate before passing them along to the database.

It can also give you a fighting chance against SQL injection attacks.

If you encrypt the JAR contents you'll have to write a custom class loader to decrypt them when loading. Not for the faint of heart.

If your client is a Swing app, with all the logic and database stuff built into the listeners and event handlers registered for each component, you'll have a serious rewrite on your hands. You'll be moving to more of a service oriented architecture, where all the work is done by services on the server side. The client only does what it's supposed to in classic MVC: pass events along to the server side and display results. Your client will be a lot lighter.

That's going to be the biggest shock to your development team and the business.