| Previous | Contents | Index |
Determine whether password encryption algorithm conforms to policy.
| 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 |
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.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
| 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 |
| 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> |
Possible values include:
Determine whether password expiration conforms to policy.
| Constraint | Nature of the violation |
|---|---|
| NOTICED | Password has expired and been noticed by user |
| NOTNOTICED | Password has expired and not been noticed by user |
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.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
| Constraint | Value | Default |
|---|---|---|
| NOTICED | 0---n (days) | 30 |
| NOTNOTICED | 0---n (days) | 30 |
| Constraint | Value | Parameters |
|---|---|---|
| NOTICED | 0---n (days) | <node>, <username> |
| NOTNOTICED | 0---n (days) | <node>, <username> |
Guess passwords to see if they are too simple.
| Constraint | Nature of the violation |
|---|---|
| TRIES | Guessed in fewer than specified number of tries |
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.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.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.
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.
| Constraint | Value | Default |
|---|---|---|
| TRIES | 0---n | 10 or 100* |
* Higher value for levels above Category-Normal.
| Constraint | Value | Parameters |
|---|---|---|
| TRIES | 0---n | <node>, <username> |
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.
1 Usernames with just NETMBX and TMPMBX will be treated as non-privileged. |
Ensure that individual usernames have acceptable password lifetimes.
| Constraint | Nature of the violation |
|---|---|
| ABSOLUTLO | Lower than minimum in the policy |
| ABSOLUTHI | Higher than maximum in the policy |
The system User Authorization File (SYSUAF) specifies for each username the password lifetime for either the primary or secondary password (if any).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.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.
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.
| 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.
| Constraint | Value | Parameters |
|---|---|---|
| ABSOLUTLO | 0---n | <node>, <username> |
| ABSOLUTHI | 0---n | <node>, <username> |
1 Usernames with just NETMBX and TMPMBX will be treated as non-privileged. |
Ensure that individual usernames have acceptable minimum password lengths.
| Constraint | Nature of the violation |
|---|---|
| ABSOLUTLO | Lower than minimum in the policy |
| ABSOLUTHI | Higher than maximum in the policy |
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.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.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.
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.
| Constraint | Value | Default |
|---|---|---|
| ABSOLUTLO | 0---31 | 6 or 8* |
| ABSOLUTHI | 0---31 | 14 |
* Higher value for levels above Category-Normal.
| Constraint | Value | Parameters |
|---|---|---|
| ABSOLUTLO | 0---31 | <node>, <username> |
| ABSOLUTHI | 0---31 | <node>, <username> |
1 Usernames with just NETMBX and TMPMBX will be treated as non-privileged. |
Determine whether the presence or absence of permission to use mixed case passwords conforms to policy.
| 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 |
The tests for this element determine whether enabling of mixed case passwords for a user conforms to policy.Default policy Enabling mixed case passwords is neither prohibited nor required. Customizing Some external authorities require the use of mixed case passwords. selector
| Constraint | Value | Default |
|---|---|---|
| PROHIBITED | FALSE or TRUE | FALSE |
| REQUIRED | FALSE, TRUE or TRY | FALSE |
| Constraint | Value | Parameters |
|---|---|---|
| PROHIBITED | FALSE or TRUE | <node>, <username> |
| REQUIRED | FALSE, TRUE or TRY | <node>, <username> |
Determine whether use of null passwords conforms to policy.
| Constraint | Nature of the violation |
|---|---|
| CAPTIVE | Null password username is not set as Captive |
| MUSTAUTO | Null password username is not set as autologin-only |
| MUSTLOCK | Null password username does not have password locked |
| PRIMAXPRIV | Maximum privilege category allowed to have a null primary password |
| PRIPROHIB | Has null primary password in violation of policy |
| PRIREQUIRE | Lacks null primary password in violation of policy |
| SECMAXPRIV | Maximum privilege category allowed to have a null secondary password |
| SECPROHIB | Has null secondary password in violation of policy |
| SECREQUIRE | Lacks null secondary password in violation of policy |
Null passwords allow access by unauthorized individuals.Default policy Use of null primary passwords is prohibited. Use of null secondary passwords is required (in other words, secondary passwords are prohibited). Customizing Add exemptions for specific usernames which are to be allowed to have null passwords. selector
| Constraint | Value | Default |
|---|---|---|
| CAPTIVE | Category-None---Category-All | Category-Normal |
| MUSTAUTO | Category-None---Category-All | Category-Normal |
| MUSTLOCK | Category-None---Category-All | Category-Normal |
| PRIMAXPRIV | Category-None---Category-All | Category-Normal |
| PRIPROHIB | FALSE or TRUE | TRUE |
| PRIREQUIRE | FALSE or TRUE | FALSE |
| SECMAXPRIV | Category-None---Category-All | Category-All |
| SECPROHIB | FALSE or TRUE | FALSE |
| SECREQUIRE | FALSE or TRUE | TRUE |
| Constraint | Value | Parameters |
|---|---|---|
| CAPTIVE | Category-None---Category-All | <node>, <username> |
| MUSTAUTO | Category-None---Category-All | <node>, <username> |
| MUSTLOCK | Category-None---Category-All | <node>, <username> |
| PRIMAXPRIV | Category-None---Category-All | <node>, <username> |
| PRIPROHIB | FALSE or TRUE | <node>,<username> |
| PRIREQUIRE | FALSE or TRUE | <node>,<username> |
| SECMAXPRIV | Category-None---Category-All | <node>, <username> |
| SECPROHIB | FALSE or TRUE | <node>,<username> |
| SECREQUIRE | FALSE or TRUE | <node>,<username> |
The %%%MAXPRIV constraints were added to allow support of a privilege-dependent policy for null secondary passwords. As it turns out, the %%%MAXPRIV constraints can accomplish everything done by the %%%PROHIB constraints except for prohibiting null passwords for usernames that have no privileges.
Changing the limit or exemptions to allow use of secondary passwords may lead to a false sense of security by those who do not realize that in the hands of a single individual, a single more obscure password is just as good.
| Previous | Next | Contents | Index |