Re: Need to generate passwords (really long response - sorry)

Gang -

WOW!  I didn't expect the response that my simple (I thought!) question 
generated.

Answering or commenting on several responses:

================================================================================================

Mike Wills wrote:
"My big question on this is, how does this prevent anything? As admin on the
server, you can still reset the password. Yes, it prevents others from
getting to "the new guys" info, but other than that?"

and Steven Ryan wrote:

"With all due respect to those who have offered there suggestions on
generating passwords, I think we need to reconsider the scenario of the
original request.

The original request was that new users be given a password, that would be
changed by them to whatever they want the first time they sign in.  This is
where the real problem lies.

No matter how sophisticated or randomised the password, it will be useful
for about 30 seconds.  After that, the user will put in the wife's name or
the dog or (heaven forbid) 'password'.

So while we can come up with all sorts of wonderful formulas, if, in the
end, the user is choosing their own password, it will all be for naught."

Mike and Steven -

I agree!  This prevents nothing. Unfortunately, the auditing group doesn't seem 
to understand this - perhaps I've ticked them off!

================================================================================================

Narayanan R Pillai wrote:
"I think the requirement was to generate an initial password and then give
the password to the new user. I am sure that the profile is PWDEXP(*YES)
along with this. This allows the user to reset it to a "non-sticky-note"
password.

Have I gotten this right ?"

Narayanan -

Yes, you've gotten it right - for the most part.  We will also be using a 
password validation program to avoid trivial passwords.

===============================================================================================

Mark Lazarus wrote:
"Have you explained that random passwords are *far* more likely to be put
on a Post-It on the side of the screen??"

Mark -

The "randomized" password will be expired and the user will be changing it as 
soon as he/she signs on for the first time.  We are also implementing a 
password validation program which will use a "dictionary file" to prevent the 
use of "common words".  Where the dictionary file comes from, I don't know.  I 
also don't know who gets to define "common words" - I suppose the creator of 
the dictionary file.

================================================================================================

Booth Martin wrote:

"Ever explain anything to an auditor?   Successfully?"

No - and certainly not recently - that's why I'm asking for help!  :-)

and he wrote:

"Get an old newspaper and a dart.   throw the dart. thats the password.  Tell
him that's your Random Password Generator(RPG).   If he is still concerning,
get a Wall Street Journal and use one of those pages.  Now you have an
Official Wall Street Journal Random Password Generator.  If he's still upset
buy a New York Times Sunday Edition."

HEY!  Now there's an idea!  But I need to automate it . . . maybe a monkey . . 
.  ;-)

===============================================================================================

Paul Musselman wrote:

"How does Auditing plan on you informing the new user of their initial 
password?"

The current process uses a command-and-CLP to perform several initial tasks in 
addition to the CRTUSRPRF command.  The last step sends a "Welcome" e-mail to 
the user informing them to contact me to get their new password (which, at the 
moment, is the same for all new users).  Auditing (actually, this particular 
auditor) wants to include the password generator in this process and include 
the generated password in the "Welcome" e-mail (I didn't bother explaining that 
I could send myself or anyone else a CC: of the "Welcome" e-mail).

===============================================================================================

Scott Klement wrote:
"It says that he cannot assign an initial password, even if it is set to
*EXPIRED.   It does not say that the programatically generated password
would also be expired.

Even if he meant to say that the programatically generated password would
also be expiring, he did not ask us how to deal with whatever passwords
the users assigned -- his question was "does anyone have a CL/RPG/COBOL
solution to generate 'random' passwords?" "

Scott -

Yes - the programmatically generated password will be *EXPIRED.  We are also 
implementing a password validation program which will use a "dictionary file" 
to prevent the use of "common" words.

===============================================================================================

Again, I'm amazed at the volume of response that my query generated.  Thanks to 
everyone who responded either directly or to the list.

Thanks again,

Steve