openVMS minimum password duration

[hirschi]

Is it possible to implement a "minimum lifetime" for passwords ?
We would like to unable a password change during at least 15 days after its creation.

[Karl Rohwedder]

I know of no standard VMS solution for this.
Of course you could modify the dcltables and call your own image instead of SETP0, check for the password change (this is stored in UAF record) and issue an error message or call SETP0.

regards Kalle

[hirschi]

Thanks Karl.
Do you know where we could find password rules in HP documentation ?
We would need official documentation to provide evidence of this lack of fonctionality for a security audit ...

[Karl Rohwedder · Accepted solution]

Check the standard VMS docs, e.g. here:
http://h71000.www7.hp.com/doc/os83_index.html.

Esp. the System Managers Essentials and the Guide to System Security.

Some thought about this can be read here:
http://www.osdata.com/holistic/security/security.htm#OpenVMSsecurity

To prevent user to use old password again (by changing it several times), VMS keeps a history of used password (can be disabled on a per user basis).

regards Kalle

[Richard Brodie_1]

"Do you know where we could find password rules in HP documentation ?"

In the system security manual. One might also ask, "in what way does preventing you from changing your password increase security?"

[Rick Dyson]

There is an ability to implement any password rules you want, over and above the default OpenVMS ones. I do this to enforce intitutional rules.

Using the same API hooks (documented in manuals), I would assume you should be able to collect the last password reset date from the UAF with a system service call and then do the math and deny the new password.

I have not done this, but the hooks all seem to be there to my mind. (consider the source ! :)

I don't recall where the exact docs are located, but a key word to look for is "VMS$Password_Policy". It is triggered by setting the SysGen parameter: Load_PWD_Policy.

rick

[Ian Miller.]

additonal password requirements can be enforced by implementing a site specific password policy as described here

http://h71000.www7.hp.com/doc/82FINAL/5841/5841pro_091.html#create_share_image_sec

[Kris Clippeleyr]

Time to revive this thread.
Browsing through my collection of undocumented features, I stumbled over the LGI$PASSWORD_NOCHANGE_DAYS logical name.
The equivalence should be numeric; the value sets the minimum time (in days) to change the password.
E.g.:
$ DEFINE/SYS/EXEC LGI$PASSWORD_NOCHANGE_DAYS 5
$ SET PASSWORD !1st time OK
Old password:
New password:
Verification:
$ SET PASSWORD !2nd time refused
Old password:
New password:
Verification:
%SET-F-PWDLOCKED, password is locked to prevent change

Hope this helps,
Kris (aka Qkcl)

[Wim Van den Wyngaert]

Note that Kris uses an undocumented and thus unsupported feature. IMO they should not exist and be supported or not be tehre at all.

Wim

[Dave Laurier]

If you would like to create a site specific password policy then also check the following thread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=866372

It contains examples for various people in various programming languages that show how to create a shareable image for this purpose.

[Jan van den Ende]

Looks like Kris has the answer.

But it also looks like Engeneering should (and easily could!) document this feature.

Although personally I always question WHY one would want to, but I _HAVE_ seen this demand before ( by rule-making auditors without real-life experience, nor any thinking capability, I assume ) and IF you run into such demand, it will be sooo much easier to just be able to comply...

fwiw,

Proost.

Have one on me.

jpe

[comarow]

Interesting demand. Yes, you can create your own interface, but it would be very customized for that site and difficult to maintain.

We know that you can lock a password. Assuming the user is unprivileged, you could use a com procedure that creates an account, and locks the password. It could also create another com procedures, of just a few lines, that will unlock it after the duration.

I suspect you are trying to prevent people from setting it back. As someone just mentioned, the password history prevents that, so you may not need any solution??

Best of luck.