Weak Password Testing

[djk]

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.

[John Gillings · Accepted solution]

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

[djk]

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

[Andy Bustamante]

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

[Hein van den Heuvel]

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.

[Hoff]

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

[John Gillings]

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.

[Jon Pinkley]

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

[Jur van der Burg]

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.

[Peter Weaver_1]

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.