java - 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 vulnerabilities. One of the solutions we employed to make the files more secure is to create a new database user with read-only access to the database, and only for those tables that the JAR files required to operate. I then found out that they are storing these credentials in plain text files alongside the JAR files, only an educated-guess away from the public at large. And finally today they are asking for much looser database privileges, but I don't think she understands that she really shouldn't need them for a properly written JAR file.

Anyway, I'm pretty sure this developer wouldn't know a security vulnerability if it bit her on the backside. And I don't know enough about Java/JAR files to properly advise her on what she should be doing, only enough about infosec to tell her what she shouldn't be doing.

So what are the typical security considerations when writing a distributed JAR file that connects to a remote MySQL database? Is there a standard way to encrypt the connection details (username and/or password)? IIRC, aren't .jar files just glorified ZIP archives, and couldn't anyone therefor unpack the file and view the connection details in the source code? Is there a way to encrypt the jar file content?

---

UPDATE: I received the following clarification from the developer. Does this sound right?

All the classes in the jar file are encrypoted. i have always encrypted all the class files before archiving them in a jar file. if you open any [redacted] jar, you will only see encrypted code. so there is no chance for a user to be able to view the source code by decompiling the classed. the classes do use jdbc to connect to the db, the search eangine needs to connect to the DB to run sqls. these sqls are in teh encrypted clasees in the jar file.

when i asked you about the encrypting the DB password, I meant what you say below. we will write an encryption/decription code in java and use it. Thecompiled class from this source code will again get encrypted as part of the reoutine class encryption procedure. We use a Java obfuscation tool called Retroguard to encrypt all the classes. we also embed a key in the html page to make sure that the application will work only if it has been downloaded form [redacted] website. if the user copies the jar to his local machine and tries to run it, it will fail.

Answer 1

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.