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:
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:
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.
