A system manager pitched his plight. "My operator, in his infinite wisdom, decided to change passwords on manager.sys.  Of course he forgot, or fingerchecked... I don’t know.  At any rate I need some help. Any suggestions, other than a blindfold and cigarette?"

Several versions of help involved the use of utilities from security experts VEsoft. "Do you have the GOD program on your system? If so, it has PM capability, and so it can give the user who runs it SM capability. So it will allow you to do a LISTUSER MANAGER.SYS;PASS=

(That's why GOD should be secured, by the way. A randomized lockword will do the job, visible only to users who have SM capability. When VEsoft installs MPEX, for example, it installs a randomized password to MGR.VESOFT, and to GOD.PUB.VESOFT.)

Paul Edwards, ever a source for HP 3000 training, ran through the backstop methods every system manager should practice to avoid such a dilemma.

1. You do run BULDACCT prior to each full backup so you can look in BULDJOB1 for the passwords, don’t you?
2. You have another user on the system with SM capability and a different password as a backup in case this happens, don’t you?  
3. Your operator used LISTUSER MANAGER.SYS;PASS just after changing the password to verify the accuracy as spelled out in the Operations Procedures section in your Systems Manager Notebook, didn’t he/she?  
4. You do have a Systems Manager Notebook as discussed in detail in my papers on Homesteading on my Web site, don’t you?

  Then Duane Percox of K-12 app vendor QSS opened up a clever back door:

If your operator can log onto operator.sys:
file xt=mytape;dev=disc
file syslist=$stdlist
store command.pub;*xt;directory;show

Using your favorite editor or other utility search for the string: "ALTUSER MANAGER  SYS" You will notice: PAS=

, <passwd> which is your clue

Then there's the question of how to keep passwords fresh. A development manager posed this problem:

"What management wants is for a user to be forced to change their  password on a regular basis. Also, certain rules must be applied to  the new password. We don’t have VEsoft’s Security/3000, although we do have MPEX, and I am unable to get the funds to buy it. I therefore have two options. 1)  Write something myself, or 2) See if there is anything in the Contributed Software Library that  will do the job or can be modified to supply the required solution.

Bill Lancaster of Lund gave the manager a summary of his situation. "You won’t be able to accomplish this using MPE’s password scheme. You’ll either need to find the money for Security/3000 or write/creatively acquire a passwording system that sits on top of MPE and can apply all the rules you want. The absolute best option is to get Security/3000."

Homegrown and bundled solutions followed. HP's Jeff Vance offered this:

There is a pseudo random password generator available on Jazz which knows MPE’s password rules. See: http://jazz.external.hp.com/src/scripts/index.html and scroll down to the link “RANDNAME”. There are also UDCs on Jazz which force a password to be supplied when using NEWUSER, NEWACCT and NEWGROUP CI commands. These required passwords can be random (uses the script above) or user entered with a minimal length enforced.  See: http://jazz.external.hp.com/src/scripts/udcvol/index.html

Then he added as an afterthought, a strategy to program your own password system:

I haven’t thought about it much, but it seems you could have a password file (maybe a CIRcular file?) for each user on the system. This file would have their last N passwords, and the modified date of the file would be the date their password was most recently changed.

A logon UDC could detect if the password file for that user exists. If not create it and require a new password right then.  If the password file exists then get it’s modified date and compare that to today’s date. If greater than X days then in a loop prompt for a new password. Validate the entered password against previous N passwords and your other rules. Maybe run a dictionary checking program to make sure the password is not common, etc.

Update the user-specific password file with their new password, and then logon the user.

From the user community, Donna Garverick weighed in with this advice:

The solution that your management is asking for is going to cost more for you to develop/implement/maintain than it’ll take for you to get Security/3000. If you have no choice other than to develop a product, then I’d certainly model it after what VEsoft has already done.  That is:

Based on a system-wide UDC, examine all sessions (it is just sessions, yes?  By the way, a DSLOGON from inside a job is still a session....) against a ‘database’ (By the way, just how secure is this database?  A real database needs passwords... Who’s going to maintain that? A flat file could be lockworded... but that’s not a slamdunk answer.) which is looking for the ‘age’ of the password (By the way, are you going to provide an advance warning period?). 

If it is time to change the password, get the ‘new’ password from the user... but writing the rules is a pain, and keeping track of reused passwords is just annoying. Auditors in the states love when you can say the password is one-way encrypted.  Dunno what your management is saying for encrypting an MPE password.

Then came a solution rolled up by Paul Christidis

Some years ago I had developed a set of command files that could be used  to require users to have passwords.  Later on, mostly as an exercise, I  enhanced the process to age passwords and to automatically assign ‘random’  passwords as they expire.  The random passwords are comprised of  alternating consonants and vowels, they can have a minimum and maximum  length and optionally a random digit can be inserted.

The entire ‘process’ is comprised of a system batch job (should be running  always), a command file that is invoked by a log-on UDC and communicates  with the batch job, a ‘control’ command file that starts and stops the  batch job, a command file to determine the password age and a command file  to generate the random password. Below are the comments from the batch job.  They explain some of the details.

!# Author:  Paul H. Christidis
!# Date:    06/17/96
!# Remarks:   This job 'listens' at a message file for any requests to
!#    determine if a user has a password.  Once that determination is
!#    made it passes back to the session an indicator to that effect.
!#    A command of STOP causes the job to terminate.
!#
!#      The request comes via the execution of a command file or a System
!#    wide UDC and it is comprised by the file name where the reply should
!#    be placed and the user's name and account.
!#      This job does NOT return the user's password, it only writes in
the
!#    message file specified by the client the command:
!#          setvar user_password true/false
!#      The client then executes the command and tests the setting of the
!#    variable 'user_password' to decide what action to take.
!#
!# DATE:    06/08/2004  *** WHILE RETAINING THE ABOVE BEHAVIOR ***
!#   The job logic was changed to assign a new password after 30 days.  A
!# file in the posix space is built using the user's name.  Then at each
!# logon a command file is used to determine the file's age, using its
modify
!# date, and when it is older than 30 days another command file is used to
!# generate a random password.  Said password is sent back to the session
!# and the user is informed about his new password.
!#
!#   If the 'job/session' name is not to be used in creating the posix
file
!# that will be used to age the password, then the value of the CI
variable
!# 'pw_UseSess' should be set to 'FALSE'.
!#
!# DATE:    06/10/2004   [Added alternative aging values functionality]
!#   Alternative aging limits are kept in an ASCII file "pswrdage"
comprised
!# of 'setvar' commands, for each MPE account, MPE user or Session name.
It
!# should adhere to the following format:
!#       SETVAR SYS_MANAGER_XTIDIS_pwage   45
!#       SETVAR SYS_MANAGER_pwage          40
!#       SETVAR SYS_pwage                  35
!#
!#  The above have the following implications:
!#    The user's "xtidis,manager.sys" password expires in 45 days
!#    The user's "manager.sys" password expires in 40 days
!#    Any other user of the "sys" account has their password expire in 35
days
!#    While the 'default' 30 days applies to every other user on the
system.
!#
!# NOTE 1: Suffix of '_pwage' is required.
!# NOTE 2: A negative or zero setting equals to NO password aging.
!# NOTE 3: The order MUST be 'ActName_UserName_JobName_pwage'.
!#
!# Date:    06/11/2004   [Added code to 'force' a password change]
!#   When the CI variable "ForcePwChange" is set to TRUE in the session
that
!# executes the command file, the 'passed' code is changed and the batch
job
!# forces the password change (Unless it was already changed on the same
day)
!# <---------------------------------------------------->

Dave Powell coded up some of the fine print nicely in his contribution:

It ought to be possible to do everything for free, using just MPE.  Editing the new password is the ugly part, but if you randomly assign it that issue goes away. The next issue is that the :password command seems to like to be purely interactive, as in:

echo oldpass >> tempf
echo newpass >> tempf
echo newpass >> tempf
:password < tempf
password
Command not allowed in noninteractive environment. (CIERR 2500)
PASSWORD WAS NOT CHANGED.

That leaves the altuser cmd, which needs AM cap.  If you don't want a background job (like Paul's suggestion), you can have the command file (called by  your logon UDC) use the echo command to build job with AM cap, which it then streams, kind of like (untested, but I have working examples of cmd-files building other jobs):

ECHO !!JOB ACCTMGR/PASS.SOMEACCT; HIPRI  >> TF
ECHO !!ALTUSER !HPUSER;PASS=!NEW_PASS >> TF
ECHO !!SETVAR STREAMED_BY   WORD(HPSTREAMEDBY,"()",2) >> TF
ECHO !!TELL !!STREAMED_BY Your new password is !NEW_PASS >> TF
ECHO !!EOJ >> TF
STREAM TF
ECHO Please note your new password when it appears
PAUSE 99; JOB = !HPLASTJOB
PURGE TF, TEMP

If I haven't screwed up the fine print too badly, this code in the middle of the password cmd-file runs the job that changes your password, then waits for the job to tell you what the new password is.  The single exclamations before HPUSER & NEW_PASS mean that values that are variables to the session and command-file become hard-wired values for the job.

Before all this your cmd-file checks the date, gets a random password, etc., as posted by others.  After it the cmd-file writes (or just builds) a file that serves as a timestamp.  But I am not too comfy with putting the passwords into a plain-text file, so I might skip that part (remember, the user needs both read and write access to it).  Put the command file in a group that users have xeq access to, but not read/write access.