Small bug in password requirements error message

OpenVMS x86 Field Test questions, reports, and feedback.
Post Reply
User avatar

Topic author
dmjb
Active Contributor
Posts: 49
Joined: Mon Aug 17, 2020 4:38 pm
Reputation: 0
Status: Offline

Small bug in password requirements error message

Post by dmjb » Tue May 09, 2023 7:25 am

On E9.2-1, one of my user accounts passwords expired, and I received the following error for attempting to set too short of a password as a replacement:

Code: Select all

%%%%%%%%%%%  OPCOM   6-MAY-2023 20:23:19.24  %%%%%%%%%%%
Message from user AUDIT$SERVER on VMSX86
Security alarm (SECURITY) and security audit (SECURITY) on VMSX86, system id: 65
534
Auditable event:          Local interactive login failure
Event time:                6-MAY-2023 20:23:19.24
PID:                      00000413
Process name:             SYSTEM
Username:                 SYSTEM
Process owner:            [SYSTEM]
Terminal name:            _OPA0:
Image name:               VMSX86$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Posix UID:                -2
Posix GID:                -2 (%XFFFFFFFE)
Status:                   %SET-E-INVPWDLEN, password length must be between !UB
and 64 characters; password not changed
Note the `password length must be between !UB and 64 characters` in the Status.

As an aside, it is worth nothing that password expiration times are no longer considered best practice (e.g. see https://pages.nist.gov/800-63-FAQ/#q-b05). While I am aware that it is possible to remove them using the AUTHORIZE utility, VSI may want to consider removing or extending the default expiration period.
Last edited by dmjb on Tue May 09, 2023 7:30 am, edited 2 times in total.


dgordon
VSI Expert
Active Contributor
Posts: 32
Joined: Tue May 09, 2023 7:57 am
Reputation: 1
Status: Offline

Re: Small bug in password requirements error message

Post by dgordon » Tue May 09, 2023 8:16 am

This is *not* a bug.

Some messages have FAO (Formatted ASCII Output) directives in them. !UB is the directive for unsigned byte decimal. (See the $FAO system service doc for a complete list.)

The audit server gets the final status, but not any of the arguments to fill in. When displayed, if the final status maps to message, that's what is displayed. SS$_INVPWDLEN is 9108 (decimal.) Try:

$ WRITE SYS$OUTPUT F$MESSAGE (9108)

and you'll get exactly the message you saw in the audit record.

$ WRITE SYS$OUTPUT F$FAO(F$MESSAGE (9108), 15)

would give you a fully-formatted message.

Because the minimum password length is defined on a per-user basis, the message needs to have a variable base number. When the message is displayed in context, the number is correct. When the status is converted to a message in the audit, it's obvious that the user chose a too-short password, but you'd have to check the user record in SYSUAF to determine what the number should be. The user was given the fully-formatted message.

One important note: The password maximum was raised to 64 for V9.x, but not all access software has caught up. Until you are certain that your connection method supports passwords longer than 32, it's safer to stick to 32 or fewer characters.

Added in 13 minutes 48 seconds:
As an aside, it is worth nothing that password expiration times are no longer considered best practice (e.g. see https://pages.nist.gov/800-63-FAQ/#q-b05). While I am aware that it is possible to remove them using the AUTHORIZE utility, VSI may want to consider removing or extending the default expiration period.
I'm quite familiar with the NIST best practices for memorized secrets. Unfortunately, the rest of the world hasn't caught up. As a best practice, it's preferable to ship standard accounts in a mostly-locked-down state and let the system administrator modify in accordance with local policy.

That said, you shouldn't remove password lifetime entirely. Instead, you should set it to a very large value, say 9999 days. "Why?", you ask. Because an account with no password lifetime will never be allowed to change an expired password at login. If there's no password lifetime, how does the password become expired? Setting the password via AUTHORIZE marks the password expired by default. Or the system administrator can simply force all passwords to expire in the case of a suspected breach. Go with the long expiration.

User avatar

Topic author
dmjb
Active Contributor
Posts: 49
Joined: Mon Aug 17, 2020 4:38 pm
Reputation: 0
Status: Offline

Re: Small bug in password requirements error message

Post by dmjb » Wed May 10, 2023 4:41 am

Thanks for the detailed explanation. It seems unfortunate that the error message is unable to display the actual minimum value from a usability perspective, but at least I understand how this is not a bug.


dgordon
VSI Expert
Active Contributor
Posts: 32
Joined: Tue May 09, 2023 7:57 am
Reputation: 1
Status: Offline

Re: Small bug in password requirements error message

Post by dgordon » Wed May 10, 2023 7:50 am

It seems unfortunate that the error message is unable to display the actual minimum value
It did -- when the message was displayed to the user.

What you're displaying is the security alarm, which is mostly of use to the system or security administrator. Remember that VMS is a server-oriented OS. For the "person in charge", it's important to know about all login failures, but the choice of a short password on password change is what's important -- not how long the minimum was for that particular user. That information was both provided to the user when it happened, and available to the administrator via AUTHORIZE if needed.

A quick check of the source tells me that the original INVPWDLEN message (complete with FAO argument) has been in VMS since 1988. The increase of the upper length text was changed from 32 to 64 in 2021.
Last edited by dgordon on Wed May 10, 2023 7:51 am, edited 1 time in total.
Executive Vice President of InfoServer Engineering at VSI.

User avatar

Topic author
dmjb
Active Contributor
Posts: 49
Joined: Mon Aug 17, 2020 4:38 pm
Reputation: 0
Status: Offline

Re: Small bug in password requirements error message

Post by dmjb » Thu May 11, 2023 2:08 pm

Got it. Thanks again for the explanation.

Post Reply