Creating system-generated passwords without using SET PASSWORD

[Jeremy Begg]

Hi,

I'm preparing to automate the creation of user accounts on my OpenVMS 8.3 systems and would like to auto-generate the passwords for the new accounts.

I'm comfortable with the passwords generated by

$ SET PASSWORD /GENERATE

but that command is not well suited to the task at hand.

Is there a callable interface to the password generator, or a standalone program? I haven't been able to find one.

Thanks,
Jeremy Begg

[Joseph Huber_1]

If nothing better can be found...
put the single line
$SET PASSWORD/generate=n
into a command-file (n: choose the wanted password length).
$Exit or EOF after the kine, so that set password does not get old/new password input and simply exits.

Execute the command-file with /output=tempfile or pipe it into a command-file, which reads the output (or sys$pipe), and takes the password(s).

An alternative could be another generate password program like gpw.c at

ftp://ftp.multicians.org/

You could modify it to put the generated password into a DCL symbol.

[Joseph Huber_1]

And in addition there are CPAN perl modules
String::MkPasswd
( http://search.cpan.org/~cgrau/String-MkPasswd-0.02/lib/String/MkPasswd.pm )

and
Crypt::RandPasswd

( http://search.cpan.org/~jdporter/Crypt-RandPasswd-0.02/lib/Crypt/RandPasswd.pm )
\

[Hoff]

One usual approach involves perusal of NETCONFIG.COM.

IIRC, some related underpinnings are available via the undocumented sys$forge_word system service.

I've posted full source code of the NEWUSER user creation tool (with an MIT-style license) at http://labs.hoffmanlabs.com/node/1260

[Joseph Huber_1 · Accepted solution]

.. and a DCL one-liner to get a generated password into a logical name:

pipe write sys$output "Invalid" | set password/generate=8 | (read sys$pipe l ; read sys$pipe l ; define/job password &l)

[Craig A]

If the LockPWD flag is set then the account issuing the SET PASS/GEN password will get:

%SET-F-PWDLOCKED, password is locked to prevent change

Craig A

[Graham Burley]

I would've thought $mc authorize add/generate_password more suited to the task, but I've probably missed the point.

[Jeremy Begg]

Hi,

Responding first to the last posts from Craig and Graham ...

The newly-created accounts won't have LOCKPWD set, so that's not going to be a problem. And in any case the password will be generated before the account is created.

Graham, thanks for pointing out the /GENERATE_PASSWORD qualifier, I didn't know about that one. I don't think it will work for me in this situation because it still requires me to select from a list -- which isn't as automated as I need. But I think it will be useful elsewhere!

I'll respond to the other suggestions and assign points when I've had a chance to look at them in more detail.

Thanks!
Jeremy Begg

[John McL]

Is it too difficult to write some code that uses randon numbers between appropriate limits for ASCII a-z, A-Z and 0-9 and repeat this for however many characters? Use a seed such as I/O ops on a disk if you want to make it difficult for people to emulate what you've done and get the same password.

Once you have it then use $SETUAI to save it.

You've not said if the users will change their passwords when they first access the system but I'm guessing that's the case.

[Jeremy Begg]

Hi John,

No, it's not too hard to write some code to spit out a string of characters -- but I'm trying to not reinvent the wheel, and I prefer that the generated password be pronouncable (more or less).

I should add that these accounts will be non-interactive, primarily for email services, and users won't be required to change them. (We will provide an option to allow users to change them if they wish.)

Thanks,
Jeremy Begg

[Jeremy Begg]

Hi all,

Big thanks to Joseph for the DCL one-liner, it does exactly what I need.

The GPW and Perl programs look like too much work to set up; GPW requires some dictionaries and the Perl code requires modules which we don't currently have installed.

I still need to look at Hoff's NEWUSER program.

Regards,
Jeremy Begg

[Joseph Huber_1]

>> The newly-created accounts won't have LOCKPWD set,

Just a note, it is not the newly created account, it is the creator/administrator/Your account which is issuing the set password, so this must not have LOCKPWD!

[Craig A]

Another thign to bear in mind is that depending on your site it might be better to create the account via a batch job and then have the initial password emailed to the user.

I did this at one site where there were lots of different type of underlygin servers: VMS, Unix, IBM, etc..

All with different username conventions and lengths.

The purpose of the exercise was to use each others email address as the key for populating which access they had to which systems.

So when they first logged in they were asked for their email address and then an accesss code was mailed to that address (only internal addresses were allowed). They then had to get the access code from the email and enter it.

Over a few weeks we were able to build up a picture of who had access to what accounts.

Dependong on what you are trying to achieve you could just generate, say, a 10 digit integer - using F$CVTIME() and use that as the password.

HTH

Craig A