Considered by many to be “that old legacy operating system,” VMS pioneered many security-oriented design approaches, technologies, methodologies, and practices – its foundations are strong. In many ways, it has earned its reputation as “unhackable”. However, VMS has not seen much security update activity since the mid-1990s, so it earns and deserves some constructive criticism in the face of contemporary security issues and threats. This document will examine and discuss:

• VMS password technology, including what's good/strong, and what needs improvement.
• Well-respected industry IT security experts views of passwords and associated security policies.
• NIST (and other) official password guidelines, both past (discredited) and current (revised for the better).
• PARSEC's Password Policy software product, including new features/updates which comply with latest NIST security recommendations.
• VMS break-in detection and evasion, why this makes VMS hacker-resistant.
• The UIC-based security model, why and how this works.
• VMS Security Auditing, making it work for you.
• Network security on VMS.

This is an honest assessment and survey of VMS security features…

VMS (then “VAX/VMS”, not yet “OpenVMS”) was conceived, designed and imple-mented in the mid-1970s, a time very different from the “now” of the 2000-teens, with very different attitudes, expectations and assumptions about “computing,” including operating systems environments, and especially about “security.”

In particular, computer security was hardly even a topic in the 1960s and ‘70s, when the prevailing attitude was all about information sharing, and everything about the young-but-upcoming operating systems like Unix encouraged that. These attitudes and expectations came naturally from historical OS antecedents like CTTS¹⁾ (1961 to 1973), Multics²⁾ (from 1964, latest release in 2016, the direct ancestor of Unix), WAITS³⁾ (mid-1960s to 1991), ITS⁴⁾ (late 1960s to 1995), TOPS-10 and TOPS-20⁵⁾ (1967-69 to present as TOPS hobbyist licenses; see also TENEX and TWENEX), and others⁶⁾ circa the 1960s and early ‘70s.

An awful lot of computing innovation, development growth and sophistication happened during that decade-and-a-half. And although these OS environments included elements of file access/security, and even (in most cases) password-secured logins, the emphasis in those days was on information (files and data) sharing among academics and research folks.

Especially in university computing environments, passwords were viewed with distrust and, in some places and by certain hackers,⁷⁾ with outright hatred, subversion and rebellion. The norm was open access, and passwords just got in the way.

Networking too was in its most preliminary phases of development — an experimental glimmer in a visionary’s eye — during those times as well. Today’s Internet did not come about until over two decades later, although the seminal ideas of file transfers (sharing) and remote logins were basic realities. In particular, network security attacks and black-hat crackers were nowhere on anyone’s mind, but a distant and dim possibility in those early days.

In business, commerce and industry — always more formal and stuffy than early computer science academia, even without actual reasons for being so — this was the environment where early notions of security actually took root, star¬ting with passwords and stronger notions of sign-on or login identity. The invention of the “first password” (a working implementation thereof) is attributed to computer scientist Fernando José “Corby” Corbató⁸⁾ and his team when they worked on the CTSS operating system in the early 1960s.

Early password implementations (including mainframes) stored passwords in plain text, relying on a file’s access control to “protect” the password/user data¬base. The first hashed password implementation was developed in the early 1970s, by Robert Morris Sr.,⁹⁾ with a crypt¹⁰⁾ utility based on the m-209 cipher machine. Both Morris and Dennis Ritchie¹¹⁾ were able to demonstrate how to break crypt, both by hand and automated methods.¹²⁾ The utility was soon replaced by the crypt C-library function, which proved to be somewhat more robust in its time.

In 1979, Morris coauthored, with Ken Thompson,¹³⁾ a seminal paper on passwords entitled “Password Security: A Case History.”¹⁴⁾ In an ironic twist of fate, Morris’s son, Robert Jr.,¹⁵⁾ unleashed the first “Internet Worm”¹⁶⁾ on an unsuspecting early Internet over a decade later, on November 2nd, 1988.

Unix adopted secure, hashed passwords (based on Morris’s crypt) in the 6th Edition, 1974. Unix hackers (the good guys) grudgingly began accepting passwords as a necessary evil, a new way of life. By the time Linux was invented (1992), passwords were an ordinary thing, the normal way of “logging in.”

Passwords were not an afterthought, or a “bolt-on,” for VMS — security has been considered “baked into” (designed into) VMS from its earliest days. Version 1.0 was released with usernames and passwords as the normal way of identifying and authorizing user logins:

• Username ― A unique name for a VMS user account, consisting of from 1 to 12 alphanumeric characters (“$” and “_” also permitted), all letters are uppercase, must include at least one alphabetical character (although all-numeric usernames like “123456” are supported, they are discouraged because a Rights Identifier cannot be associated with an all-numeric username).

• Password ― A string of from 0 to 32 characters A..Z, 0..9, $_. Traditionally, all lowercase characters entered as a password are converted to uppercase; also, the minimum password length has been 6 characters from the earliest days. Unfortunately, for many VMS users (and event for sys-admins), that minimum 6-char length has also become the default or norm, misunderstood as “VMS passwords are six characters long.”¹⁷⁾

With VMS v7.3-2 (mid-1990s), lowercase letters for passwords became available, so the password character repertory expanded to a..z, A..Z, 0..9, $_, plus “special characters” (this was never well-defined by enumeration, but includes the usual suspects like !@#$%^& and likely a few more ― some documentation includes the phrase “including almost every printing character”). To enable this larger lower/uppercase character set for a user account, that account is modified to use the /FLAG=PwdMix flag.

VMS does not store the users’ passwords in “clear text” ― Instead, when a user enters his/her new password with the SET PASSWORD command (or the sys-admin sets the user’s password using the AUTHORIZE MODIFY username /PASSWORD command), VMS computes a hash-function value¹⁸⁾ for that password (string of characters, concatenated with a “salt”¹⁹⁾ value (to guarantee the uniqueness of that hash value); “salting” a password string helps defend it against both dictionary attacks²⁰⁾ and rainbow-table attacks.²¹⁾

It is the hash value (plus the salt) that is stored as part of the user’s authorization record in the SYSUAF.DAT file. Since the hash calculation is a one-way function (cannot be “easily” reversed or undone to reveal the original password string), even system administrators with VMS privileges cannot “see” or decrypt any users’ passwords ― thus, when a user loses or forgets their own password, the sys-admin can only help them replace it with a new, pre-expired password, and then the user must reset their own private, secret password with the SET PASSWORD command.

VMS password secrecy was based on the Purdy²²⁾ polynomial²³⁾, which at the time (1970s-80s) was considered secure enough for federal government/DARPA use. With the passage of several decades, in the 2000-teens, that hash algorithm is known to be rather vulnerable²⁴⁾ to contemporary power-hacks (brute-force password derivations), and is in need of improvement or replacement by stronger con-temporary hash functions ― likely two/multi-factor authorization²⁵⁾ is ultimately the way to go for the future of VMS (and other systems).

Even so, since its earliest days (1970s), OpenVMS has enjoyed a well-deserved reputation for:

• Security, as a built-in (not half-baked add-on) design.
• Login break-in/intrusion detection and evasion.
• Strong user authorization by password.
• Strong access control to files and other system objects mediated by UIC and Rights Identifiers.
• Unhackability, earned in trials-by-fire at various security symposium and conventions (e.g., the Black-Hat Conferences of the late 1990s and early 2000s).

Unfortunately, at this remove, there’s a tendency for VMS advocates to rest on their laurels.

In the 2000-teens, VMS is as vulnerable as any other operating system environment to security breaches by aggressive and determined attackers, malicious state agents and other black hats.²⁶⁾

VMS systems now live and function in a much more complex business environment than existed in the 1970s and ‘80s. The infrastructure is now highly connected, both with internal/local networks (LANs) and external connections (the Internet), including sophisticated, but complicated (and sometimes buggy), protections such as firewalls, VPNs, VLANs, SSL/TSL, security certificates, trust inheritance, and more.

In the face of growing concerns and legal liabilities over system data breaches, starting to be serious in the 1990s and early 2000s, a “conventional wisdom” posing as a “security best practice” arose globally throughout the IT industry. Much of that best practice wisdom has turned out to be mythology and false preconception about how things “ought to be.”

And as CTOs, CIOs, CSOs and CEOs²⁷⁾ all scrambled to either ensure that their companies were invulnerable to attack,²⁸⁾ or to contain the damage to reputation if they’d been hacked,²⁹⁾ much of that conventional wisdom became entrenched and calcified as “Corporate Security Policy.”

Unfortunately, once thus enshrined, such mythology has become intractably difficult to update in the light of current and objective facts about passwords and their practical use.

Seeking a silver-bullet to indemnify and inoculate themselves and their companies against security breaches, executives and corporate security committees have carved these principles into their Security Policies:

• Make passwords complicated, complex and hard to remember.³⁰⁾
• Make rules, enforced if possible by software, which requires users to create and use complex passwords.
• Make users change their passwords every N-days, where “N” is chosen rather arbitrarily by committee, usually 30, 45, 60 or 90 days.
• Imply that users are responsible for system security, especially via their own passwords.

However, in practice, those rules made things worse, not better.

All of these rules were codified by the National Institute of Standards and Techno-logy (NIST) in its 2003 document “NIST Special Publication 800-63”. In an appendix, the document specified that passwords should be created as awkward, arbitrary strings of characters rife with obscure characters, capital letters in a landscape of lowercase, and numbers, sometimes substituting “3” for “E”, “1” for “I”, “5” for “S”, and other nonsense; and then to change them ― the passwords ― regularly.

All for naught. Users ― ordinary people ― cannot remember or enter such complicated passwords, and naturally look for ways to “beat the system” in creating easy(er)-to-remember-and-type passwords that barely complied with these mandates. Hence, passwords like the following became common:

• password1
• Pa55w0rd
• 123456 (or 12E456 or 12E4S6)
• querty

Just google “worst passwords 201X” (e.g., 2017, 2018, etc.) for full lists of popular but really bad passwords.³¹⁾

Furthermore, many users ― suffering from understandable password overloads ― routinely reuse insecure passwords over and over for online accounts, including their financial/banking “secure” accounts, and for internal corporate logins (like Unix, Linux and VMS systems). Password reuse is, of course, a Very Bad Thing.

During all of this, users were being warned about identity theft, and that their personal, private data ― including passwords ― have already been stolen, and are in the hands of bad-guy/black hats worldwide. The incredulous, sensationalist and gullible global news has media reported data theft breaches at (for example, just in 2018 alone):³²⁾

• Adidas, Arby’s, Best Buy, Delta Airlines, KMart, Panera Bread, Saks Fifth Avenue, Sears, Sonic, and Whole Foods.

And (in previous years):

• Adobe Systems, Ameritrade, Ancestry.com, AOL (multiple times), Apple, AT&T (twice), ADP, Barnes & Noble, CardSystems Solutions Inc., CVS, Dropbox, Dun & Bradstreet, eBay, Experian, Facebook (multiple), Google Plus, Hewlett Packard, Home Depot, Hyatt Hotels, the IRS, LexisNexis, LinkedIn, Michaels, Monster.com, Mozilla, NASDAQ, Natural Grocers, Network Solutions, US Office of Personal Management, Quora, Scottrade, SnapChat, Sony (various divisions), Starbucks, Texas Lottery, T-Mobile, Trump Hotels, Twitter, Uber, UPS, US DoD, Verizon, Walmart, Wendy’s, Yahoo, and Zappos.

…plus too many banks³³⁾ and financial institutions³⁴⁾ to even begin to mention. Oh, and lots of universities, and lots of hospitals and medical centers. And plenty of US and worldwide government organizations. …And counting…³⁵⁾

Of course, “the users” often got the blame, for “…failing to use sufficiently strong [that is, complex] passwords.” What does all of this have to do with VMS?

Most data breaches are internal,³⁶⁾ along these attack vectors:

• “Disgruntled” (mad at employer) employee or ex-employee, or one with an actual criminal intent, and legitimate inside access.
• External black-hat using social engineering through naive but otherwise innocent employees who do have legitimate access.
• External black-hat masquerading as a legitimate insider, say, a contractor, consultant or service provider (think “construction crew member”).
• Non-employee insider with access (think “janitor/cleaning staff”, “fire safety inspector,” “security consultant”(!), etc.) ― anyone who can promote and gain unescorted, unsupervised internal access.

Most data breaches are at least started by non-technical, non-sophisticated means, although once system access has been breached, the actual exfiltration of valuable corporate and/or customer data is often enabled by technology (USB memory sticks, writable CD or DVD, network data transfers, email, etc.). Too many innocent junior staff, secretaries, receptionists and executive assistants have been “sweet-talked” by socially skillful bad-guys (posturing as “really good guys”) into handing over or revealing passwords and other information which can be leveraged into system access.

“But our systems are all internal, protected by our corporate firewall!” Uh-huh. Corporate firewalls are probed for routine, well-known holes, and if found to be “too secure to bother with,” the black hats refocus their attention inside, on the company’s all-too-vulnerable human assets… They “go around the firewall” as soon as it gives them resistance, as the people inside are the really soft targets.

So… If your VMS (or Linux, or Unix, or Windows) system(s) is/are firewall-protected, and “not on the Internet,” well, think again about how vulnerable those systems actually are, and what juicy data-targets they might contain. Your “secure” VMS system(s) are just as much a target for data breaches as any other system in your infrastructure. Since passwords are the first and best line of defense against unauthorized access to whatever data/assets are contained on or controlled by a VMS system, it makes sense to modernize our thinking about old 6-character, all-upper-case VMS passwords as well.

And that (previous pages) is where things stood from the earliest days up until the about 2016. In spite of security rules mandating complex passwords and change-‘em-every-N-days, corporate security breaches keep happening, on an ever-more-frequent and escalating pace.

There have been dissenting voices of real wisdom and bonafide security expertise who have been constructively critiquing the prevalent password security rules over recent years ― these IT security expert individuals include:

• Bruce Schneier, blogging at www.schneier.com. Relevant articles include:
  • Frequent Password Changes Is a Bad Security Idea (https://www.schneier.com/blog/archives/2016/08/frequent_passwo.html)
  • Changes in Password Best Practices (https://www.schneier.com/blog/archives/2017/10/changes_in_pass.html)
  • Stop Trying to Fix the User (https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7676198)
  • Choosing Secure Passwords ― read this one! (https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html)
• Lance Spitzner, Director, SANS Security Awareness:
  • Time for Password Expiration to Die (https://www.sans.org/security-awareness-training/blog/time-password-expiration-die)
• Lorrie Cranor, CTO for the Federal Trade Commission:
  • Frequent password changes are the enemy of security, FTC technologist says (https://arstechnica.com/information-technology/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/)
• Bill Burr, a manager at NIST, responsible for writing the 2003 “NIST Special Publication 800-63. Appendix A.”, the bad and wrong recommendations for passwords which held sway through the first decade of this century. Mr. Burr has since admitted NIST’s overall error: “Much of what I did I now regret…”, he says here: https://www.wsj.com/articles/the-man-who-wrote-those-password-rules-has-a-new-tip-n3v-r-m1-d-1502124118
• Brian Krebs, blogging at KrebsOnSecurity.com ― A voice of calm reason and wisdom.
• Troy Hunt, blogging at troyhunt.com, and creator of the stolen-password resource site HaveIbeenPwned.com ― an invaluable reference site. See also https://en.wikipedia.org/wiki/Have_I_Been_Pwned%3F.

These have been primary, but not the only, voices of reason for password best practices. They have all concurred and agreed:

“Password expiration and complexity rules are not only ineffective, they are counter-productive ― they actually compromise security, leading to worse security outcomes than doing without them.”

Their advice and conclusions are based not on personal ideologies or opinions, but on actual hard facts born out of studies of data/security breaches, human (user) behaviors regarding selection and maintenance of passwords, and actual stolen password corpses (databases).

In 2017, after months of study and revision, the National Institute of Standards and Technology (NIST) completely rewrote, revised and upgraded their “Data Identity Guidelines,” including a complete reversal of their advice for password construction, complexities and expirations ― this is the relevant volume of that extensive documentation:

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf

…and its “Appendix A. Strength of Memorized Secrets” (about passwords) is the most relevant section therein. The NCSC (Great Britain’s National Cyber Security Centre, part of GCHQ) also revised its own recommendations³⁷⁾ nearly simultaneously and in complete agreement.

This Appendix now (in a complete reversal of previous recommendations) stipulates password concepts that are in full harmony and consonance with the long-standing recommendations of Schneier, Cranor, Spitzer, Krebs and Hunt:

• Completely abandon all notions of “password complexity.” Here’s the key quote ― a bit bureaucratic in language, but perfectly understandable:

“Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought…, although the impact on usability and memorability is severe.” [emphasis added]

• Longer is better: “Users should be encouraged to make their passwords as lengthy as they want, within reason.” Non-privileged passwords should be at least 10 characters long, and privileged account passwords should be longer (at least 14-to-16 character minimums).

Elsewhere, NIST concurs with industry experts’ long-standing recommendations:

• Support the use of upper- and lowercase letters, digits and a large repertory of “special” (i.e., punctuation and other printable) characters, possibly even including international, extended character sets (e.g., UCF, UTF-8, etc.). Larger character set repertories are a good thing.
• Teach and support users in the creation of pass-phrases (for example: BigBlueBoat ― but don’t use that one!) to meet secrecy and length guidelines. This encourages avoidance of known-weak and already-stolen passwords, and supports memorability and ability to enter even longer pass-phrases successfully.
• Eliminate any and all requirements for password expirations ― do not require users to regenerate their passwords “every N-days.” As users learn to create longer, memorable, pass-phrases with good password-strength characteristics, allow users to use such passwords indefinitely. A known data breach may be the only justifiable reason to insist on changing/updating passwords.
• Where possible, compare a user’s candidate password (its hash value before accepting it) to a known corpus of stolen, compromised and/or known-weak passwords. Troy Hunt’s password resource site HaveIbeenPwned.com is expressly intended and designed for such comparison use; it contains over 517-million³⁸⁾ known-stolen passwords which must never be used again.

In other words, simply: Long(er) pass-phrases (not -words), use a large® character repertory, and don’t expire ’em.

And although most of this new, revised, improved password advice is focused on online/Internet website accounts (etc.), it is just as applicable to VMS (and other internal &/or legacy) systems security practices as well. For example:

$ mcr authorize
UAF> modify jschmoe /PWDMINIMUM=10 /FLAG=PWDMIX /PWDLIFETIME=”0-”
UAF> modify system /PWDMINIMUM=16 /FLAG=PWDMIX /PWDLIFETIME=”0-”

Add /PWDEXPIRED to above to force that user to actually recompose and reset a new password according to these new length and PwdMix requirements.