Skip to ContentSkip to Footer
Start of content
- Community Home
- >
- Servers and Operating Systems
- >
- Operating System - OpenVMS
- >
- OpenVMS Password Encryption and FIPS Compliance
Operating System - OpenVMS
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
-
- Forums
-
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
- HPE Blog, Austria, Germany & Switzerland
- Blog HPE, France
- HPE Blog, Italy
- HPE Blog, Japan
- HPE Blog, Middle East
- HPE Blog, Russia
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
-
Blogs
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Blog, Latin America
- HPE Blog, Middle East
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
-
Information
- Community
- Welcome
- Getting Started
- FAQ
- Ranking Overview
- Rules of Participation
- Tips and Tricks
- Resources
- Announcements
- Email us
- Feedback
- Information Libraries
- Integrated Systems
- Networking
- Servers
- Storage
- Other HPE Sites
- Support Center
- Aruba Airheads Community
- Enterprise.nxt
- HPE Dev Community
- Cloud28+ Community
- Marketplace
-
Forums
-
Blogs
-
Information
-
English
Topic Options
- 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
- Email to a Friend
- Report Inappropriate Content
07-14-2008 05:22 AM
07-14-2008 05:22 AM
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
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
- Tags:
- encryption
- Password
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-14-2008 06:10 AM
07-14-2008 06:10 AM
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-14-2008 06:16 AM
07-14-2008 06:16 AM
Re: OpenVMS Password Encryption and FIPS Compliance
And a previous discussion
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1155683
Wim
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1155683
Wim
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
10-17-2008 04:54 AM
10-17-2008 04:54 AM
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.
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
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
End of content
United States
Hewlett Packard Enterprise International
Communities
- Communities
- HPE Blogs and Forum
© Copyright 2021 Hewlett Packard Enterprise Development LP