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 ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Testing username/password from DCL

  1. 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 ?

  2. 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 ?


    Is there some reason why you'd want this to be DCL only?

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  3. 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.

  4. 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.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  5. 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.

  6. Re: Testing username/password from DCL

    In article , burley.not-this@encompasserve-or-this.org (Graham Burley) writes:

    > When I was looking for something similar


    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 ;-)


  7. 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).

  8. 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).


    Well, protection on the image itself would keep certain parties out.
    ACLs my be useful too.

    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.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  9. Re: Testing username/password from DCL

    In article <37abd$474c8f17$cef8887a$18988@TEKSAVVY.COM>, JF Mezei writes:
    >
    > 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 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?



  10. 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.

    ftp://picard.eurokom.ie/setpass.zip

    contains code that does something like:

    $ setpass /old= /new=

    Use as a template, or simply remove the bits that do the actual password
    changing.

    ---------------------------------------------------------
    Tom Wade | EMail: tee dot wade at eurokom dot ie
    EuroKom | Tel: +353 (1) 296-9696
    A2, Nutgrove Office Park | Fax: +353 (1) 296-9697
    Rathfarnham | Disclaimer: This is not a disclaimer
    Dublin 14 | Tip: "Friends don't let friends do Unix !"
    Ireland

  11. 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.

    http://www3.sympatico.ca/n.rieck/dem...pache_demo.zip
    http://www3.sympatico.ca/n.rieck/dem...-pw-change.zip

    The second demo as written for VMS-7.3 and needs a few tweaks for
    VMS-8.x

    Neil Rieck
    Kitchener/Waterloo/Cambridge,
    Ontario, Canada.
    http://www3.sympatico.ca/n.rieck/


  12. 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.

  13. 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.

  14. 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



  15. 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.


+ Reply to Thread