LJK/Security Reference Manual
Previous Contents Index

Three separate wild proxy tests are provided to increase the granularity with which exemptions can be granted in settings where that must be done.

One situation where a wildcard proxy entry may be good for security is when it is used as the method for getting rid of a default incoming DECnet account. Allowing unrestricted access from a particular node is more secure than allowing unrestricted access from all nodes!

PWDAGE

Ensure that individual usernames have acceptable password ages.

Violation reports

Constraint Nature of the violation
ABSOLUTHI Higher than maximum in the policy

Description

The system User Authorization File (SYSUAF) specifies for each username the date of the last password change for either the primary or secondary password (if any).

The purpose of this test is to ensure that the password change for each user complies with organization-wide security policy. This test compares that value for each authorized username against each privilege-related limit set in the policy.

Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

Default policy

The password age minimum and maximum are 0 for non-privileged accounts and privileged accounts 1 relying instead on tests (UAF,PWDLIFE,*)

Customizing

Change the default limits to match your own organization policy.

A limit or exemption with a value of zero means there is no value which is considered unacceptable. selector Limits and exemptions for this test can take a selector consisting of a privilege name or a privilege-level name.

Thus, each can be set once for each possible privilege and once for each possible privilege level. If a username has a given privilege or is at a given privilege-level then that limit applies. When using the Command Interface if you do not specify a selector when changing the limit or exemptions your change applies to all privileges and privilege levels.

Limits

Constraint Value Default
ABSOLUTHI 0---n 0

Exemptions

Constraint Value Parameters
ABSOLUTHI 0---n <node>, <username>

Practical considerations

If password ages are too long, some user may be evading organization policy.

Note

1 Usernames with just NETMBX and TMPMBX will be treated as non-privileged.

PWDENCRYPT

Determine whether password encryption algorithm conforms to policy.

Violation reports

Constraint Nature of the violation
OLD Password encryption algorithm is older than allowed by policy
NEW Password encryption algorithm is newer than allowed by policy

Description

Password encryption algorithms are only changed when passwords are changed. If your system has any very old accounts from prior versions of VMS which have relaxed password lifetimes, then older less-secure password encryption algorithms may be in use. If the user changes the password, the newer forms of encryption will be used.

Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

Default policy

The password encryption algorithm must be the latest

Customizing

Customization is probably not appropriate. Get users to change passwords and advance to the newest algorithm

Selector

Limits

Constraint Value Default
OLD AD_II, PURDY, PURDY_V, PURDY_S or CUSTOMER_n PURDY_V
NEW AD_II, PURDY, PURDY_V, PURDY_S or CUSTOMER_n PURDY_S

Exemptions

Constraint Value Parameters
OLD AD_II, PURDY, PURDY_V, PURDY_S or CUSTOMER_n <node>, <username>
NEW AD_II, PURDY, PURDY_V, PURDY_S or CUSTOMER_n <node>, <username>

Practical considerations

Be gentle when attempting to bring users into compliance in this area. The very existence of multiple algorithms is unknown to most users.

Possible values include:

PWDEXPIRED

Determine whether password expiration conforms to policy.

Violation reports

Constraint Nature of the violation
NOTICED Password has expired and been noticed by user
NOTNOTICED Password has expired and not been noticed by user

Description

Expired passwords not yet noticed by users will be brought to the user's attention on their next login attempt. Those which have been noticed will require system administrator intervention to make the usernames useful again.

Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

Default policy

Passwords must not have expired more than 30 days ago

Customizing

You may choose to tighten the limit for the NOTICED test, since that can provide an indication of user confusion.

A limit or exemption with a value of zero means there is no value which is considered unacceptable

Selector

Limits

Constraint Value Default
NOTICED 0---n (days) 30
NOTNOTICED 0---n (days) 30

Exemptions

Constraint Value Parameters
NOTICED 0---n (days) <node>, <username>
NOTNOTICED 0---n (days) <node>, <username>

Practical considerations

Unnoticed password expirations may indicate that the real problem is username inactivity (should that username exist if it is not needed?).

PWDGUESS

Guess passwords to see if they are too simple.

Violation reports

Constraint Nature of the violation
TRIES Guessed in fewer than specified number of tries

Description

If passwords are simple enough to be guessed by this program, they are simple enough to be guessed by an attacker. Of course the attacker will be hindered by the breakin evasion features of VMS, denying access even with a correct password if it follows too many incorrect guesses. Since LJK/Security accesses the authorization file directly, its guesses are not hindered by VMS breakin evasion.

LJK/Security as a matter of policy does not display the password if a correct guess is made, it merely indicates approximately how many tries were required. The exact number of guesses required is not reported, in order to prevent the use of reverse-engineering to determine the password. This approach is taken to prevent LJK/Security from being used as a breakin tool (since learning the password of another allows unauthorized accesses to be made as though they had come from the user whose password was learned).

Password guessing is still performed on usernames which are set to require generated passwords or make use of the password history and screening provided effective with VMS V5.4. These controls only affect passwords set up with the SET PASSWORD command and do not protect against the setting of a weak password by a privileged user with the AUTHORIZE program.

By adjusting the limit you can control how much guessing is done against each password.

Default policy

Only 10 guesses will be made (ineffective against all but the simplest passwords) against non-privileged accounts 1 , in order to minimize execution time.

By default, only 100 guesses will be made against privileged accounts, in order to minimize execution time

Customizing

Choose a number of tries appropriate for your situation. Password guessing is not attempted against usernames which are set to require generated passwords. For other usernames, however, a large number of password guessing tries can require considerably more time to perform an assessment (especially when multiplied by the number of users). It will also provide a CPU-intensive drain on the tributary node.

For most situations, a larger number of tries for privileged accounts is appropriate.

Password guessing is at least partially dictionary-based. By editing the file LJK$SECURITY_POLICY_AREA:LJK$SECURITY_WORDS.DAT you can add site-specific terms which you suspect might be used in passwords. As supplied, this file is empty, the words provided by LJK Software are kept elsewhere. selector Limits for this test can take a selector consisting of a privilege name or a privilege-level name.

Thus each can be set once for each possible privilege and once for each possible privilege level. If a username has a given privilege or is at a given privilege-level then that limit applies. When using the Command Interface if you do not specify a selector when changing the limit or exemptions your change applies to all privileges.

Limits

Constraint Value Default
TRIES 0---n 10 or 100*

* Higher value for levels above Category-Normal.

Exemptions

Constraint Value Parameters
TRIES 0---n <node>, <username>

Practical considerations

The degree to which passwords are unguessable is often much less important than human considerations, such as discouraging password sharing.

You may want to have a special policy and assessment which has higher values for this test, and run that assessment only on weekends when the demand for CPU time is not so great.

If the fact that LJK/Security does not report the guessed password hinders your ability to get users to change their passwords, LJK Software suggests a disclosure meeting, where the user will reveal the password and then change it (use the VMS authorize utility to make sure it has not already been changed since the guessing was reported). If the user had a password which was not "easy to guess" in human terms, LJK Software would like to get a report of what it was.

Note

1 Usernames with just NETMBX and TMPMBX will be treated as non-privileged.

PWDLIFE

Ensure that individual usernames have acceptable password lifetimes.

Violation reports

Constraint Nature of the violation
ABSOLUTLO Lower than minimum in the policy
ABSOLUTHI Higher than maximum in the policy

Description

The system User Authorization File (SYSUAF) specifies for each username the password lifetime for either the primary or secondary password (if any).

The purpose of this test is to ensure that the password lifetime established for each user complies with organization-wide security policy. This test compares that value for each authorized username against each limit set in the policy.

VMS treats a password lifetime of 0 as meaning "without limit", so violation notices from LJK/Security may seem strange at times indicating that a value of 0 is higher than the limit of 90.

Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

Default policy

The password lifetime minimum is 30 days and maximum is 90 days for non-privileged accounts and 30 days for privileged accounts 1. This corresponds to the values recommended by DEC with the release of VMS V5.2

Customizing

Change the default limits to match your own organization policy.

A limit or exemption with a value of zero means there is no value which is considered unacceptable. selector Limits and exemptions for this test can take a selector consisting of a privilege name or a privilege-level name.

Thus, each can be set once for each possible privilege and once for each possible privilege level. If a username has a given privilege or is at a given privilege-level then that limit applies. When using the Command Interface if you do not specify a selector when changing the limit or exemptions your change applies to all privileges and privilege levels.

Limits

Constraint Value Default
ABSOLUTLO 0---n 30
ABSOLUTHI 0---n 90 or 30 or 0*

* 30 for levels above Category-Normal, 0 for explicit privileges.

Exemptions

Constraint Value Parameters
ABSOLUTLO 0---n <node>, <username>
ABSOLUTHI 0---n <node>, <username>

Practical considerations

If password lifetimes are too long, exposure from a compromise is increased. If password lifetimes are too short, users take short cuts in choosing new passwords.

Note

1 Usernames with just NETMBX and TMPMBX will be treated as non-privileged.

PWDMINLEN

Ensure that individual usernames have acceptable minimum password lengths.

Violation reports

Constraint Nature of the violation
ABSOLUTLO Lower than minimum in the policy
ABSOLUTHI Higher than maximum in the policy

Description

If passwords are too short, they can be easily guessed. The system User Authorization File (SYSUAF) specifies for each username the minimum password length which can be used by that user for either the primary or secondary password (if any) using the SET PASSWORD command.

The purpose of this test is to ensure that the minimum length established for each user complies with organization-wide security policy. This test compares that value for each authorized username against each privilege-related limit set in the policy. This test is not performed for usernames with null passwords.

Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

Default policy

The minimum password length must be at least 6 for non-privileged accounts and 8 for privileged accounts 1. This corresponds to the values initially established by DEC for existing accounts when the minimum password length feature was introduced in VMS V4.0.

By default, the minimum password length cannot exceed 14. The reasoning is that very high minimum password lengths encourage users to write down passwords

Customizing

The default policy above is set by using both privileges and privilege levels, so if you relax a privilege limit you will need to relax a privilege level limit as well in order to achieve the desired effect. selector Limits and exemptions for this test can take a selector consisting of a privilege name or a privilege-level name.

Thus, each can be set once for each possible privilege and once for each possible privilege level. If a username has a given privilege or is at a given privilege-level then that limit applies. When using the Command Interface if you do not specify a selector when changing the limit or exemptions your change applies to all privileges and privilege levels.

Limits

Constraint Value Default
ABSOLUTLO 0---31 6 or 8*
ABSOLUTHI 0---31 14

* Higher value for levels above Category-Normal.

Exemptions

Constraint Value Parameters
ABSOLUTLO 0---31 <node>, <username>
ABSOLUTHI 0---31 <node>, <username>

Practical considerations

Excessive length requirements for passwords can encourage users to write them down, which leads to poor security.

Note

1 Usernames with just NETMBX and TMPMBX will be treated as non-privileged.

PWDMIX

Determine whether the presence or absence of permission to use mixed case passwords conforms to policy.

Violation reports

Constraint Nature of the violation
PROHIBITED Mixed case passwords are enabled in violation of policy
REQUIRED Mixed case passwords are disabled in violation of policy

Description

The tests for this element determine whether enabling of mixed case passwords for a user conforms to policy.

Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

Default policy

Enabling mixed case passwords is neither prohibited nor required

Customizing

Some external authorities require the use of mixed case passwords

Selector

Limits

Constraint Value Default
PROHIBITED FALSE or TRUE FALSE
REQUIRED FALSE, TRUE or TRY FALSE

Exemptions

Constraint Value Parameters
PROHIBITED FALSE or TRUE <node>, <username>
REQUIRED FALSE, TRUE or TRY <node>, <username>

Practical considerations

The security enhancement afforded by mixed case passwords is not even close to that provided by robust smart tokens.

Previous Next Contents Index