I recently started working on a personal project where I was connecting to a database using Java. This got me thinking. I have to provide the login information for a database account on the DB server in order to access the database. But if I hard code it in then it would be possible for someone to decompile the program and extract that login info. If I store it in an external setup file then the same problem exists only it would be even easier for them to get it. I could encrypt the data before storing it in either place but it seems like that's not really a fail safe either and I'm no encryption expert by any means. So what are some best practices for storing sensitive setup data for a program?

5 Answers 5


Several options here:

  • Run the Java program under a domain user which is granted access to the database (or, alternatively, store the password information in a file which is only accessible by the user that is running your program).

  • use a key store, with restrictions to both the user and software which will be using the key (such as what Mac OS X provides)

  • use a standard encryption solution, with an interface which will require input of the encryption password on program startup (so the admin starting up the program knows the password, only)

  • require that the uid/password for the database be entered on program startup


First rule of sensitive data storage is don't. In this case, you should probably do what just about every authentication system does -- issue each user their own credentials so you don't have this problem. Or problems like "oh, snap, the database account got compromised. Now I've got to figure out how to reissue this password to every user. Including the ones I don't know about."


There is no way to prevent anyone who receives your application from learning the username and password. If that is unacceptable, then you will have to put some software between the application and the database, like a web service.


Typically you want to try and encrypt that kind of information. For example the general practice with web development in .NET is to encrypt the section of the web.config that contains the connection strings. The other you can do is use domain/windows/os accounts instead of direct connections. This keeps you from hard coding the password into your app or config files. Instead you manage your connections by authorizing the user of the application (or account it runs under).


You have to encrypt your application so it can't be decompiled. I do not know the Java tools, but they exist for sure.

By the way, you should always encrypt your applications for safety! Then you can hardcode it if you want.

EDIT: Following the comment, I will precise that you CAN encrype your application, you only need to have a tool (kind of 'on the fly' decrypter) on the user's machine to run the encrypted app. This is what I used with Foxpro and it mose probably exist too for other languages. Maybe, though, that type of tools is not used in more recent technology, but it definitly makes my apps impossible to decompile while running well.

EDIT 2: Some product I found for .NET encryption: http://www.hallogram.com/ezcryptonet/index.html

  • 4
    obfuscation != encryption. What you recommended is neither technically feasible, nor exists for any software. Programms which are encrypted so they cannot be decompiled also cannot be executed. Programs which can be executed, can always be decompiled Mar 3, 2011 at 4:05
  • 2
    what prevents the user from collecting the output of the decrypter, or modifying the decrypter? Mar 3, 2011 at 5:50
  • My wording here was wrong, it doesn't decrypt, but rather interprete. About modifying the decrypter, well, I guess that could maybe be a possibility. My knowledge of the subjet is not extanded enough to answer on that.
    – Mathieu
    Mar 3, 2011 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.