Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

OpenVMS Password Encryption and FIPS Compliance

Richard Mansfield
Occasional Visitor

OpenVMS Password Encryption and FIPS Compliance

I'm trying to determine if the password hashing functions in OpenVMS are FIPS 140-2 approved. I reviewed the hash information on the HP website (http://h71000.www7.hp.com/doc/732FINAL/4527/4527pro_005.html) and noted that OpenVMS use Purdy hash. Unfortunately, I can't find any information showing that this hashing function has been approved by NIST.

I reviewed the validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules website (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm) and didn't see a direct reference to Purdy or OpenVMS password encryption.

Can someone tell me if the OpenVMS hash (Purdy) is FIPS approved?

And, is there a FIPS approved alternative for OpenVMS?


Thanks in advance,

Rich M
3 REPLIES
Hoff
Honored Contributor

Re: OpenVMS Password Encryption and FIPS Compliance

These sorts of questions are best routed directly to HP Business Management, as you're almost certainly looking for an official statement.

There is a subtle but important distinction here: OpenVMS does not encrypt its password. Encrypting a password is not what you want; if you can't decrypt it, you can't expose it. OpenVMS uses a cryptographic hash function.

As for your literal question, AFAIK, no, the hash is not on the list of NIST hashes. But for what purpose are you seeking this? Is this an administrative standards-compliance "rock-fetch", or are you protecting nuclear secrets here? The passwords themselves are usually a bigger risk. (If folks are poking around inside SYSUAF, you're already scrod.) And AFAIK, the Purdy is still difficult to reverse.

http://csrc.nist.gov/groups/ST/hash/index.html

NCSC certainly looked at the Purdy scheme as part of the Class C2 and Class B1 security evaluations for specific OpenVMS versions. Further, the password protection here is two-fold. The secondary protection is the hash, and the primary protection is that the SYSUAF file itself is protected against access.

It's feasible to roll your own authentication and your own password hash, though you'll break anything that is using commonly-available HPWD sources and Perl modules. And you can also run a password filter and break-in evasion, which will reduce your exposure to dictionary attacks.

As for reversing it, brute-force attacks can be feasible. John the Ripper is an oft-cited option, though it requires read access to SYSUAF.

Here is some related reading material:

http://portal.acm.org/citation.cfm?id=361089&dl=GUIDE&coll=GUIDE&CFID=36704998&CFTOKEN=58570644

http://www.mail-archive.com/cryptography@metzdowd.com/msg08261.html

As for other options, you could use Kerberos-based external authentication. The use of passwords in general should be addressed long before the hash. There are other and bigger holes that you'll need to plug first, if you're seriously looking at these sorts of details.

Do talk with HP directly for the official answer. One of the most senior business managers over there is very familiar with security.

Stephen Hoffman
HoffmanLabs LLC


Wim Van den Wyngaert
Honored Contributor

Re: OpenVMS Password Encryption and FIPS Compliance

Highlighted
Richard W Hunt
Valued Contributor

Re: OpenVMS Password Encryption and FIPS Compliance

A greater issue of concern (at least at my site, which is Dept. of Navy), is TELNET.

We got no hiccups over the Purdy-S algorithm. That part of our SSAA documentation sailed right through. For the folks not fluent in USA-Gov-Speak, SSAA = System Security Architecture Approval document, or some such silly acronym. But to get the SSAA finalized, we were required to implement SSH logins. It is OK that they use passwords.

SSH protects that login from casual spying even if all you have is the password. With SSH via passwords, we will be "UTM PROTECT" compliant. Don't know if that acronym would be meaningful to a non-Navy person. Heck, it doesn't mean that much to me; just another hurdle to leap while maintaining some semblance of my stride.

It also helps that you use a terminal emulator that is FIPS-140-2 compliant. There are several. Not advertising here, but we use Attachmate's Reflections package for Windows. Works OK and the SSAA doesn't barf on that package either. I'm sure that others exist. That's just the one that I have experience in using, and I know it works.
Sr. Systems Janitor