I'm at a USA Dept. of Defense site and trust me, my government managers are so overboard on the paranoia scale as to make Batman's friend the Joker look sane. I've got them satisfied after a LOT of hard work. Here's what I had to do, not necessarily in any order.
First, I implemented a password policy module. It's not that hard - look at SYS$EXAMPLES for a couple of example modules named VMS$PASSWORD_POLICY. You have two entry points for functions that return a status code. A hash entry and a cleartext entry. Your inbound parameters are, for the hashed entry, a username by descriptor and a quadword-by-reference of the hash code. For the plaintext entry, two strings by descriptor of the username and actual input password. When you implement this, OpenVMS calls your entry points for each attempt to change a password. NOT for each use of an existing password. ONLY for changes of passwords.
You don't need to do anything for the policy_hash function entry point except return SS$_NORMAL as a status. I've yet to figure out why ANYONE would want to look at the hash code for anything. If the PURDY_S algorithm is in use, then any value of the hash is equally possible and equally valid - if you use PWD_MINIMUM as something other than zero.
For the policy_plaintext function entry, you only need to scan, categorize, and count character classes. For me, classes were uppercase, lowercase, digit, and punctuation characters. Define lower limits for each to whatever is the site policy, and then if the string doesn't meet criteria, return an error code of SS$_PWDWEAK (= %x0E7A if you want it as -E- severity.)
While I was working on this little jewel, I also checked for a minimum password age, which is another DOD requirement. You build a SYS$GETUAI call to include UAI$_PWD_DATE and UAI$_FLAGS. Get back those two values.
If the user has the PwdMix flag set, require the complexity as noted above. If not (which for me occurs as a public-key-only login case), you don't care about the passwords 'cause they never get used, so just return SS$_NORMAL and go away.
For the password date, which is a quadword, get the current time of day. For the high-order quad-time components only, subtract the password change date from the current time of day. Ignore the low-order date portion.
If the two dates differ in the high-order longword of the date-quad by less than 201 (decimal) then the password is less than about 24 hours old. (OK, if you do the math, the exact number is 23:58:48.84 old). Reject it because it is too young. I returned an error of SS$_PWDSYNTAX for this one rather than try to define my own system error code, but I made the module write a message to SYS$OUTPUT saying "password too young" so the user understood what was going on with that.
OK, using the standard password and other security thingies, I set the SYSGEN LGI stuff like this: LGI_PWD_TMO 30, _RETRY_LIM 3, _RETRY_TMO 20, BRK_LIM 3, _BRK_TMO 3600, HID_TIM 1800. My site also requires me to set LGI_BRK_DISUSER to 1, which I hate but cannot prevent.
Then for each user you set their minimum password size to at least two more characters than the sum of the minimum requirements for complexity. We have a requirement for 2 each of the four classes, so my min password is 10 - and if the user is privileged at all, we up that to 14. Max password age for my site is 60 days, per DoD requirements.
Here's a crazy thought, and it doesn't matter really, but if you implement password complexity, you don't need the password dictionary for those accounts - because I guarantee you that the passwords won't be in the dictionary. But password history still makes sense. I computed the numbers and set these system-wide logicals:
SYS$PASSWORD_HISTORY_LIFETIME = "305" and SYS$PASSWORD_HISTORY_LIMIT = "50" - which effectively prevents password churning, the technique whereby someone resets a password often enough to push old passwords out of the history list so he can reset his favorite password.
Now, the $64,000 question: How do you know that someone doesn't have a weak password right now? Answer: You cannot tell without more trouble than it is worth. The only thing you can see after-the-fact is the hashed password. You can get the hash quadword with a SYS$GETUAI function. You can then do repeated probes by calling function SYS$HASH_PASSWORD with the appropriate parameters for the given user, including their username, SALT value, the algorithm code, and the password you wanted to compare against the stored password hash.
I.e. You have a hash, you take your "weak" password and compute a hash for that user. Compare the hashes. If they match, the user MIGHT have a weak password. However, since the hash output by SYS$HASH_PASSWORD depends on three user-specific parameters, you have to repeat this probe once for each user for each "weak" password you wanted to test. That very quickly mounts up based on the size of the "weak" password list.
So here is how you assure that you have no weak passwords.
First, implement the password policy module, assert all users to have the PWDMIX flag and the minimum password size according to site policy.
The password policy module requires you do define the location of the module with a system-wide logical VMS$PASSWORD_POLICY = "{location/name of module}}" - by default, SYS$LIBRARY:VMS$PASSWORD_POLICY.EXE You also have to do something with SYSGEN at system startup - you use the ACTIVE parameters (NOT the CURRENT ones) and use SET LOAD_PWD_POLICY 1, then WRITE ACTIVE.
You must install the policy module, THEN define the system-level pointer, THEN update the SYSGEN parameter - in that order.
Next, send out a warning regarding password policy issues and immediately expire all user passwords.
Now, run a report after a few days showing those users who have updated their passwords since the policy module went into effect. Those folks DO NOT have weak passwords. Everyone else? Their passwords are expired. They won't log in until they reset their passwords - with the policy module in place.
Now, having done the above, you can honestly report to the big bosses that nobody has any weak passwords. Sound like a lot of work? Yep, you got it right. But it meets DoD specs in every way.
Sr. Systems Janitor
