Testing username/password from DCL - VMS

This is a discussion on Testing username/password from DCL - VMS ; Say I have a DCL script that runs under the account WEB_SERVER which has
no privileges. (except tmpmbx and netmbx).
That script gets a request with a username/password as parameters.
What would be the best/easiest way to test those prior ...

Testing username/password from DCL

Say I have a DCL script that runs under the account WEB_SERVER which has
no privileges. (except tmpmbx and netmbx).

That script gets a request with a username/password as parameters.

What would be the best/easiest way to test those prior to sending the
results back to the remote user ? And would there be a way to test for a
privilege ?

Would opening a DECNET task or just attempting to type a some file
aka:
$TYPE/OUTPUT=NLA0:-
0"''username' ''password'"::SYS$MANAGER:SYSTARTUP_VMS.COM

Be sufficient ? (and then use ON ERROR to detect a failure). This would
require an implicit file access to that file (either via a SYSTEM
account, or someone with SYSPRV).

Would having a few SET NOVERIFY in the procedure ensure that the
username/passowrd is never written to any log file ?

I would also have to ensure the username and password fields are not
empty to ensure no default proxies are used (since the WEB_SERVER
account needs some proxies for itself).

Or would it be considered far more secure/safe/efficient to write an
application installed with privileges that checks the
username/password/privs via $GETUAI system service ?

Is there any sample code that verifies a password and if wrong, does the
right calls to log that failed login attempt ?

Re: Testing username/password from DCL

In article <37abd$474c8f17$cef8887a$18988@TEKSAVVY.COM>, JF Mezei writes:
>
>
>Say I have a DCL script that runs under the account WEB_SERVER which has
>no privileges. (except tmpmbx and netmbx).
>
>That script gets a request with a username/password as parameters.
>
>What would be the best/easiest way to test those prior to sending the
>results back to the remote user ? And would there be a way to test for a
>privilege ?
>
>Would opening a DECNET task or just attempting to type a some file
>aka:
>$TYPE/OUTPUT=NLA0:-
> 0"''username' ''password'"::SYS$MANAGER:SYSTARTUP_VMS.COM
>
>Be sufficient ? (and then use ON ERROR to detect a failure). This would
>require an implicit file access to that file (either via a SYSTEM
>account, or someone with SYSPRV).

Seems pretty heavy to create a process and do network I/O, even if it
is minimal, to check/validate a username/password. Why not write a
program -- which can be installed with the necessary privies -- to do
the check?

>Would having a few SET NOVERIFY in the procedure ensure that the
>username/passowrd is never written to any log file ?
>
>I would also have to ensure the username and password fields are not
>empty to ensure no default proxies are used (since the WEB_SERVER
>account needs some proxies for itself).
>
>Or would it be considered far more secure/safe/efficient to write an
>application installed with privileges that checks the
>username/password/privs via $GETUAI system service ?

I would.

>Is there any sample code that verifies a password and if wrong, does the
>right calls to log that failed login attempt ?

Re: Testing username/password from DCL

In article , VAXman- @SendSpamHere.ORG writes:
> In article <37abd$474c8f17$cef8887a$18988@TEKSAVVY.COM>, JF Mezei writes:
>>Or would it be considered far more secure/safe/efficient to write an
>>application installed with privileges that checks the
>>username/password/privs via $GETUAI system service ?

Note that $GETUAI should only be used if you require this to work on VAX.
Otherwise, use $ACM in order to take advantage of breakin evasion and
auditing.

Re: Testing username/password from DCL

JF Mezei wrote:
> Say I have a DCL script that runs under the account WEB_SERVER which has
> no privileges. (except tmpmbx and netmbx).
>
> That script gets a request with a username/password as parameters.
>
> What would be the best/easiest way to test those prior to sending the
> results back to the remote user ? And would there be a way to test for a
> privilege ?
>
> Would opening a DECNET task or just attempting to type a some file
> aka:
> $TYPE/OUTPUT=NLA0:-
> 0"''username' ''password'"::SYS$MANAGER:SYSTARTUP_VMS.COM
>
> Be sufficient ? (and then use ON ERROR to detect a failure). This would
> require an implicit file access to that file (either via a SYSTEM
> account, or someone with SYSPRV).

On the commercial systems that I used to manage, that method would
always fail. SYLOGIN.COM had code in it to disable all non-proxy decnet
logins.

It made sure that no one put a username and password combination in a
command file to remotely access a production machine. Incoming FTP was
also disabled for most accounts.
> Or would it be considered far more secure/safe/efficient to write an
> application installed with privileges that checks the
> username/password/privs via $GETUAI system service ?
>
> Is there any sample code that verifies a password and if wrong, does the
> right calls to log that failed login attempt ?

I am not aware of any sample code.

I do know that a frequent mistake is to validate the passwords on
disabled accounts, or to ignore other login restrictions.

And as LJK posted, for newer releases you can use the ACM$ calls, on
VAX, you need to generate the intrusion calls other logging manually.

Re: Testing username/password from DCL

In article <37abd$474c8f17$cef8887a$18988@TEKSAVVY.COM>, JF Mezei writes:
> What would be the best/easiest way to test those prior to sending the
> results back to the remote user ? And would there be a way to test for a
> privilege ?

Is there a reason you can't use the authentication built into the
web server?
> Would opening a DECNET task or just attempting to type a some file

Tempting, but the intrusion source will be the script account, i.e.
LOCALNODE::WEB_SERVER
> Is there any sample code that verifies a password and if wrong, does the
> right calls to log that failed login attempt ?

When I was looking for something similar one of the better examples was
in Ruslan Laishev's RADIUS port, also worth taking a look at Ferry Bolhar's
CHKLGI package from Hunter's Freeware.

Re: Testing username/password from DCL

Of course, it goes without saying that you should use the $ACM services
where available, as long as you don't ask any difficult questions about
why the TCP/IP Services POP server doesn't use it ;-)

Re: Testing username/password from DCL

Graham Burley wrote:
> Of course, it goes without saying that you should use the $ACM services
> where available, as long as you don't ask any difficult questions about
> why the TCP/IP Services POP server doesn't use it ;-)

Because VMS management refused to have $ACM available on VAX, I can't
use it. $ACM is good for specific applications that will run on a
specific platform, it can't be used for software that is to be
distributed to anyone because roughly 1/3 of the installed base is on VAX.

So I essentially have to re-invent the wheel and write my own $ACM which
is why I was wondering if something was already available. Really makes
me wonder why they didn't compile ACM on VAX to include it with 7.2 or
7.3 (or whenever $ACM appeared).

In terms of TCPIP services, they managed to do things right for FTP even
on VAX, so it means that having an application generate intrusion
detection stuff is possible on VAX.

Now, if I do write my own application, I am somewhat concerned about it
being installed with the necessary privileges. It means that anyone can
use it to test passwords and specify some source that could be the
boss' terminal for instance (denial of service to the boss).

Re: Testing username/password from DCL

In article <6fc65$474d5ea7$cef8887a$18158@TEKSAVVY.COM>, JF Mezei writes:
>
>
>Graham Burley wrote:
>> Of course, it goes without saying that you should use the $ACM services
>> where available, as long as you don't ask any difficult questions about
>> why the TCP/IP Services POP server doesn't use it ;-)
>
>Because VMS management refused to have $ACM available on VAX, I can't
>use it. $ACM is good for specific applications that will run on a
>specific platform, it can't be used for software that is to be
>distributed to anyone because roughly 1/3 of the installed base is on VAX.
>
>So I essentially have to re-invent the wheel and write my own $ACM which
>is why I was wondering if something was already available. Really makes
>me wonder why they didn't compile ACM on VAX to include it with 7.2 or
>7.3 (or whenever $ACM appeared).
>
>
>In terms of TCPIP services, they managed to do things right for FTP even
>on VAX, so it means that having an application generate intrusion
>detection stuff is possible on VAX.
>
>Now, if I do write my own application, I am somewhat concerned about it
>being installed with the necessary privileges. It means that anyone can
>use it to test passwords and specify some source that could be the
>boss' terminal for instance (denial of service to the boss).

I provided a company with a program that was only to be run by their
applications which were a nested in a morass of DCL procedures. What
I did was have the program check the procedure which was executing it
and compare that with an authorized procedure name (in an exec mode
logical). As long as the procedures were RE and nobody on the system
had privies to change the DCL or the logical, there seemed to be very
little in the way of using the program for purposes other than what
it was intended for. Even if the procedure was used for something
outside of this company's intended use, it wasn't annything that was
really deleterious to their operations.

Be very carefull of taking a user's input and putting it in a
DCL command that way. The user could enter a variety of lexical
functions as either username or password that could get them
results other than what you want.
> Would having a few SET NOVERIFY in the procedure ensure that the
> username/passowrd is never written to any log file ?

No. Suppose the user enters f$verify(1,1) as part of those
fields. Where does the output then go?
> Or would it be considered far more secure/safe/efficient to write an
> application installed with privileges that checks the
> username/password/privs via $GETUAI system service ?

That's a much better idea. But if the web server account is not
privileged, what are you going to do with the username and password?
Are you just checking that a user can do something before you start
a process to do it under his username/password?

Re: Testing username/password from DCL

> Note that $GETUAI should only be used if you require this to work on VAX.
> Otherwise, use $ACM in order to take advantage of breakin evasion and
> auditing.

And if you do need VAX support and intend to use $GETUAI, you will have
to call the $SCAN_INTRUSION calls yourself.

Re: Testing username/password from DCL

On Nov 27, 4:41 pm, JF Mezei wrote:
> Say I have a DCL script that runs under the account WEB_SERVER which has
> no privileges. (except tmpmbx and netmbx).
>
> That script gets a request with a username/password as parameters.
>
> What would be the best/easiest way to test those prior to sending the
> results back to the remote user ? And would there be a way to test for a
> privilege ?
>
> Would opening a DECNET task or just attempting to type a some file
> aka:
> $TYPE/OUTPUT=NLA0:-
> 0"''username' ''password'"::SYS$MANAGER:SYSTARTUP_VMS.COM
>
> Be sufficient ? (and then use ON ERROR to detect a failure). This would
> require an implicit file access to that file (either via a SYSTEM
> account, or someone with SYSPRV).
>
> Would having a few SET NOVERIFY in the procedure ensure that the
> username/passowrd is never written to any log file ?
>
> I would also have to ensure the username and password fields are not
> empty to ensure no default proxies are used (since the WEB_SERVER
> account needs some proxies for itself).
>
> Or would it be considered far more secure/safe/efficient to write an
> application installed with privileges that checks the
> username/password/privs via $GETUAI system service ?
>
> Is there any sample code that verifies a password and if wrong, does the
> right calls to log that failed login attempt ?

JF. Before I chime in please tell us what you are up to. Are you
trying to validate a username/password from a web page? If so, what
kind of webserver software are you running?

p.s. I do this all the time with HP's Apache for OpenVMS. In some
instances we let Apache prompt for the OpenVMS username/password while
in other instances we do OpenVMS username/password validation from
within our served-up applications.

Re: Testing username/password from DCL

JF Mezei writes:
>In terms of TCPIP services, they managed to do things right for FTP even
>on VAX, so it means that having an application generate intrusion
>detection stuff is possible on VAX.

Not quite right. The reverse the bytes of the IP address in the intrusion
record compared to that from, say, a TELNET login failure.

Re: Testing username/password from DCL

Neil Rieck wrote:
>> p.s. I do this all the time with HP's Apache for OpenVMS. In some
> instances we let Apache prompt for the OpenVMS username/password while
> in other instances we do OpenVMS username/password validation from
> within our served-up applications.

Web servers validate username/passwords to gain access to protected
pages. But they won't check if a user has sufficient privileges to run
perform certain tasks.

But come to think of it, one can setup access controls limited to certan
users only, even on OSU, so you could limit it to say "SYSTEM" and other
username/password combis would be rejected even if they are valid passwords.

Re: Testing username/password from DCL

On Nov 28, 5:05 pm, JF Mezei wrote:

[...snip...]
>
> Web servers validate username/passwords to gain access to protected
> pages. But they won't check if a user has sufficient privileges to run
> perform certain tasks.
>
> But come to think of it, one can setup access controls limited to certan
> users only, even on OSU, so you could limit it to say "SYSTEM" and other
> username/password combis would be rejected even if they are valid passwords.

True.

My employer's users (mostly technicians and clerks) look at IE/Apache
as just another way to get onto our system (they usually enter in
VT200 mode via Reflections but some prefer IE). So we've got to get
them to log-in just so we know who they are for logging purposes (we
log all changes to our ticketing databases).

Whether they are challenged via the Apache module
"auth_openvms_module" or directly via the served-up application (which
them must have sufficient privs to inspect SYSUAF) doesn't make much
difference.

Now if you were running a public web app like Amazon.com you wouldn't
expect each person to have an entry in SYSUAF (or whatever the equiv
would be on that system). You would do it in some sort of customer
database. In this case you have priv login mechanism for sysops, DBAs,
etc. We use these too and do it through 3 different protected script
directories: public, semi-private, private.

NSR

Re: Testing username/password from DCL

In article <37abd$474c8f17$cef8887a$18988@TEKSAVVY.COM>, JF Mezei writes:
> Is there any sample code that verifies a password and if wrong, does the
> right calls to log that failed login attempt ?

Check out the code in the OSU web server. I modified it for my own use
to make it fancier. Let me know if you want to know more.