Conference noted::hackers_v1

An account SMITH_JONES with a secondary password?    

-piper

      From a command file, attempt to access a known non-existent
      file using specific access control; _e.g._, 
      
          $ DIRE/NOOUT 0"SMITH ''password'"::DOES_NOT_EXIST.NO_WHERE;

      and check the $STATUS returned for either insufficient privilege
      (the password is incorrect) or no such file (the password is
      correct).
      
      Dave C.

    
    Really don't want to have to create more accounts.  Besides, if
    there were accounts A, B, C, D I'd have to create accounts A_B,
    A_C, A_D, B_C, B_D, and C_D - a geometric progression.  If there
    were 50 accounts (more reasonable), I'd have to create 1225 accounts
    to accomodate it.
    

    
    re .2
    
    Dave, that sounds like it should work, but ...
    
    For some reason, when I tried it out, $STATUS was %X1 whether the
    password was correct or not.  What went wrong?
    

    Sounds like you inserted a (successful) command between the file
    lookup and the status check.  I just tried it and I get $STATUS=
    %X1001C02A for failure and %X10018290 for sucess.
    
    -Mike

    
    After person-years of testing, I've found out why.  There's a world
    of difference (believe it or not) between:
    
    $ DIRE/NOOUT 0"SMITH password"::NO_SUCH_FILE.EXISTS
    
    and
    
    $ DIRE/NOOUT 0"SMITH password"::NO_SUCH_FILE.EXISTS;
    
    The latter returns $STATUS %X1 regardless of the password.  (At
    least on VMS V4.3)
    

    I think the solution of 225.2 has a problem, due to the fact that RMS
    'caches' accounts/passwords.  That is, after one successful access (to
    that account), access to 0"SMITH password"::DOES_NOT_EXIST.NO_WHERE;
    will succeed, regardless (yes, that's "SMITH password", as is).

      Re .7
      
      Is that documented?  Is it a bug?  Should it be QAR-ed?  It
      is a feature?  Does it work only within the context of one
      process? one job? the whole operating system?
      
      Dave C.

It's not documented.  It's not a bug.  It's already been QARed and answered.
It's not a feature.  It only works within the context of one process.

Personally, I wouldn't rely on it's behaviour one way or the other (though
I've occasionally found it a nice way to 'hide' the password of a remote
account, while still being able to copy files from there -- interactively).
Too, it sometimes fails, and sometimes stops working in the middle of things.

In any case, it'd provide a security hole in your scheme, *unless* the process
was SPAWNed, tried the remote access, and was then deleted.

	    . . . you could always clear it with a bogus password:

		    0"USER <BOGUS_PASSWORD>"::FOO:[BAR]BAZ.BO

			<_Jym_>

    Maybe I missed something major, but it sounds like a wierd application.
    
    A friend of mine wrote an on-line application to control sign-off
    of products.  He had each user run the application for his/her own
    account.   Having Jones using Smith's terminal seems to encourage
    Jones telling Smith was the password was, rather than passing a
    keyboard around.
    
    Hope my rambling thoughts aren't too off the wall.
    
    	KC

    Well, I'm not really in on the design a whole lot.  The designer asked
    me how it could be done. 
    
    My understanding is that both people will sit down in front of one tube
    and test the new software.  When both are satisfied, they execute the
    DCL command file that creates an audit log that both SMITH and JONES
    approved the software, then updates the application library (I think it
    uses CMS/MMS). 

    

    
        Another hack can build a program that performs a network login with
    you specified command procedure that just exits.  By doing this you
    can get detailed information about why the login failed.  The only
    problem with this approach as with all the DECNET related approaches
    is that users with secondary password will not work.  When last
    I tried this loginout died with an access violation.
    
    
    More details:
    
    	Create a mailbox for reading the termination message.
    	Get the mailboxes unit number this is used as an argument to $creprc
    
    	   The first image run in the created detached
           process is SYS$SYSTEM:LOGINOUT.EXE.  It expects
	   as inputs the following:

	   SYS$INPUT - name of command procedure to be invoked.

	   SYS$OUTPUT - 3 concatenated ASCII access
			control strings (username, password, account).
    			(form of string: byte count,username string,byte count,
	 		password string, byte count = 0)

 	   SYS$ERROR - network control block (NCB).  For deferred process 
    		       initialization the NCP is used to form the process 
    		       logical name SYS$NET which in this case is the 
    		       filename specified as input to the deferred process.

    
	Now use SYS$CREPRC with these inputs to log in the user.  If
    the $CREPRC is ok then perform a read on the termination mailbox
    and find out the final exit status of the process. 
    
    
    
    							Forrest A. Kenney
    							Dtn: 481 - 4251

    
    PS Almost forgot you need to set PRC$M_NETWRK in the stsflg on the
       $CREPRC.

    If it's a program you wish to write just use the lgi$ routines that
    VMS uses to check users passwords on login. They are documented
    in the source fiche. You need to install the program with CMKRNL
    though. 
    
    John De Angelis.