OpenVMS Password Encryption and FIPS Compliance

[Richard Mansfield]

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

[Hoff]

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]

And a previous discussion
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1155683

Wim

[Richard W Hunt]

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.