Gavin,
Problem #2 can be fixed by doing STREAM TEST < $NULL
No prompting occurs.

John Zoltak
North American Mfg Co

> -----Original Message-----
> From: Gavin Scott [SMTP:[log in to unmask]]
> Sent: Tuesday, March 17, 1998 1:44 PM
> To:   [log in to unmask]
> Subject:      [HP3000-L] Using MPE to authenticate users
>
> Jim writes:
> > The method I had devised (but not implemented) would attempt to
> stream a
> > job using the supplied Username and Password.  Then check HPCIERR to
> see
> > if the job launched successfully.
>
> Just for grins I tried to find a misuse of !JOB syntax that would
> allow
> you to check the passwords without actually submitting a job.  In ten
> minutes of playing around I was unable to find one.
>
> I did find lots of reasons why !JOB is a really lousy way to check
> passwords though :-)
>
> The top problems are:
>
> 1) If the user has appropriate capabilities, the passwords passed to
> the
>    !JOB command are ignored completely, and the job will always log
> on.
>    This makes it look as though the passwords are valid when they are
> not.
>
> 2) If you fail to specify a password, or specify a null password, the
>    :STREAM command will prompt you for each password three times.
>
> 3) All the jobs logging on and off causes lots of problems.
> Logon/logoff
>    is still a fairly intensive process, so there will be performance
>    issues, and the job numbers will increase much faster than usual.
>    Also the extra number of INVALID PASSWORD FOR... messages on the
>    console might make it less likely that you'll notice an attempt to
>    violate *MPE* security.
>
> The first two restrictions could be gotten around by doing the check
> in
> batch from a user without AM or SM capability, and which will never
> be asked to check the user password for the user *it* is running as.
> Otherwise it's not very useful.
>
> From a security point of view, any facility that lets you quietly test
> passwords for validity is a serious security hole, so there shouldn't
> be any (non-privileged) way to do this that doesn't have a side-effect
> such as the !JOB command's INVALID PASSWORD FOR... console messages.
>
> So what you need is some privileged routine that quietly tests the
> passwords for validity.  There may be something like this in MPE, but
> I
> don't know about it.  One option is to go get the real passwords out
> of the directory and do the compare yourself.  Code that does this
> is probably available in the public domain somewhere (I've seen it
> done several times).  Of course the user might have used SECCONF to
> enable encrypted passwords, in which case even this won't do you any
> good.
>
> G.