Re: $SETUAI() Query/Problem

From: covendotartdottalk21dotcom (postmaster_at_127.0.0.1)
Date: 01/31/04 

Date: Sat, 31 Jan 2004 16:53:07 -0000

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:owaUX4dF8GaK@eisner.encompasserve.org...
> In article <iZidnUd-geh-54fd4p2dnA@brightview.com>,
"covendotartdottalk21dotcom" <postmaster@127.0.0.1> writes:
>
> > I'm writing some software that is intended to run on NODEA and change
> > passwords on NODEB, but avoiding sending the password in cleartext
> > form across the network to NODEB (i.e. NOT some kind of remote
> > submission of MC AUTHORIZE commands).
>
> > From within a program (DEC C), I can quite happily create a logical
> > name of SYSUAF with a value of NODEB::SYS$SYSTEM:SYSUAF.DAT in the
> > process name table, in supervisor mode on NODEA with:
>
> > However, when I attempt to use $SETUAI() or $GETUAI, the system
> > services always seem to pick up the definition in the SYSTEM name
> > table, not the PROCESS one.
>
> But if that _did_ work, what gives you the slightest hint that it
> would meet hour goal of "avoiding sending the password in cleartext" ?

Using $SETUAI in combination with $HASH_PASSWORD gives you a one-way
encrypted password.

If someone also "sniffs" the SALT and algorithm in use (because one
has to $GETUAI in the first place, to find out the user's SALT and
algorithm - one can't guarantee that the algorithm in use on NODEB is
the same as NODEA - in order to use $HASH_PASSWORD appropriately),
then arguably, "they" could use that to launch a dictionary attempt
to see if "they" could ever generate the same hashed password
(provided they had legitimate access to an OpenVMS system, and had
programming skills available to them to make use of $HASH_PASSWORD).

However, depending on what criteria are specified for password
selection, the chance of actually generating the same hashed password
before it gets changed again, may be slim (and depending on how "they"
attempt to then connect to NODEB, "they" may set off intruder alarms,
further limiting "their" chances of not being detected).

Even if someone does generate the same hashed password, the fact that
it was not sent in cleartext format, still meets the obscurity
deptartment's requirement that it is not sent in cleartext format.

It's not my fault that they're not more specific in their assessment
of vulnerabilities (which I think are a load of hocus anyway:
knee-jerk reactions to the events accidentally caused by a supplier
who is a trusted user, are not the way to go; they only succeed
in making systems less usable; if they want a secure system, they
should power it off, place it inside a safe inside a bunker in the
middle of the Siberian wilderness; of course, it won't then offer
the intended service, but at least it's secure)

> What makes you think MCR AUTHORIZE uses those system services ?

Because it would seem logical, since it gets and sets UAF information;
having separate code that has to change each time the UAF format
changed (i.e. if AUTHORIZE manually traverses the UAF file itself)
would be nonsensical - why not use perfectly good system service
routines that already exist?

> It can do wildcards and the system services cannot.

The VMS mail command allows you to specify more than one destination
email address using @FILENAME.EXAMPLE, but that doesn't mean that the
callable mail routines actually support it (they don't; in VMS mail,
it's DCL which parses the parameter, and deals with it appropriately;
if you use callable mail routines, you have to manually process the
@FILENAME.EXAMPLE yourself (depending on how the parameter is passed
to your program, and posibly, which language you are using).

Ergo, MC AUTHORIZE may manipulate wildcards and convert them into
suitable $SETUAI()/$GETUAI() calls; just because it handles wildcards
doesn't mean it doesn't use system services.

But then again, I don't have a copy of the source code, and I'm not
sure if the source for AUTHORIZE is even included on the CD.

Maybe you have access to the source and can tell me different?

Mark