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

[ Converted text/html to text/plain ]
The difference between you (us) and the auditors is this:

Auditors investigate what has happened after the event. Auditing does not
prevent anything. If there are thousands of transactions  (eg. a journal on a
transaction file), auditing the data can easily miss something that may
suggest a fraud or something.

Our job is to prevent the event happening in the first place. If there were no
events, there would be no need for auditors. On a well run system with most
infringements prevented, the auditors do not have a big job to do. However,
auditors do need to justify their fees and feel duty bound to come up with
some suggestions no matter how ludicrous, or how much it wastes time.

The fact that you have been asked to create this password generator suggests
that the auditors can't find anything else of any significance to worry about.
I would take this as a compliment, they obviously don't have much else to
concern them.
Regarding the password program - if you set the user profile to *EXPIRED the
password will only be used once and forgotten about. It doesn't matter what
the password is, or how it was generated. The password won't need to be
written down for all to see. Any old program will do, I don't see any reason
to waste a lot of time on it.
Your boss is required is required to listen to the auditors concerns, so
creating a simple program keeps the auditors and your boss happy, and you get
paid for wasting company time!!
Your system is only as secure as the the passwords chosen by the users
themselves. Perhaps the auditors will pick on this aspect next time. Perhaps
you could pre-empt them!!
Syd Nicholson
McKay, Steve wrote:

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 ab
out 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 
audi
tor) 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 prev
ent 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
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com[1]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l[2]
or email: MIDRANGE-L-request@midrange.com[3]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l[4].

===References:===
  1. mailto:MIDRANGE-L@midrange.com
  2. http://lists.midrange.com/cgi-bin/listinfo/midrange-l
  3. mailto:MIDRANGE-L-request@midrange.com
  4. http://archive.midrange.com/midrange-l