How do you handle passwords or credentials for standalone applications?

Question

Let's say that you have a standalone application (a Java application in my case) and that this application has a configuration file (a XML file in my case) where you store the credentials (user and password) for a bunch of databases you need to connect.

Everything works great, but now you discover (or your are given a new requirement like me) that you have to put this application in a different server and that you can't have these credentials in the configuration files because of security and/or compliance considerations.

I'm considering to use data sources hosted in the application server (a WAS server), but I think this could have poor performance and maybe it's not the best approach since I'm connecting from a standalone application.

I was also considering to use some sort of encryption, but I would like to keep things as simple as possible.

How would you handle this case? Where would you put these credentials or protect them from being compromised? Or how would you connect to your databases in this scenario?

Answer 1

I'm considering to use data sources hosted in the application server (a WAS server), but I think this could have poor performance and maybe it's not the best approach since I'm connecting from a standalone application.

In contrary, those datasources are usually connection pooled datasources and it should just enhance DB connecting performance since connecting is per saldo the most expensive task.

Have you tested/benchmarked it?

Answer 2

I was also considering to use some sort of encryption, but I would like to keep things as simple as possible.

Take a look at the Java Cryptography Architecture - Password Based Encryption. The concept is fairly straight forward, you encrypt/decrypt the XML stream with a key derived from a user password prior to (de)serializing the file.

I'm only guessing at what your security/compliance considerations require, but definitely some things to consider:

1. Require strong passwords.
2. Try to minimize the amount of time that you leave the sensitive material decrypted.
3. At runtime, handle sensitive material carefully - don't leave it exposed in a global object; instead, try to reduce the scope of sensitive material as much as possible. For example, encapsulate all decrypted data as private in a single class.
4. Think about how you should handle the case where the password to the configuration file is lost. Perhaps its simple in that you can just create a new config file?
5. Require both a strong password and a user keyfile to access the configuration file. That would leave it up to the user to store the keyfile safely; and if either piece of information is accidentally exposed, it's still useless without both.

While this is probably overkill, I highly recommend taking a look at Applied Cryptography by Bruce Schneier. It provides a great look into the realm of crypto.

Answer 3

if your standalone application runs in a large business or enterprise, it's likely that they're using the Lightweight Directory Access Protocol, or LDAP, for their passwords.

You might want to consider using an LDAP, or providing hooks in your application for a corporate LDAP.