Password Security

Password Scope

Server and service passwords authenticate the identity of a server or service process to other processes, for example, an FTL server authenticating itself to an affiliated FTL server or to an authentication service. For transparent fault tolerance, you can use the same password for equivalent servers or services in a fault-tolerant arrangement.

Keystore passwords encrypt key files, such as the private key file that FTL servers use to identify themselves to clients and to other servers.

Passwords can be masked. You can mask passwords using tibftladmin. Masked passwords have $mask$ at the beginning of the string. Masked passwords are unmasked before being sent to the realm service.

Password Argument

When you supply a password, that argument is visible to casual observers. For example, command line arguments appear in the output of the UNIX ps command, even after you have cleared the shell's command history. Passwords in a file are visible to anyone who can access or intercept that file.

You can supply the password in any of the following forms. Each form results in a different level of security for the password, along with associated precautions you must take. Choose exactly one form.

Form	Description
file:file_path	This form can provide excellent security: only the file path is visible to observers. You must create a text file that contains only the password itself, store that file on the file system of the FTL server's host computer, and ensure the security of that file.
env:environment_var	This form can provide excellent security. You must set an environment variable in the shell where you run the FTL server. The value of that variable is the password string. You must ensure that only authorized personnel have access to that shell.
pass:password	This form is not secure: the password is in the configuration file itself. Do not use these forms except during development and early testing phases.