XML security is only as secure as the keys used to secure them. How do people secure their keys.
The complexity of this issue depends on who performs what roles. In a home or small operation, the same person may perform all roles. In a larger shop, the developer, system administrator, db administrator, source code administrator and the security administrator may be different people. Container based keystore: Some J2EE containers have a keystore built in and it is up to some administrator to setup up the keys for the required aliases. This approach is good since the keys are protected by the container and should only be accessible within the container using the appropriate API and the same code can have different keys for the different environments such as dev, test, QA and production. The problem with this approach is that you need a container that supports this and each developer has to configure their own container individually. Keystore file without a password: This allows the code to use the Keystore API to access the keys without knowing the password but this approach is only as secure as the file system and anybody who has read access to the file can use the keys. Do you trust the nighttime system administrator at the ISP hosting your site? Unless something goes wrong at night, you may never even know who they are. Keystore file with hard coded password: This is a step up from no password, but anybody that can read the source code or de-compile the executable code can see the password. Any breaches in security on the machine would require a new version of the code. Keystore file with a password in a file: This is similar to a hard coded password but now it is in a file. If you have access to the keystore file, you probably have access to the password file. The benefit is that keystore and password can be swapped without affecting the code. Keystore file with a password in a parameter: This is a great solution except for the fact that the password is either hard coded in a startup script and saved in some command line history and displayed when you list executing tasks or the system can not automatically start and some unknown operator must read the password printed from a piece of paper that is probably mounted on a cafeteria bulletin board and entered it each time an instance is started. Keystore file with generated password: This is similar other file based solutions but you need some way to consistently generate the password and you can not used third party tools to administrate the keystore. Any ideas on a good way to generate the password? So what keeps you up at night? Any comments or suggestions? Wes.
