How to store passphrase in this situation?

Question

How to store a passphrase with a Java application that periodically needs access to its plaintext form? It is a strange situation, but I am wedged in it. If providing a decent security mechanism is impossible, any tips on deterring script-kiddies?

Elaboration on my situation (it rhymes):

It's an inconvenient (read "horrible") situation where the application will be accessing a remote http (not https) service, passing a login/password in plaintext, a few times a week. Yes, ideally I would change service, but I can't do that. Given that, my question is on how to store the login, which the application needs to be able to access in plaintext/unencrypted form. Is there a more secure or at least script-kiddies deterrent solution than just hardcoding the plain values?

Elaboration 2:

This is a server app. I might have the option to host it on a Java EE app server, I am not aware of benefits it provides though. At the same time I am equally interested in how I could deal with this outside a JEE app sever.

Answer 1

First, the login should be issued per-client, so it can be changed if leaked, or cancelled when a client's access to the service is revoked. This reduces the consequences of loss of the password to the smallest size, instead of losing everything when one client is compromised or goes rogue.

Once you have done that, your problem is simply to store a password which is used for this one client with this one service. This is a well-known problem with well-known solutions. Essentially, you should assume that the operating system is secure. (If it is not you have bigger problems.) So save it into a file, the registry etc, and protect it with an ACL. If you wish you can add obfuscation on top of that, or use CryptProtectData or similar, which can provide some protection against unsophisticated attackers.

But the bottom line is you need to accept that issuing, revoking, and resetting credentials is going to be a normal part of your operation. You will also want to monitor usage of the service so you can detect when credentials have leaked.

Answer 2

This is difficult to achieve without leaving a reasonably significant level of risk (if the host were to be compromised in some way), although can be mitigated to some degree.

The HTTP credentials should be encrypted via a strong (and well established) symmetric algorithm, which would require a password for decryption. Since it will need to decrypt the password without an operator being present, the key will need to be available somewhere - which is the weakness of this method. I would advise against hard-coding any of these details, since all could be revealed if someone got their hands on the application files. Instead, I would recommend that the user is asked for the HTTP credentials and an encryption password during setup / first use. The application would then ask for the encryption password each time it is started, which will be stored in memory until the application process ends. This would require an operator during the first install and for each reboot etc.

(N.b. It is recommended that character arrays are used for password variables rather than strings due to garbage collection in Java. See here: https://stackoverflow.com/a/12981202/3177084)

However, a more convenient solution - which relies on the application being used solely on Windows, but essentially manages all of the above for you - would be to utilise DPAPI. This basically encrypts and stores credentials using the Windows account details, so the application should be able to retrieve the HTTP credentials as long as its being executed by a user who has stored them via DPAPI. This has similar weaknesses to the home-grown solution above, but avoids the pitfalls of implementing your own crypto-system.

Answer 3

Apparently, your main vulnerability in this model is the network: spending time and money in trying to store data that will travel in cleartext is a waste of time (and money).

Typically, you will attempt to solve that kind of problem by adding a security layer around the vulnerable part: if you can't get the remote system to use HTTPS, then use a VPN that ends as close as possible to the target server (because anyone having access to the network between that VPN endpoint and the HTTP server will be able to obtain the cleartext data).

Another option is to place both systems in the same hardened network. (This usually only makes sense if you already have such a network available).

Once you have secured the network, then you can think about securing these keys (although, in your case, it might still be pointless if the remote system doesn't treat this key securely).

Answer 4

Encode it in Base64 keep the result in a variable and decode it when needed. That will keep script-kiddies away, but not rest.