Re: $SETUAI() Query/Problem

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

Date: Sun, 1 Feb 2004 01:39:41 -0000

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:rAoPF48Tifny@eisner.encompasserve.org...
> In article <pO2dnUvFieDoQIbd4p2dnA@brightview.com>,
"covendotartdottalk21dotcom" <postmaster@127.0.0.1> writes:
> $SETUAI transfers the entire UAF record to disk, because that is the
> nature of RMS records. Rethink your desired use of RMS between nodes
> and you will realize this has to be the case.

You are of course, presuming that I know the format of UAF records,
and that a user "record" is not actually comprised of a number of
other smaller "records". The $GETUAI()/$SETUAI() documentation
doesn't indicate the format of the UAF file.

> Yes, and that is quite straightforward. VMS Password Security depends
> on two mechanisms that are not available in this threat scenario:
>
> 1. Secrecy of the salt
> 2. VMS Breakin Evasion

Again, you're making a presumption (in #2) that access from any DECnet
or IP address is permitted to these systems. It's not. Permitted/
trusted nodes can be (and are) defined.

You might then presume that address spoofing is then an issue, but
you don't know what security measures exist in the networking
components of our network infrastructure.

> > (provided they had legitimate access to an OpenVMS system, and had
>
> Such as a free hobbyist license on a free machine offered from time
> to time.

Well, the box would have to be physically connected into our network,
and not using any kind of addressing mechanism that would conflict
with existing systems in the network, in addition to having access to
the datacomms rooms, and reconfiguring ports to which the box could
then be connected, to make them active.

Assuming of course that "they" could actually find a source of cheap
second-hand VMS boxes in this country.

Whilst "never say never" and "nothing is impossible" may be relevant
phrases here, I doubt very much that all of the elaborate steps that
would be required for such an attack to occur in our network, would
actually be fulfilled, and in any case, other systems which monitor
the output of these boxes would indicate within seconds a DOS attack,
or an attempt to change the output into something which "they" would
achieve some kind of benefit from.

> > programming skills available to them to make use of $HASH_PASSWORD).
>
> Or programming skills on a non-VMS system. I would not be surprised
> if there is hacker code to do the VMS password algorithm on windows.

I don't have a set of VMS source code, so I don't know whether or not
$HASH_PASSWORD() code is included (in its entirety), but I would have
thought this unlikely.

Is $HASH_PASSWORD()'s functionality generic (not specifically the
algorithms that are used), or is (some of) the implementation
VMS-specific?

> Those system services (not "perfectly good" due to never implemented
> AST capabilities) did not exist when Authorize was written.

That's as may be, but instead of repeating your argument, why not
indicate whether or not that is still the case, or whether Authorize
has, in fact, "moved with the times"?

> > 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.
>
> I do, and it is.
>
> > Maybe you have access to the source and can tell me different?
>
> I did in my prior post.

I don't see any reference to "I've got a set of VMS sources, and I've
looked for AUTHORIZE, and it does exist on the CD" in your statement
"What makes you think MCR AUTHORIZE uses those system services ?
It can do wildcards and the system services cannot."

Self-belief of implication is one thing, but it doesn't necessarily
follow that everyone else will infer the same thing, especially for
those for whom [American] English is not their mother tongue.

It's hard enough getting companies to continue to use VMS these days,
let alone choose it for new solutions, without resurrecting CJL's
attitude and then causing in-fighting amongst the brethren who still
practice it...

Instead of bitching about the fact that I'm trying to achieve an
automated way of changing passwords on thousands of accounts across
hundreds of systems, have you got any *useful* suggestions on how this
might be achieved (in a different way to the way I have been trying)?

Do you now, or have you ever had this problem? How did you deal with
it? If you've not had the problem, do you know of someone else who
did? How did they deal with it?

Mark

Relevant Pages

  • Re: $SETUAI() Query/Problem
    ... And network traffic coming from a PC needs to be identified by? ... > of password sniffing is unlikely. ... Some risk of password sniffing? ... Having hundreds of VMS systems might ...
    (comp.os.vms)
  • Re: OpenVMS Security
    ... >> You are absolutely right Andrew, however it seems you define 'network' ... > DECnet would at this point be a better option is laughable. ... Within a pure VMS ... or I use the IP stack for DECnet over IP to copy sofware over the ...
    (comp.os.vms)
  • Re: Routable Protocol for Clustering
    ... > Here's some specific info from our network engineers... ... > due to the fact that they will not support IP clustering. ... From the point of view of what a VMS cluster does, ... > fiber resources to dedicate paths for Proprietary VMS use exclusively. ...
    (comp.os.vms)
  • Re: $SETUAI() Query/Problem
    ... >> $SETUAI transfers the entire UAF record to disk, ... >> nature of RMS records. ... VMS Breakin Evasion ... _those_ computers are not secured from unprivileged users. ...
    (comp.os.vms)
  • Re: SMTP setup for rank newbie
    ... >>found that there was no SMTP service running on this node. ... I have little VMS experience, ... I walked into this network set up as it is, ...
    (comp.os.vms)