Password History

[Sentosa]

Dear All,

As I want to change back my previous password but fail, how can I know no. of old password lists kept in the system?

If the password history file full, the system requests to choose the password from the list.
How can I reset the password history file?

Thanks,
Sentosa

[Hein van den Heuvel]

How did you fill up the record?
You may want to check out the logical: lgi$password_nochange_days

By default, the system retains these records for one year. Password history records that are older than the system password history lifetime are allowed as valid password choices.

My method?

$OPEN/READ/WRITE/SHARE=WRITE pass SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA
$READ/DELETE/KEY=sentosa pass record ! Poof
$SHOW record ! Just in case
$!WRITE/SYMBO pass record ! Changed your mind?
$CLOSE pass ! This too shall pass

With the users record data in the symbol you could conceivably manipulate some entries (I believe there is a timestamp to help corelate fields), but why bother.

You may want to check out the AUTHORIZE command:
UAF> MODI ... /FLAG=DISPWDHIS


hth,
Hein.

[John Gillings]

Sentosa,

The password history file is an indexed file keyed on username containing a dated history of hashed passwords. Its contents are controlled by logical names:

SYS$PASSWORD_HISTORY_LIMIT and SYS$PASSWORD_HISTORY_LIFETIME

If not defined, they default to 60 and 365. (See HP OpenVMS Guide to System Security for details).

As you say, once a user has user LIMIT passwords within LIFETIME, they are forced to use generated passwords.

You could increase the limit and/or lifetime to give the user more capacity, or you can clear their password history entirely by deleting the corresponding record from the password history file. For example:

$ OPEN/READ/WRITE/SHARE pwdhist SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA
$ READ/DELETE/KEY="SENTOSA" pwdhist rec
$ CLOSE pwdhist

The history record will be recreated when the user next changes their password.

On the other hand, if you have suffient privilege to do any of the above, you can simply set the password directly using AUTHORIZE:

$ MCR AUTHORIZE MODIFY SENTOSA/PASSWORD="your-password"

changes using this mechanism are not subject to history constraints

[EdgarZamora]

When using:

$ MCR AUTHORIZE MODIFY SENTOSA/PASSWORD="your-password"

I would recommend adding a /NOPWDEXP as the password change will usually be set to (pre-expired) and when you log in you'll be asked to change password again.

[Hoff]

Consider simply shutting off system security. Seriously.

You've triggered the password over-change logic; you've changed passwords so many times you've blown out the buffer and been tossed into the generated password penalty box. (Yes, folks that tried to "loop" the password history list in an attempt to re-use an old password were considered when the OpenVMS password code was written.)

As for your request, give up the fig leaves here and set your password to null, and lock out password changes. This makes it way easy to manage passwords, and you can avoid all the hassles around password changes. This also makes it easier on the system crackers and password sniffers, if that's a concern. (BTW, there is Windows malware around that sniffs passwords off telnet connections, and it's trivial to set up an OpenVMS box to sniff, too.)

As for your specific request, invoke the AUTHORIZE utility and issue the following command: MODIFY SENTOSA /FLAG=DISPWDHIS
/NOPWDLIFETIME (and consider /PASSWORD=""). Problem solved.

Or dig out all the old passwords from the password history database, as was described earlier.

Or deal with the generated password at least until the history lock-out times out.

If you set up ssh keys or kerberized telnet or such, you can avoid many cases where you previously had to enter passwords and usernames. This is usually a better approach if you're going to be messing about and want to avoid passwords, or to avoid sending passwords in the clear. ssh keys work nicely with ssh and with sftp and scp and such; you can get out of embedding passwords in command procedures -- which I might guess is centrally involved here -- and you have the ability to change passwords (ssh keys, in this case) as and when required.

Dig out the passwords in the existing DCL, in other words, and fix the underlying problem. Or set up the target username with a null password. (This since embedded passwords are little better then null passwords, and far more honest about the level of security provided. Most any decent cracker around knows to search OpenVMS disks and disk backups for text strings such as [expurgated], after all.

Stephen Hoffman
HoffmanLabs LLC

[Sentosa]

thanks

[Hein van den Heuvel]

Hello Sentosa,

You indicate the issue is closed, but no contribution is marked as a solution.
Did it not work for you? What was missing?

I know I did not answer the letter of the question, just the spirit, so maybe I misread the spirit.

To address the letter of questions... you can find the number of passwords kept by looking at the record length in the history file. Subtract 32 bytes for username, divide by 12 for date+code. If this is somehow really critical for you (I cannot imagine myself) then you should verify those number by creating a record for a first password, check length (Either DUMP/REC=(COUN=1,STAR=x), or similar to the DCL but dropping the /DELE and checkig F$LENGTH(record)).

You can reset the file by deleting all records ($READ/DELE without key) or by recreating it empty with ANAL/RMS/FDL old, CREAT/FDL=... new.
But in that case, like Hoff questions, why bother with security at all?! :^)

Hope this helps some more,
Cheers,
Hein.