- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Weak Password Testing
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2009 02:21 PM
тАО03-25-2009 02:21 PM
Re: Weak Password Testing
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2009 03:05 PM
тАО03-25-2009 03:05 PM
Re: Weak Password Testing
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2009 03:44 PM
тАО03-25-2009 03:44 PM
Re: Weak Password Testing
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2009 05:03 PM
тАО03-25-2009 05:03 PM
Re: Weak Password Testing
>
>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2009 06:24 PM
тАО03-25-2009 06:24 PM
Re: Weak Password Testing
http://64.223.189.234/node/1223
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-26-2009 06:00 AM
тАО03-26-2009 06:00 AM
Re: Weak Password Testing
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-03-2009 06:56 AM
тАО04-03-2009 06:56 AM
Re: Weak Password Testing
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-06-2009 03:55 AM
тАО04-06-2009 03:55 AM
Re: Weak Password Testing
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.
:-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-06-2009 09:10 AM
тАО04-06-2009 09:10 AM
Re: Weak Password Testing
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-07-2009 09:02 AM
тАО04-07-2009 09:02 AM
Re: Weak Password Testing
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