## Password Aliases

If you're using a "single sign-on" system that allows you to share the same password across different machines/servers/applications, etc. you can setup Password Safe entries accordingly, so that changing one password affects all other related entries. This is called "aliasing" entries. This section describes how to define and use such aliases.

#### Summary

The basic idea is to allow one entry's password to be referred to by another. The "referred to" entry is called the base, and the "referring" entry (or entries) is (are) called the alias(es). When an entry is set to be the alias of another entry, the alias's password effectively "follows" that entry's password: If you copy the alias' password to the clipboard, the password that gets copied is the base's. If you change the base's password, this is immediately reflected in all the alias entries associated with the base. Although this may sound complicated, in fact it's quite simple and intuitive to use. The hardest part is setting up the aliases, as described below.

#### Defining an alias

In Password Safe, an entry can refer to another's password by means of a specially formatted password in the referring entry. The format is the "name" of the referred-to entry enclosed in square brackets. Most of the time, you can think of "name" as synonymous with the title field of an entry, so if the base entry's title is "master", for example, then entering "[master]" (without the quotes) in another entry's password field is enough to define the other entry as an alias of "master".

In the general case, a "name" can contain all of the following fields, separated by colons: Group, Title and User name. Note that if the title is unique in the database, then the other fields are optional. Likewise, if the group and title together or title and user together specify a unique entry, then the corresponding user or group doesn't have to be specified.

In Password Safe entries, only the Title and Password fields are mandatory. Group and User name fields are optional as long as the resulting combination of "group/title/user name" is unique. As indicated above, the alias' "password" is in the form [g:t:u] but in fact you only have to specify enough information to uniquely identify the base entry. So, if there is only one entry in the database with title 't', then [t] would be sufficient - since title is mandatory and only one item is given, it is assumed to be the title. If there were more than one entry with this title, you would be warned that this is the case, and you would need to be more specific in order to uniquely identify the base entry by adding either its group, its user name, or both. As long as there is a matching unique entry, any of the following formats are accepted: [g:t:u], [g:t], [t:u] or [t]. Specifying a colon without a value implies an empty field, e.g. [g:t:] means an entry with title 't' in group 'g' and with no user name value and [:t:] specifies an entry with title 't' in the root with no user name value, etc.

If you change the password of an Alias (either via the Generate password button or by typing in the password field), the change will only be made when the Apply or OK button is clicked. However, if you wish to change the base entry's password, then you should edit the base entry directly. If you change the Alias's password from [g:t:u] to some other value not in this format, it will change from an alias to a "normal" entry, and will have no relation to the previous base entry. Of course, you can restore the connection by Undo, or manually editing the password.

Unlike shortcuts, which refer to the base entry for all fields, aliases have their own values for all fields except for its password, which is its base's. For example: copying the aliases URL will use the alias's value but copying the alias's password will copy its base's.

Finally, if a normal entry was saving its password history before it was made an alias by changing its password as described above, then it will retain this history. If the alias is then reverted back to a normal entry at a later date, this password history will again become active and be updated if its password is changed.

The following examples should make this clear.

#### Examples

1. If the base entry's title is "LDAP Server", and there are no other entries with that title, then an alias can be defined by an entry that has "[LDAP Server]" in the password field.
2. If there are "LDAP Server" entries in two different groups, say "Dept. A" and "Dept. B", then one can specify an alias to the latter by "[Dept. A:LDAP Server]". Note you do not have to specify the user name if the information you have provided uniquely identifies the base entry.
3. Different user names can also be used to differentiate between similar base entries, e.g., "[LDAP Server:Joe]" and "[LDAP Server:Mary]".
4. Finally, all three fields may be specified, as in "[Dept. A:LDAP Server:Joe]"

#### Display

Base entries, that is, entries with at least one alias "pointing" to them, are displayed with a green triangle instead of a green square in the nested tree view.

Alias entries are shown with grey triangles.