We are busy developing a Java web service for a client. There are two possible choices:
-
Store the encrypted user name / password on the web service client. Read from a config. file on the client side, decrypt and send.
-
Store the encrypted user name / password on the web server. Read from a config. file on the web server, decrypt and use in the web service.
The user name / password is used by the web service to access a third-party application.
The client already has classes that provide this functionality but this approach involves sending the user name / password in the clear (albeit within the intranet). They would prefer storing the info. within the web service but don’t really want to pay for something they already have. (Security is not a big consideration because it’s only within their intranet).
So we need something quick and easy in Java.
Any recommendations?
The server is Tomkat 5.5. The web service is Axis2.
- What encrypt / decrypt package should we use?
- What about a key store?
- What configuration mechanism should we use?
- Will this be easy to deploy?
Being on the intranet certainly does not justify dismissing security. Most damage done to information is by insiders. Look at the value of what’s being protected, and give due consideration to security.
It sounds like there’s a third-party application, for which you have one set of credentials, and some clients that effectively share this identity when using the third-party application. If that’s the case, I recommend the following approach.
Don’t distribute the third-party password beyond your web server.
The safest way to do this is to provide it to the web application interactively. This could be ServletContextListener that prompts for the password as the application starts, or a page in the application so that a admin can enter it through a form. The password is stored in the ServletContext and used to authenticate requests to the third-party service.
A step down in safety is to store the password on the server’s file system so that it’s readable only by the user running the server. This relies on the server’s file system permissions for protection.
Trying to store an encrypted form of the password, on the client or the server, is just taking one step backward. You fall into an infinite regress when trying to protect a secret with another secret.
In addition, the clients should authenticate themselves to the server. If the client is interactive, have the users enter a password. The server can then decide if that user is authorized to access the third-party service. If the client is not interactive, the next best security is to protect the client’s password using file system permissions.
To protect the clients’ credentials, the channel between the client and your web server should be protected with SSL. Here, operating on an intranet is advantageous, because you can use a self-signed certificate on the server.
If you do store passwords in a file, put them in a file by themselves; it makes the need to manage permissions carefully more conspicuous, and minimizes the need for many users to be editing that file and thus seeing the password.