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:
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 CTTS1) (1961 to 1973), Multics2) (from 1964, latest release in 2016, the direct ancestor of Unix), WAITS3) (mid-1960s to 1991), ITS4) (late 1960s to 1995), TOPS-10 and TOPS-205) (1967-69 to present as TOPS hobbyist licenses; see also TENEX and TWENEX), and others6) 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,7) 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ó8) 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.,9) with a crypt10) utility based on the m-209 cipher machine. Both Morris and Dennis Ritchie11) were able to demonstrate how to break crypt, both by hand and automated methods.12) 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,13) a seminal paper on passwords entitled “Password Security: A Case History.”14) In an ironic twist of fate, Morris’s son, Robert Jr.,15) unleashed the first “Internet Worm”16) 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:
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 value18) for that password (string of characters, concatenated with a “salt”19) value (to guarantee the uniqueness of that hash value); “salting” a password string helps defend it against both dictionary attacks20) and rainbow-table attacks.21)
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 Purdy22) polynomial23), 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 vulnerable24) 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 authorization25) 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:
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.26)
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 CEOs27) all scrambled to either ensure that their companies were invulnerable to attack,28) or to contain the damage to reputation if they’d been hacked,29) 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:
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:
Just google “worst passwords 201X” (e.g., 2017, 2018, etc.) for full lists of popular but really bad passwords.31)
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):32)
And (in previous years):
…plus too many banks33) and financial institutions34) 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…35)
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,36) along these attack vectors:
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:
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:
…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 recommendations37) 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:
“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]
Elsewhere, NIST concurs with industry experts’ long-standing recommendations:
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-”
/PWDEXPIRED to above to force that user to actually recompose and reset a new password according to these new length and