07-14-2008 05:22 AM
I reviewed the validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules website (http://csrc.nist.gov/groups/STM/cmvp/documents/140
Can someone tell me if the OpenVMS hash (Purdy) is FIPS approved?
And, is there a FIPS approved alternative for OpenVMS?
Thanks in advance,
07-14-2008 06:10 AM
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.
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:
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.
10-17-2008 04:54 AM
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.