topic Re: Weak Password Testing in Operating System - OpenVMS

Weak Password Testing

djk — Tue, 24 Mar 2009 21:20:44 GMT

I need to verify that VMS user passwords are not too weak and create a security vulnerability. My companies audit group suggest using a Password Scanning/Cracking program that will detect weak user passwords.

The UAF parameters are setup for min length, etc to ensure pwd rules are enforced but I still need to conduct a test to verify good pwd security.

I am looking for suggestions from others who have have processes in use to verify that user passwords are appropriately structured to ensure strong pwd security.

Re: Weak Password Testing

John Gillings — Tue, 24 Mar 2009 23:03:05 GMT

djk,

There are enough hooks in OpenVMS to allow you to insert your own, arbitrary policies to test for password strength.

Remember, by default VMS imposes length and basic substring checks for username and node name and checks against the password dictionary (which you are free to extend or replace - see SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA), .

There are probably password scan/crack utilities around, but they tend to be extremely resource heavy, because the only feasible mechanism is brute force. I doubt anyone in this forum would make one available in response to a random query. There are security implications!

A much simpler mechanism would be to implement a password policy module to apply whatever policy your audit group require, then expire all users passwords. Next time they login, they will be forced to update their password to conform with the new policies.

If you search this forum for "VMS$PASSWORD_POLICY" you should be able to find a copy of an example program (I posted a MACRO32 example a while back).

Re: Weak Password Testing

djk — Tue, 24 Mar 2009 23:17:46 GMT

Thanks for response. Your suggestions are good and offer good control on the front end. What I need is the ability to "test" the control to prove to the audit group no weak pwd's exist (even though there shouldn't be because of the front end control).

Re: Weak Password Testing

Andy Bustamante — Wed, 25 Mar 2009 00:32:27 GMT

VMS has intrusion detection and blocking enabled by default. From the VMS Guide to System Security at http://h71000.www7.hp.com/doc/732final/aa-q2hlg-te/aa-q2hlg-te.html

The operating system is sensitive to login failures. Afterone failure, it begins to monitor the terminal, terminal serverconnection, or network connection where the login is taking place.At first, the operating system records unsuccessful logins in anintrusion database. As failures continue, the operating system not onlyrecords failures but takes restrictive measures. The person attemptinglogin is monitored more closely and limited to a certain numberof login retries within a limited period of time. Once a personexceeds either the retry or time limitation, he or she cannot login for a while, even with a valid user name and password. At a laterpoint, the restriction eases, and login is allowed once again.

You'll need to disable intrusion detection while any password scan is running. As far as running the scan, perhaps your auditors can provide a utility. Of course disabling intrusion detection may be an issue in later audits.

One low cost quick to deploy option may be to use a terminal emulation package with scripting support. Kermit comes to mind. There are consultants to found, some will be following up in this thread.

Andy

Re: Weak Password Testing

Hein van den Heuvel — Wed, 25 Mar 2009 01:25:14 GMT

Andy>> You'll need to disable intrusion detection while any password scan is running.

Nah, leave it on! It is on right? Only fair.

I would explain the password rule already in place, and then have `them' explain how that is not good enough, and how they propose to test to their satisfaction. No handwaving. Have `them' be specific to their (perceived?) needs and then set out to honor those. Surely `they' are not going to just accpet a test you and I dream up no?
Make the requiremenents specific: interactive, network, oracle, attunity, MQ,..

I suspect more than 1/2 of the ( non-generated ) passwords in this world are weak, in the sense that they encorprate a predictable sequence based on the last password.
You tell me the number in the prior password, and I can predict the next password :-(. You can easily extend OpenVMS to protect against that, using the new-password intercept John referred to. Just take the new password, and try to validate it against the current password 2*N times where N is the number of characters provided. For eacht character try once try the value one lower, and once the value one lower. Watch in horror? No matter how 'strong' the password looks, if it is based on the prior, then it is weak.

Good luck!
Hein.

Re: Weak Password Testing

Hoff — Wed, 25 Mar 2009 01:48:45 GMT

Details on password filter and password weakness tools.

http://64.223.189.234/node/643
http://64.223.189.234/node/229
http://64.223.189.234/node/526

Re: Weak Password Testing

John Gillings — Wed, 25 Mar 2009 01:58:49 GMT

djk,

> What I need is the ability to "test" the
>control to prove to the audit group no
>weak pwd's exist

Given the set of "weak" passwords is near enough to infinite for practical purposes, "proving" no weak passwords exist is theoretically impossible. What is "their" criteria for such a test to succeed? Will they provide the set of weak passwords to test for? Why not just add them to the password dictionary?

You could perform a dictionary attack against a particular user, but from the outside (by default), you'd only get only five attempts before the system ignored you and locked itself down in intrusion mode. Then you have to wait an hour or two until the intrusion detection settled. Furthermore the login sequence is deliberately slow, so you're looking at geologic time frames to test each user!

From a privileged account you could avoid intrusion detection, and speed up your tests by running each test password through the password hash algorithm and comparing with the stored hash. This is potentially much faster, but remember it still needs to be done for each user, as the hashing algorithm has a "salt" value to make sure the same password doesn't hash to the same value for different users. You could speed things up a bit by removing all the words from the standard password dictionary from your test dictionary.

I think there was a utility that was supposed to do something like this a few years ago (was it "John the Ripper"?), but from memory it didn't work very well, and I doubt anyone else has been bothered to create one that works properly because it's rather pointless, except perhaps as an exercise in using system services.

Re: Weak Password Testing

Jon Pinkley — Wed, 25 Mar 2009 03:51:08 GMT

As long as you have all accounts set up with /flags=(NODISPWDDIC,NODISPWDHIS) and you haven't weakened the password dictionary, or reduced the time before passwords can be reused, about the only thing that guessing passwords will find are passwords that have been entered by privileged users at the UAF prompt, which bypasses any history or dictionary lookups. In other words, if user JOEKID has /PWDMINIMUM=8 /FLAGS=(NODISPWDDIC,NODISPWDHIS), a privileged user can still use the following command to change the password to "SECRET", even though it isn't allowed by the password dictionary and does not meet the minimum password length.

$ mcr authorize modify joekid/pass=secret/nopwde

You can detect these changes with authorization auditing, but there are other ways that privileged users can modify passwords without the changed showing up in audit journal as an authorization event.

If you want to detect all password changes, you could take a periodic snapshot of the SYSUAF file and have a program compare the password and salt fields to see if they had changed, and then verify that there are audit records for the changed passwords.

If you want to find passwords, methods other than brute force guessing are probably easier. Social engineering, looking under people's keyboards, in their top shelf, on their calendar or sticky notes will probably yield more than a brute force scan of the SYSUAF file. If telnet or ftp is being used, WireShark or easily found password sniffing programs are the easiest way.

Procedures to attempt to guess passwords, in my opinion, do more to provide a false sense of security than to actually improve it.

If truly strong passwords are enforced, the likelihood of finding passwords written (in easily found locations) increases.

In summary, you can put great lock on a screen door, but it doesn't provide much real protection.

Just my opinion.

Jon

Re: Weak Password Testing

Jur van der Burg — Wed, 25 Mar 2009 07:59:35 GMT

A quick and dirty check can be done by using the program that is used during vms installation, something like this:

$ if f$search("sys$update:vms$chkpwd.exe") .nes. ""
$ then
$ mcr sys$update:vms$chkpwd 'pwd'
$ savestat = $status
$ if .not. savestat then goto again
$ endif

Jur.

Re: Weak Password Testing

Peter Weaver_1 — Wed, 25 Mar 2009 19:52:12 GMT

Do a search for John the Ripper with the OpenVMS parts done by Jean-loup Gailly. It compares passwords against a large list of common passwords.

Jean-loup had executables for VAX and Alpha on his site, but you can also copy the SYSUAF.DAT to a Windows or Linux and run the program there.

If you try John the Ripper you will probably be very shocked at how quickly you find passwords.

Re: Weak Password Testing

John Gillings — Wed, 25 Mar 2009 21:21:30 GMT

just to clarify Jur's post, SYS$UPDATE:VMS$CHECKPWD checks a string to see if it passes some VERY basic tests. It doesn't appear to consult the password dictionary, or even minimum length rules.

Based on my simple experiments I wouldn't trust it for anything serious:

$ mcr sys$update:vms$chkpwd password
%SYSTEM-E-PWDWEAK, password is too easy to guess; please choose another string
$ mcr sys$update:vms$chkpwd test
%SYSTEM-E-PWDWEAK, password is too easy to guess; please choose another string
$ mcr sys$update:vms$chkpwd secret
$ mcr sys$update:vms$chkpwd aaa
$ mcr sys$update:vms$chkpwd aa
$ mcr sys$update:vms$chkpwd a

It might be interesting if anyone with access to the sources can post exactly what this program does. From its size, and behaviour, I suspect not much!

Re: Weak Password Testing

Hein van den Heuvel — Wed, 25 Mar 2009 22:05:13 GMT

John is correct. It is a trivial test. I happened to look at its listing a few weeks back. It tests for a few dynamic strings, (username, username reversed, nodename,..) and simple list of suspect password words:

Hein

$ strings sys$update:vms$chkpwd
ELF
ALPHA
ALPHAVMS
BRATWURST
EVAX
EVMS
FIELDSERVICE
MANAGER
MANAGERS
SYSMANAGER
SYSMANAGERS
PANCAKES
PASSWORD
PRIMARY
SERVICE
SECONDARY
UETP
USER
VAXVMS
WILLIWAW
ZIRHUMBA
DEFAULT
DIGITAL
FIELD
PCSI
SPIA
SYSTEM
TEST
OPENVMS
SYSTEST
SYSTEST_CLIG
BACKUP
PASSWORD

Re: Weak Password Testing

Jon Pinkley — Wed, 25 Mar 2009 22:44:47 GMT

I suppose we should then make sure that the VMS password dictionary has all the words that John the Ripper tries...

Has anyone actually done a comparison?

I just did a search of SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA;1 for "ABC123" and that isn't there, so I assume there are probably other "commonly used passwords" that aren't in the stock dictionary.

Jon

Re: Weak Password Testing

Peter Weaver_1 — Thu, 26 Mar 2009 00:03:25 GMT

> I suppose we should then make sure that the VMS password dictionary has all the words that John the Ripper tries...
>
>Has anyone actually done a comparison?

Back when I first heard of John the Ripper I added all the words to the data file and I modified VMS$PASSWORD_POLICY to do some of the other checks that John did. It did not take me very long, a couple of hours at most. But the people I did the work for decided that the VMS systems were far enough behind the firewalls to not worry about. That company doesn't really exist anymore.

Re: Weak Password Testing

Hoff — Thu, 26 Mar 2009 01:24:45 GMT

The password dictionary article, including how to use dictionaries to extend the password dictionary:

http://64.223.189.234/node/1223

Re: Weak Password Testing

Hoff — Thu, 26 Mar 2009 13:00:45 GMT

ps: consider acquiring a heap or three of your site-specific and local document files and text databases, and pull all of the words out of those, eliminate the duplicates, and use the results as site-local additions to the dictionary.

This might seem silly, but it's a common technique used by an attacker. The generic defensive dictionaries invariably miss the site-local terms and acronyms, which means that they're potentially in play as passwords.

Re: Weak Password Testing

Richard W Hunt — Fri, 03 Apr 2009 13:56:27 GMT

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.

Re: Weak Password Testing

Galen Tackett — Mon, 06 Apr 2009 10:55:45 GMT

Testing for weak passwords:

Using your best "coach voice" tell the password, "OK, password, gimme 50," and see how many push ups it can do. You could also make the password do some chin ups as an extra level of testing for weakness.

:-)

Re: Weak Password Testing

Hein van den Heuvel — Mon, 06 Apr 2009 16:10:02 GMT

Richard, super writeup. Well done.

If I were to support a password module for a customer, then I would add one more test:

Look for any number character in the NEW password, add one and try against the old password, also subtract one and try.
If any of those work as prior password, then return and error and send an Email reminder to go spank the user with a wet noodle or two. Clearly one-on-one education about the intent of the passwords requirements is required for such case.

fwiw,
Hein.

Re: Weak Password Testing

AEFAEF — Tue, 07 Apr 2009 16:02:41 GMT

A lot of emphasis on complexity here. But it seems to me that requiring multiple character sets doesn't help nearly as much as increased length. Especially case. You don't gain much with case sensitivity compared to increased length. Check the number of possible passwords: X^L. L buys you a lot more than X. (X is number of characters, L is length.) [As an aside: Imagine if your check bounced because you used the wrong case!}

See

http://www.infoworld.com/d/security-central/password-size-does-matter-531

http://www.infoworld.com/d/security-central/win-money-and-books-cracking-my-windows-password-hashes-277

I suppose that complexity issues such as repeated characters, anagrams, company names, and history and such, are still helpful. But multiple requiring character sets seems counterproductive to me. They're too predictable and many users will use the "obvious" format of "Ulower#," for their passwords. I don't think it's very helpful to require this kind of complexity, esp. as it increases the odds that the password will be written down on a post-it note.

Stratus VOS has some interesting options that can be added to what has already been discussed here:

-forbid_vowels: yes/no
-forbid_repeating_chars: yes/no
-forbid_user_name: yes/no
-forbid_repeat_password: yes/no
-forbid_frequent_changes: yes/no
-num_hours_between_changes: 24
-forbid_passwords_in_table: yes/no
-forbid_reverse: yes/no
-forbid_anagram: yes/no
-req_alpha_numeric: yes/no
-forbid_begin_end_numeric: yes/no

(I've changed all the yes/no values to "yes/no".)

Thoughts? Comments?

AEF