- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: OpenVMS Password Encryption and FIPS Complianc...
Operating System - OpenVMS
1748019
Members
4423
Online
108757
Solutions
Forums
Categories
Company
Local Language
юдл
back
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
юдл
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
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
- 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
- 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
- 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
- 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.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP