Network Security Considerations

This section describes how to use access control strings in file specifications and how to use proxy logins to help make network access more secure.

Protecting Information in Access Control Strings

Network access control strings can be included in the file specifications of DCL commands working across the DECnet for OpenVMS network. They permit a user on a local node to access a file on a remote node.

An access control string consists of the user name for the remote account and the user's password enclosed within quotation marks, as follows:

NODE"username password"::DISK:[DIRECTORY]FILE.TYP

Because access control strings include sufficient information to allow someone to break in to the remote account, they create serious security exposure. To protect access control string information, do the following:

Avoid revealing the information on either hardcopy or video terminals. If you use a hardcopy terminal, dispose of the output properly. If you use a video terminal, clear the screen, and empty the recall buffer with the DCL command RECALL/ERASE when the network job is completed. This prevents another user from seeing the password, either by displaying the command line with the Ctrl/B key sequence or with the DCL command RECALL/ALL. DECwindows users can clear the screen with the Clear Lines Off Top option from the Commands menu. Otherwise, a DECwindows user could use the scroll bar to view previously entered text.
Do not place networking commands that include access control strings in command procedures where they would be likely targets for discovery.
If you must put access control strings in your command procedures, provide these files with optimum file protection by using the techniques described in “Protecting Data”.
The use of access control strings in not permitted in an evaluated configuration. Please see your system administrator to determine if your system is running in an evaluated configuration.

To avoid the need for access control strings, you might prefer to use proxy login accounts, which are described in “Using Proxy Login Accounts to Protect Passwords”.

Using Proxy Login Accounts to Protect Passwords

Proxy logins let you access files across a network without specifying a user name or password in an access control string. Thus, proxy logins have the following security benefits:

Passwords are not echoed on the terminal where the request originates.
Passwords are not passed between systems where they might be intercepted in unencrypted form.
Passwords are not needed in command files to perform the remote access steps.

Before you can initiate a proxy login, the system or security administrator at the remote node must create a proxy account for you. Proxy accounts, like regular accounts, are created with the Authorize utility (AUTHORIZE). They are usually nonprivileged accounts. Security administrators can allow you access to one default proxy account and up to 15 other proxy accounts. While proxy logins require more setup effort on the part of system managers, they provide more secure network access and eliminate the need for users to enter access control strings.

The following examples illustrate the differences between a normal network login request and a proxy login request. For each example, the following conditions exist:

The user KMAHOGANY has two user accounts:
- An account on node BIRCH with the password XYZ123ABC
- An account on node WALNUT with the password A25D3255
KMAHOGANY has logged in to node BIRCH.
KMAHOGANY wants to copy the file BIONEWS.MEM from the default device and directory of the account on the node WALNUT.

The following diagram illustrates these conditions:

Figure 3-1 Network and Proxy Logins

The user KMAHOGANY could use an access control string to copy the file BIONEWS.MEM, as follows:

$ COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM  BIONEWS.MEM

Notice that the password A25D3255 echoes. Anyone who observes the screen can see it. In contrast, if KMAHOGANY has proxy access from node BIRCH to the account on node WALNUT, the command for copying the file BIONEWS.MEM is as follows:

$ COPY WALNUT::BIONEWS.MEM   BIONEWS.MEM

KMAHOGANY does not need to specify a password in an access control string. Instead, the system performs a proxy login from the account on node BIRCH into the account on node WALNUT. There is no exchange of passwords.

Using a General Access Proxy Account

Your security administrator can also authorize groups of users from foreign nodes to share in the use of a general access proxy account. For example, the security administrator at node WALNUT can create a general access account with the following conditions:

The user name GENACCESS.
Access limited to network logins.
A password known only to the owner of the account. (None of the remote users need to know it.) This helps to protect the account.
The default device and directory STAFFDEV:[BIOSTAFF].

If the security administrator grants BIRCH::KMAHOGANY proxy access to the GENACCESS account, the user KMAHOGANY can copy the file BIONEWS.MEM by entering the following command:

$ COPY WALNUT::[KMAHOGANY]BIONEWS.MEM   BIONEWS.MEM

Note that KMAHOGANY must specify the directory [KMAHOGANY] because the file BIONEWS.MEM is not in the default device and directory for the GENACCESS account (STAFFDEV:[BIOSTAFF]). In addition, the protection for the file BIONEWS.MEM must permit access to the GENACCESS account. Otherwise, the command fails.

When You Need to Specify the Name of a Proxy Account

If you have access to more than one proxy account on a given node and you do not want to use the default proxy account, specify the name of the proxy account. For example, to use a proxy account called PROXY2 instead of the GENACCESS account (the default), KMAHOGANY enters the following command:

$COPY WALNUT"PROXY2"::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM

This command uses the PROXY2 account to copy the file BIONEWS.MEM from the [KMAHOGANY] directory on node WALNUT.