Discussion:
VMS humor
Add Reply
Michael Moroney
2020-12-29 22:49:20 UTC
Reply
Permalink
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
John Reagan
2020-12-30 05:08:12 UTC
Reply
Permalink
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
On x86, it will be harder to pronounce:

$ set password/generate=16/algo=mixed
Old password:

knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0

Choose a password from this list, or press RETURN to get a new list
Phillip Helbig (undress to reply)
2020-12-30 06:38:10 UTC
Reply
Permalink
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
Für Information über Risiken und Nebenwirkungen, fragen Sie Ihren Arzt
oder Apotheker.
V***@SendSpamHere.ORG
2020-12-30 13:25:07 UTC
Reply
Permalink
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Jan-Erik Söderholm
2020-12-30 12:37:14 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
It has been a long time since users only kept passwords in their memory.

Most applications (maybe more browsers then terminal emulators)
today has the option to save the login data. It is uncommon today
that you are forced to remember your passwords yourself.
V***@SendSpamHere.ORG
2020-12-30 17:45:49 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by V***@SendSpamHere.ORG
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
It has been a long time since users only kept passwords in their memory.
Most applications (maybe more browsers then terminal emulators)
today has the option to save the login data. It is uncommon today
that you are forced to remember your passwords yourself.
The VMS terminal driver will be modified to remember your cryptic password?
Oh, the security.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Dave Froble
2020-12-30 17:35:01 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by Jan-Erik Söderholm
Post by V***@SendSpamHere.ORG
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
It has been a long time since users only kept passwords in their memory.
Most applications (maybe more browsers then terminal emulators)
today has the option to save the login data. It is uncommon today
that you are forced to remember your passwords yourself.
The VMS terminal driver will be modified to remember your cryptic password?
Oh, the security.
How about having your terminal emulator keep usernames and passwords?

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2020-12-30 23:42:02 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by Jan-Erik Söderholm
Post by V***@SendSpamHere.ORG
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
It has been a long time since users only kept passwords in their memory.
Most applications (maybe more browsers then terminal emulators)
today has the option to save the login data. It is uncommon today
that you are forced to remember your passwords yourself.
The VMS terminal driver will be modified to remember your cryptic password?
Oh, the security.
Of course not!

It is up to the application doing the login. Such as a terminal emulator
or a browser.
Phillip Helbig (undress to reply)
2020-12-31 08:15:12 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
It has been a long time since users only kept passwords in their memory.
Most applications (maybe more browsers then terminal emulators)
today has the option to save the login data. It is uncommon today
that you are forced to remember your passwords yourself.
True, if you work from one access point. But that is then a single
point of failure. An alternative is some sort of password safe with a
master password. But if that is local, again a single point of failure
(except perhaps if running on a distributed VMS cluster) and if not, you
have to trust the platform where it is hosted.
John Reagan
2020-12-30 14:52:15 UTC
Reply
Permalink
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
I encourage that. Hard to guess passwords are keeping the hackers in remote locations
from hacking into your machine. Write it down and stick it to your monitor. If you are in my
house, I've got bigger problems as you can grab the machine and leave (along with my
checkbook, passport, etc.). I use both a password manager on my phone and I literally have
a spreadsheet sitting next to me. If you can remember you password, it is too easy to guess.
Craig A. Berry
2020-12-30 16:21:23 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
And goes against current NIST guidelines for long, easy-to-remember
passwords that do not routinely expire. Of course most auditors go by
what NIST said a decade or two ago, so a lot of folks won't have any
choice about following older practices.
John Reagan
2020-12-31 01:53:09 UTC
Reply
Permalink
Post by Craig A. Berry
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
And goes against current NIST guidelines for long, easy-to-remember
passwords that do not routinely expire. Of course most auditors go by
what NIST said a decade or two ago, so a lot of folks won't have any
choice about following older practices.
Easy-to-remember and high entropy don't mix.

Here's the section from the latest NIST 800-63B https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

5.1.1.2 Memorized Secret Verifiers

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15]. This process is applied before hashing the byte string representing the memorized secret. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully.

Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters in length and SHALL be generated using an approved random bit generator [SP 800-90Ar1].

Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

Passwords obtained from previous breach corpuses.
Dictionary words.
Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter [Meters], to assist the user in choosing a strong memorized secret. This is particularly important following the rejection of a memorized secret on the above list as it discourages trivial modification of listed (and likely very weak) memorized secrets [Blacklists].

Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.

The verifier SHALL use approved encryption and an authenticated protected channel when requesting memorized secrets in order to provide resistance to eavesdropping and MitM attacks.

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack. The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185]. The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output.

The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each subscriber using a memorized secret authenticator.

For PBKDF2, the cost factor is an iteration count: the more times the PBKDF2 function is iterated, the longer it takes to compute the password hash. Therefore, the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.

In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret

And Appendix A

Appendix A—Strength of Memorized Secrets

This appendix is informative.

Throughout this appendix, the word “password” is used for ease of discussion. Where used, it should be interpreted to include passphrases and PINs as well as passwords.

A.1 Introduction

Despite widespread frustration with the use of passwords from both a usability and security standpoint, they remain a very widely used form of authentication [Persistence]. 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 [Policies], although the impact on usability and memorability is severe.

Complexity of user-chosen passwords has often been characterized using the information theory concept of entropy [Shannon]. While entropy can be readily calculated for data having deterministic distribution functions, estimating the entropy for user-chosen passwords is difficult and past efforts to do so have not been particularly accurate. For this reason, a different and somewhat simpler approach, based primarily on password length, is presented herein.

Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones. These attacks are outside the scope of this Appendix.

A.2 Length

Password length has been found to be a primary factor in characterizing password strength [Strength] [Composition]. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.

The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted. In order to prevent an attacker (or a persistent claimant with poor typing skills) from easily inflicting a denial-of-service attack on the subscriber by making many incorrect guesses, passwords need to be complex enough that rate limiting does not occur after a modest number of erroneous attempts, but does occur before there is a significant chance of a successful guess.

Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.

Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.

A.3 Complexity

As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification.

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.

Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets.

A.4 Randomly-Chosen Secrets

Another factor that determines the strength of memorized secrets is the process by which they are generated. Secrets that are randomly chosen (in most cases by the verifier or CSP) and are uniformly distributed will be more difficult to guess or brute-force attack than user-chosen secrets meeting the same length and complexity requirements. Accordingly, at LOA2, SP 800-63-2 permitted the use of randomly generated PINs with 6 or more digits while requiring user-chosen memorized secrets to be a minimum of 8 characters long.

As discussed above, the threat model being addressed with memorized secret length requirements includes rate-limited online attacks, but not offline attacks. With this limitation, 6 digit randomly-generated PINs are still considered adequate for memorized secrets.
A.5 Summary

Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.
John Reagan
2020-12-31 06:29:31 UTC
Reply
Permalink
Post by John Reagan
Post by Craig A. Berry
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
And goes against current NIST guidelines for long, easy-to-remember
passwords that do not routinely expire. Of course most auditors go by
what NIST said a decade or two ago, so a lot of folks won't have any
choice about following older practices.
Easy-to-remember and high entropy don't mix.
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits. You seem to have missed some of the most
"Verifiers SHOULD NOT impose other composition rules (e.g., requiring
mixtures of different character types or prohibiting consecutively
repeated characters) for memorized secrets. Verifiers SHOULD NOT require
memorized secrets to be changed arbitrarily (e.g., periodically)."
"Length and complexity requirements beyond those recommended here
significantly increase the difficulty of memorized secrets and increase
user frustration. As a result, users often work around these
restrictions in a way that is counterproductive."
So, as I said, the "harder to pronounce" generated passwords that we'll
apparently get with x86 VMS are pretty much what everyone else has been
doing but directly contradict current NIST recommendations.
The phrase "King Philip fried a pheasant on Friday!" is 7 words out of a dictionary full of words.
The distribution is quite predictable as each English word (yes, there are a few exceptions known
to Scrabble players) contains at least one vowel. How did you determine 189?

I'm not in the XKCD camp and fall in with Steve Gibson.

https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength


You can pick the old style as well.

$ set pass /generate=16 /algorithm=alphabetic
Old password:

heabneyssiontenvok
gatotormedickings
housesupsystraste
alietesciabatter
satubmunhastonal

Choose a password from this list, or press RETURN to get a new list
New password:

And "correcthorsebatterystaple" now has an entropy of 1 bit.
Phillip Helbig (undress to reply)
2020-12-31 08:26:17 UTC
Reply
Permalink
Post by John Reagan
And "correcthorsebatterystaple" now has an entropy of 1 bit.
Right. But, of course, that was just an example.

It has shown up in breaches, along with bigtits and abc123.
Jan-Erik Söderholm
2020-12-31 11:58:54 UTC
Reply
Permalink
Post by John Reagan
Post by John Reagan
Post by Craig A. Berry
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
And goes against current NIST guidelines for long, easy-to-remember
passwords that do not routinely expire. Of course most auditors go by
what NIST said a decade or two ago, so a lot of folks won't have any
choice about following older practices.
Easy-to-remember and high entropy don't mix.
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits. You seem to have missed some of the most
"Verifiers SHOULD NOT impose other composition rules (e.g., requiring
mixtures of different character types or prohibiting consecutively
repeated characters) for memorized secrets. Verifiers SHOULD NOT require
memorized secrets to be changed arbitrarily (e.g., periodically)."
"Length and complexity requirements beyond those recommended here
significantly increase the difficulty of memorized secrets and increase
user frustration. As a result, users often work around these
restrictions in a way that is counterproductive."
So, as I said, the "harder to pronounce" generated passwords that we'll
apparently get with x86 VMS are pretty much what everyone else has been
doing but directly contradict current NIST recommendations.
The phrase "King Philip fried a pheasant on Friday!" is 7 words out of a dictionary full of words.
The distribution is quite predictable as each English word (yes, there are a few exceptions known
to Scrabble players) contains at least one vowel. How did you determine 189?
I'm not in the XKCD camp and fall in with Steve Gibson.
https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
You can pick the old style as well.
$ set pass /generate=16 /algorithm=alphabetic
heabneyssiontenvok
gatotormedickings
housesupsystraste
alietesciabatter
satubmunhastonal
Choose a password from this list, or press RETURN to get a new list
And "correcthorsebatterystaple" now has an entropy of 1 bit.
About login in general...

My customer has implemented MFA on all logins to the corporate
environment that, apart from the usual password, requires you to
select one the four MFA methods below.

Notification on authenticator app
Verification code on authenticator app
SMS to phone
Call to phone

(I currently use the SMS method.)

Has there been any investigations of integration of MFA in/from VMS?
V***@SendSpamHere.ORG
2020-12-31 14:35:01 UTC
Reply
Permalink
{...snip...}
Notification on authenticator app
Verification code on authenticator app
SMS to phone
Call to phone
(I currently use the SMS method.)
Has there been any investigations of integration of MFA in/from VMS?
I did this very thing for a company about a year and a half ago. Emailed or
SMS texted 2FA code.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Phillip Helbig (undress to reply)
2020-12-31 17:03:52 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
My customer has implemented MFA on all logins to the corporate
environment that, apart from the usual password, requires you to
select one the four MFA methods below.
Notification on authenticator app
Verification code on authenticator app
SMS to phone
Call to phone
(I currently use the SMS method.)
Has there been any investigations of integration of MFA in/from VMS?
One could put something in SYS$SYLOGIN to send an SMS (many providers
have an email address to which one can send a message which will be
forwarded as SMS) then READ/PROMPT= or whatever.
Jan-Erik Söderholm
2020-12-31 20:16:36 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
My customer has implemented MFA on all logins to the corporate
environment that, apart from the usual password, requires you to
select one the four MFA methods below.
Notification on authenticator app
Verification code on authenticator app
SMS to phone
Call to phone
(I currently use the SMS method.)
Has there been any investigations of integration of MFA in/from VMS?
One could put something in SYS$SYLOGIN to send an SMS (many providers
have an email address to which one can send a message which will be
forwarded as SMS) then READ/PROMPT= or whatever.
No, not at all. One do not want a VMS-local-specific solution. One want
to connect to the corporate MFA solution, whatever that is, so that you
one can use the same MFA infrastructure as used for everything else.

Like the integrations for LDAP and Kerberos.
Craig A. Berry
2020-12-31 18:02:55 UTC
Reply
Permalink
Post by John Reagan
The phrase "King Philip fried a pheasant on Friday!" is 7 words out of a dictionary full of words.
The distribution is quite predictable as each English word (yes, there are a few exceptions known
to Scrabble players) contains at least one vowel.
But unless the entire phrase is in someone's password cracking
dictionary, the fact that portions contain well-known words doesn't
really make any difference, does it? If it did, delimiting with
non-space characters would take care of that.
Post by John Reagan
How did you determine 189?
I did a quick web search and found this:

<http://rumkin.com/tools/password/passchk.php>

which is also something the XKCD entry below points to.
Post by John Reagan
I'm not in the XKCD camp and fall in with Steve Gibson.
https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
The point of that is that length works better than funny characters at
increasing entropy. Which was essentially my point as well.
Some Dude
2020-12-31 20:26:50 UTC
Reply
Permalink
Post by Craig A. Berry
But unless the entire phrase is in someone's password cracking
dictionary, the fact that portions contain well-known words doesn't
really make any difference, does it? If it did, delimiting with
non-space characters would take care of that.
Nope. Sophisticated attacks use dictionary tokens just the same as individual letters or symbols.

Also most attacks against a compromised authorization file start with a giant database of previously-obtained password hits under the theory that there might be user overlap with a previously-compromised account and that people are lazy.
Craig A. Berry
2021-01-01 15:33:59 UTC
Reply
Permalink
Post by Some Dude
Post by Craig A. Berry
But unless the entire phrase is in someone's password cracking
dictionary, the fact that portions contain well-known words doesn't
really make any difference, does it? If it did, delimiting with
non-space characters would take care of that.
Nope. Sophisticated attacks use dictionary tokens just the same as
individual letters or symbols.
OK. I am not a cryptographer but since the number of words in the
dictionary is much larger than the number of letters in the alphabet,
and they would have to guess the sequence, position, capitalization, and
delimiters between tokens, and could not assume that all tokens are
valid dictionary words (especially not in the same language), would an
8-word sentence not increase the cost of a correct guess well beyond
that of a random sequence of 8 characters?
Post by Some Dude
Also most attacks against a compromised authorization file start with
a giant database of previously-obtained password hits under the
theory that there might be user overlap with a previously-compromised
account and that people are lazy.
All the more reason to have people make up their own phrase or short
sentence of nonsense that will be memorable to them but unlikely to
appear in one of these databases.
Stephen Hoffman
2021-01-01 17:36:48 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Some Dude
Post by Craig A. Berry
But unless the entire phrase is in someone's password cracking
dictionary, the fact that portions contain well-known words doesn't
really make any difference, does it? If it did, delimiting with
non-space characters would take care of that.
Nope. Sophisticated attacks use dictionary tokens just the same as
individual letters or symbols.
That's true for *shorter* passwords. Out in the range we're discussing,
that becomes untenable.
Post by Craig A. Berry
OK. I am not a cryptographer but since the number of words in the
dictionary is much larger than the number of letters in the alphabet,
and they would have to guess the sequence, position, capitalization,
and delimiters between tokens, and could not assume that all tokens are
valid dictionary words (especially not in the same language), would an
8-word sentence not increase the cost of a correct guess well beyond
that of a random sequence of 8 characters?
Ayup. Longer passwords take (far) longer to brute-force. If you're
stuck without a password manager as is the case here, longer and
memorable wins over shorter and line noise.

Attempting to brute-force past 12 characters or so is less than
feasible on a reasonable timescale with current hardware, outside of
the lists of the (tens of thousands) most common passwords, and close
dictionary matches from same. And that brute-forcing with longer
passwords involves a whole-password mix, and not a partial match.

There are various write-ups of the complexity involved for folks
considering this XKCD-style multi-word password attack, here's one from
the folks fond of the Hashcat tool:
https://hashcat.net/forum/thread-9307-post-49206.html#pid49206

For this case, I'd prefer a diceware password, and not line noise. If I
need a line-noise password, I can get that from my own password
generator.

Multi-factor authentication is another feature that various sites are
starting to or do require, as well. With OpenVMS, that's probably
easiest with the assistance of an LDAP password server, though there
are some add-ons for OpenVMS that allow that locally, whether that via
key-fob or app or otherwise.
Post by Craig A. Berry
Post by Some Dude
Also most attacks against a compromised authorization file start with a
giant database of previously-obtained password hits under the theory
that there might be user overlap with a previously-compromised account
and that people are lazy.
All the more reason to have people make up their own phrase or short
sentence of nonsense that will be memorable to them but unlikely to
appear in one of these databases.
Ayup.

For those using macOS, here's the arcana necessary to enable use of
Keychain for ssh passphrases: https://apple.stackexchange.com/a/250572
Some additional background on keypairs and usage with macOS:
https://rderik.com/blog/understanding-ssh-keys-and-using-keychain-to-manage-passphrase-on-macos/


Don't us your personal or family or company slogan, or words or phrases
related to your job, either. Best to add those words to the password
filter, along with one of the common password lists.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2021-01-01 19:50:35 UTC
Reply
Permalink
Post by Stephen Hoffman
Attempting to brute-force past 12 characters or so is less than
feasible on a reasonable timescale with current hardware, outside of
the lists of the (tens of thousands) most common passwords, and close
dictionary matches from same. And that brute-forcing with longer
passwords involves a whole-password mix, and not a partial match.
If I were trying to crack a typically constrained password, I would
replace 1 with l, 0 with o, and if I crack it, in 90 days increment the
number by 1. :-)
John Reagan
2021-01-01 20:16:53 UTC
Reply
Permalink
https://www.hivesystems.io/blog/are-your-passwords-in-the-green
Arne Vajhøj
2021-01-03 00:52:39 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Craig A. Berry
But unless the entire phrase is in someone's password cracking
dictionary, the fact that portions contain well-known words doesn't
really make any difference, does it? If it did, delimiting with
non-space characters would take care of that.
Nope.  Sophisticated attacks use dictionary tokens just the same as
individual letters or symbols.
OK. I am not a cryptographer but since the number of words in the
dictionary is much larger than the number of letters in the alphabet,
and they would have to guess the sequence, position, capitalization, and
delimiters between tokens, and could not assume that all tokens are
valid dictionary words (especially not in the same language), would an
8-word sentence not increase the cost of a correct guess well beyond
that of a random sequence of 8 characters?
Yes. 8 English words is better than 8 random characters.

But 8 random characters is way better than English words with 8 characters.

If one assume that real range is 7 bit in random characters and 2 bits
in English words characters, then a sequence of English words should
be 3.5 times as long as random characters to provide equivalent
security.

I very much prefer the English words approach, but it has to be
a pretty long sentence.

Arne
Some Dude
2021-01-03 18:04:25 UTC
Reply
Permalink
Post by Arne Vajhøj
Yes. 8 English words is better than 8 random characters.
For VMS prior to V8.5, it would have to be 8 short words since the max password length is 32 in most places.

For V9.x, the supported length should be 64 at a minimum but there are issues with access software that still thinks 32 is the max. For those of you kicking the tires on X86, the longer password support is not yet enabled.
Post by Arne Vajhøj
I very much prefer the English words approach, but it has to be
a pretty long sentence.
And if you have PWDMIX set, it doesn't have to be only English words. If you can type it (and it's not a line control character/terminator) then you can use it in you password. There may still be issues with space and tab in passwords.

--D

John Reagan
2020-12-31 21:34:23 UTC
Reply
Permalink
Post by Craig A. Berry
Post by John Reagan
The phrase "King Philip fried a pheasant on Friday!" is 7 words out of a dictionary full of words.
The distribution is quite predictable as each English word (yes, there are a few exceptions known
to Scrabble players) contains at least one vowel.
But unless the entire phrase is in someone's password cracking
dictionary, the fact that portions contain well-known words doesn't
really make any difference, does it? If it did, delimiting with
non-space characters would take care of that.
Post by John Reagan
How did you determine 189?
<http://rumkin.com/tools/password/passchk.php>
which is also something the XKCD entry below points to.
Post by John Reagan
I'm not in the XKCD camp and fall in with Steve Gibson.
https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
The point of that is that length works better than funny characters at
increasing entropy. Which was essentially my point as well.
Yes, length matters. According to https://www.security.org/how-secure-is-my-password/
one the 16-char line-noise passwords would take 41 trillion years to brute force. Your "King Philip..."
phrase would take 2 octodecillion years to brute force (but I suspect that website didn't realize
that the passphrase was a sequence of concatenated words found in a dictionary).
Richard Maher
2021-01-03 01:15:07 UTC
Reply
Permalink
Post by Craig A. Berry
Post by John Reagan
The phrase "King Philip fried a pheasant on Friday!" is 7 words out
of a dictionary full of words. The distribution is quite
predictable as each English word (yes, there are a few exceptions
known to Scrabble players) contains at least one vowel.
But unless the entire phrase is in someone's password cracking
dictionary, the fact that portions contain well-known words doesn't
really make any difference, does it? If it did, delimiting with
non-space characters would take care of that.
Post by John Reagan
How did you determine 189?
<http://rumkin.com/tools/password/passchk.php>
which is also something the XKCD entry below points to.
Post by John Reagan
I'm not in the XKCD camp and fall in with Steve Gibson.
https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
The point of that is that length works better than funny characters
at increasing entropy. Which was essentially my point as well.
FIDO2
Simon Clubley
2021-01-01 03:28:04 UTC
Reply
Permalink
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits. You seem to have missed some of the most
What happens when culture gets in the way ?

For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Chris Townley
2021-01-01 10:13:56 UTC
Reply
Permalink
Post by Simon Clubley
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits. You seem to have missed some of the most
What happens when culture gets in the way ?
For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?
Simon.
But don't you need a false French accent?


Chris
Craig A. Berry
2021-01-01 20:21:30 UTC
Reply
Permalink
Post by Simon Clubley
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits.
What happens when culture gets in the way ?
In the way of what?
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?
If there is a cultural reference in there, I'm missing it. In any case,
I just don't understand what your question is.
Phillip Helbig (undress to reply)
2021-01-02 09:51:30 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Simon Clubley
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits.
What happens when culture gets in the way ?
In the way of what?
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?
If there is a cultural reference in there, I'm missing it. In any case,
I just don't understand what your question is.
I'm also still confused.

Perhaps "culture" means that "To be, or not to be" has low entropy,
whereas "koppen ist on the tafeltje" has higher entropy. In general, a
phrase in an obscure language might be better, and in some mixture of
languages even better.

As to the quote, that might refer to the practice of setting the initial
password to "secret" then telling the user that "the password is secret"
and laugh while waiting for him to figure it out. :-)
Bill Gunshannon
2021-01-02 13:04:48 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Craig A. Berry
Post by Simon Clubley
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits.
What happens when culture gets in the way ?
In the way of what?
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?
If there is a cultural reference in there, I'm missing it. In any case,
I just don't understand what your question is.
I'm also still confused.
Perhaps "culture" means that "To be, or not to be" has low entropy,
whereas "koppen ist on the tafeltje" has higher entropy. In general, a
phrase in an obscure language might be better, and in some mixture of
languages even better.
As to the quote, that might refer to the practice of setting the initial
password to "secret" then telling the user that "the password is secret"
and laugh while waiting for him to figure it out. :-)
You mean like at "The Doors of Durin"?

bill
Bob Eager
2021-01-02 13:27:44 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Simon Clubley
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits.
What happens when culture gets in the way ?
In the way of what?
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I
shall say this only once" ?
If there is a cultural reference in there, I'm missing it. In any case,
I just don't understand what your question is.
It's a British and (arguably) French cultural reference. A short Google
will inform you.
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
Craig A. Berry
2021-01-02 14:39:14 UTC
Reply
Permalink
Post by Bob Eager
Post by Craig A. Berry
Post by Simon Clubley
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits.
What happens when culture gets in the way ?
In the way of what?
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I
shall say this only once" ?
If there is a cultural reference in there, I'm missing it. In any case,
I just don't understand what your question is.
It's a British and (arguably) French cultural reference. A short Google
will inform you.
OK, so it is a well-known sentence for watchers of a particular TV show:

<https://en.wikipedia.org/wiki/List_of_%27Allo_%27Allo!_characters#Michelle_Dubois>

Obviously, don't use a well-known phrase or sentence: make up your own
nonsense phrase. Or better yet have your password generator give you a
truly random sequence of four words as XKCD recommended.
Bob Eager
2021-01-02 16:22:56 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Bob Eager
Post by Craig A. Berry
Post by Simon Clubley
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits
of entropy compared to 72 bits.
What happens when culture gets in the way ?
In the way of what?
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I
shall say this only once" ?
If there is a cultural reference in there, I'm missing it. In any case,
I just don't understand what your question is.
It's a British and (arguably) French cultural reference. A short Google
will inform you.
<https://en.wikipedia.org/wiki/List_of_%27Allo_%27Allo!
_characters#Michelle_Dubois>
Post by Craig A. Berry
Obviously, don't use a well-known phrase or sentence: make up your own
nonsense phrase. Or better yet have your password generator give you a
truly random sequence of four words as XKCD recommended.
I use five real dice, and the improved dicewords:

https://en.wikipedia.org/wiki/Diceware
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
Simon Clubley
2021-01-02 14:49:12 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Simon Clubley
Yes, they most certainly do. "King Philip fried a pheasant on Friday!"
is much easier to remember than "ud58{>!1&R17h7uo" and has 189 bits of
entropy compared to 72 bits.
What happens when culture gets in the way ?
In the way of what?
Of producing enough entropy from the phrase.

How much is the entropy reduced by when the phrase is also a cultural
reference ?
Post by Craig A. Berry
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?
If there is a cultural reference in there, I'm missing it. In any case,
I just don't understand what your question is.
It's from a BBC comedy series. Very well known here in the UK and elsewhere.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Andy Burns
2021-01-02 13:40:17 UTC
Reply
Permalink
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?
You only have to type "listen v" into google for their
suggest-as-you-type to get it ... so maybe 40 bits?
Simon Clubley
2021-01-02 14:52:03 UTC
Reply
Permalink
Post by Andy Burns
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?
You only have to type "listen v" into google for their
suggest-as-you-type to get it ... so maybe 40 bits?
Interesting, I wasn't aware of that.

I happen to have Javascript turned off when using Google so I never
see any auto-complete suggestions so that didn't occur to me to try.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Craig A. Berry
2021-01-02 15:25:02 UTC
Reply
Permalink
Post by Andy Burns
Post by Simon Clubley
For example, how much entropy is there in "Listen very carefully, I shall
say this only once" ?
You only have to type "listen v" into google for their
suggest-as-you-type to get it ... so maybe 40 bits?
I have a hard time seeing how an autocomplete mechanism has anything to
do with how a password guesser works. As far as I know the latter is
all or nothing and it would never know it got the first word right, thus
narrowing further choices.
Andy Burns
2021-01-02 15:48:46 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Andy Burns
You only have to type "listen v" into google for their
suggest-as-you-type to get it ... so maybe 40 bits?
I have a hard time seeing how an autocomplete mechanism has anything to
do with how a password guesser works.  As far as I know the latter is
all or nothing and it would never know it got the first word right, thus
narrowing further choices.
Depends who's doing the guessing, if I shoulder-surf you typing a
password, and think I see you typing "listen v" then I might well try
the whole phrase, a password cracking computer probably wouldn't, even
though google shows that some computers do associate "listen v" with the
whole phrase ...
Phillip Helbig (undress to reply)
2020-12-31 08:18:28 UTC
Reply
Permalink
Post by Craig A. Berry
And goes against current NIST guidelines for long, easy-to-remember
passwords that do not routinely expire. Of course most auditors go by
what NIST said a decade or two ago, so a lot of folks won't have any
choice about following older practices.
Exactly. Most of the old rules caused people to break others, and the
latter was much worse.

Longer is stronger.

It should be easy for humans to remember and difficult for brute-force
attacks.

If it is compromised, it needs to be changed. If not, it doesn't.
People won't remember it changing it every day. Any damage that can be
done can be done within a day.

So the standard: mixed case, letters and numbers, special characters,
change it every 90 days is about the worst you can do.
Phillip Helbig (undress to reply)
2020-12-31 08:13:35 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by John Reagan
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
Longer is stronger.

There is a great xqcd cartoon on that topic.

The more rules there are---mixed case, letters and number, special
characters---the fewer combinations one has to try. Longer passweords
without the gobbledygook are easier for people to remember but harder
for computers to guess. People just don't get it.
V***@SendSpamHere.ORG
2020-12-31 14:22:14 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by V***@SendSpamHere.ORG
Post by John Reagan
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
And harder to remember! That'll insure that the user records their
password somewhere besides in their memory.
Longer is stronger.
There is a great xqcd cartoon on that topic.
https://xkcd.com/936/
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Some Dude
2020-12-31 20:54:31 UTC
Reply
Permalink
Post by John Reagan
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
$ set password/generate=16/algo=mixed
knE~yAZ7dv=K]+Ui
3t;yh58-6T1[Oa7;
40Ie652I[6xlW3Yl
ud58{>!1&R17h7uo
dRcp7Se{'8^1<mK0
Choose a password from this list, or press RETURN to get a new list
The "line noise" password generator comes with the Enhanced Password Management patch for earlier versions. If PWDMIX is set for the account. SET PASSWORD/GENERATE will default to "line noise" and use the previous alphabetic one if PWDMIX is clear. The password changes include allowing alphabetic generation up to 32 characters although the algorithm sometimes breaks down past 25 characters or so and will not always produce 5 choices. X86 will continue to include SYS$FORGE_WORD-generated passwords.

The example policy module included with the Enhanced Password Management kit supports both strict rules (at least one upper case, one lower case, one sad emoji and the name of your favorite astronaut) and the better method of "must contain n categories" where the example defines upper, lower, numeric, and special characters as categories. The policy module is supplied in C source form for folks to modify. This would allow a SMOP to produces a sliding category rule such as "24 or more characters no category requirements, 16-23 - any 2 categories, below 16 - any 3 categories."
Phillip Helbig (undress to reply)
2020-12-30 06:37:03 UTC
Reply
Permalink
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
Does anyone wonder what the people who wrote the VMS password generator
were smoking? :=)

-------------------------------------------------------------------------------
There are two major products that come out of Berkeley: LSD and UNIX. We don't
believe this to be a coincidence.

---Jeremy S. Anderson
John Reagan
2020-12-30 14:54:07 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Michael Moroney
Does anyone else wonder if the drug manufacturers use the VMS password
generator to name new drugs? :-)
Does anyone wonder what the people who wrote the VMS password generator
were smoking? :=)
-------------------------------------------------------------------------------
There are two major products that come out of Berkeley: LSD and UNIX. We don't
believe this to be a coincidence.
---Jeremy S. Anderson
An an April Fools hack, I've suggested that we seed that generator with IKEA product names.
Loading...