Conference noted::hackers_v1

	     Dave (KALKIN::) Butenhof has some method of encoding a
	password for his BUSY tool.  You might want to ask him.
			<_Jym_>

        Depends a lot on what you mean by "encoding" a password in
        a symbol.  For the original note you quoted, the encrypted
        value of a password would be absolutely meaningless, since
        RMS wouldn't be able to use it... it needs the *text* of
        the password.
        
        What BUSY does (via BUSY/ENCRYPT) is to actually encrypt
        the password text and create a command file which will define
        a logical name to the quadword binary encryption (in hex);
        for example, my BUSY password gets defined as such:
        
$ !
$ ! Encrypted password definition for Dave Butenhof (BUTENHOF)
$ ! Created  2-FEB-1984 13:39 by BUSY/ENCRYPT=COM$:
$ !
$ Define BUSY$ENCRYPTED_PASSWORD "EC9B705AA767829C"

        When you run BUSY, it knows how to translate the logical
        name, convert the hex ascii to binary, and use it as the
        encrypted password value.
        
        The only missing piece is the actual encryption algorithm.
        You could find one in a book, or use the ENCRYPT layered
        product (assuming you can make your software dependent on
        ENCRYPT).
        
        However you get the encrypted value, you can do like BUSY
        does, and store it in a file so that it can be used over
        again (of course, you could generate a DCL symbol assignment
        just as easily as a define command, if you want); or you
        can use $CRELNM, LIB$SET_SYMBOL, or LIB$SET_LOGICAL to define
        things at runtime for the life of the image or process.
        
        What you do depends on what you want to do.  Your requirements
        weren't specific enough to say much more.
        
        I'll most likely ignore further discussion of this topic,
        incidentally, since I don't read this conference: I'm here
        by special request for my response to this particular topic.
        I'll be glad to try to answer specific questions by mail.
        
        	/dave

	What protection will prevent the user from seeing the password
	(by doing a SHOW SYMBOL), yet allow the DIRECTORY command (for
	example) to get the original password?

	FWIW, sometimes RMS seems to cache passwords, so that if you say:

		$ DIR NODE_1"SMITH PIGBLUFFFLE"::SYS$SYSTEM:

	Then later, the command:

		$ DIR NODE_1"SMITH password"::SYS$SYSTEM:

	will work.  This is not a bug, but neither is it supported.

>Then later, the command:
>$ DIR NODE_1"SMITH password"::SYS$SYSTEM:
>will work.  This is not a bug, but neither is it supported.
    
    Sounds like a bug to me !  If "SMITH password" works when
    Smith's password is not P-A-S-S-W-O-R-D, then its a bug.
    
    Granted, it's not a *serious* bug, but a bug none the less.
    
    /Eric

    re: .-1, .-2
    
    Isn't that because you already opened the FAL link to the directory,
    and it's still alive? Those things usually stay alive for some
    system-specified period of time. Probably since the link (and
    authorization) has been established (in the context of the directory)
    then FAL remembers where it is, and since you (on the other system)
    still have the link open, you can continue to copy things to that
    directory...
    
    I played around with that, so that's what I think it does...
    
    
    Otherwise:
    
      I wrote a NETCOPY command (a la NFT) in DCL to allow users around
    here to push and pull files from accounts over the network without
    typing the password on a screen. since it was a command procedure,
    I used READ SYS$COMMAND for the account and password reads, and
    shut off echo (of course) for the password read. Then I made the
    username/password combination a local symbol and put that into a
    COPY command, basically like this:
    
$!
$ get_account_info:
$!
$	read/prompt="$_Account: "  sys$command account
$!
$	set term/noecho
$!
$	read/prompt="$_Password: " sys$command password 
$!
$	set term/echo
$       write sys$Output ""	! carriage return after PASSWORD
$!
$	aclist := """''account' ''password'""
$!  
    $	if pull.eqs.0 then goto push_file
$!
$	copy/log 'node''aclist'::'file1' 'file2'
$	goto end_it
$!
$ push_file:
$!
$	copy/log 'file1' 'node''aclist'::'file2'
$!
$ end_it:
$	exit
    
    Unless you have CMKRNL and you are watching the user's typeahead
    buffer, you'll never see the password. 
    
    By the way, if you are copying multitudinous files across the network,
    and you put in "password" at the password prompt, it allows it...
    (at least it does here)
    
    /pjh
    

re .5 (re .3,.4)

    It was QARed long ago.  I've forgotten most of the implementation
    details which were described in the reply (shame on me).

re .5

>    Unless you have CMKRNL and you are watching the user's typeahead
>    buffer, you'll never see the password. 

    Unless the person doing the copy steps away, and a passerby types
    <CTRL/Y>, SHOW SYMBOL /LOCAL /ALL, CONTINUE (nice guy!).

    re: .-1
    
>    >    Unless you have CMKRNL and you are watching the user's typeahead
>    >    buffer, you'll never see the password. 

    > Unless the person doing the copy steps away, and a passerby types
    > <CTRL/Y>, SHOW SYMBOL /LOCAL /ALL, CONTINUE (nice guy!).
    
    On Control_Y then goto Mess_everything_up
    
    $ mess_everything_up:
    $	acl_string := "you cannot get off that easy"
    $   all_other_secure_symbols = whatever you don't want them to see
    $   exit
    
    (security is only as good as the design and the cooperation of the
     user)
    

>   (security is only as good as the design and the cooperation of the
>    user)

    Huh?  Then why not just have the user type the entire copy command?

    hey, if a user walks away during a copy command, then the user
    obviously doesn't care about who sees the password. If the user
    doesn't know better, then the fault is the software.... since most
    users can't be expected to know better then the design of the software
    is the first problem. Maybe I didn't say that as explicitly as I
    should have.
    
    /pjh

    re .6
    
    I believe that by running SHOW after a <Ctrl>Y you will destroy
    the context for the copy image. Which should get you nothing more
    than a $ after the "continue". Unless, of course, you abort the SHOW
    command. I think that the "copy" will need to be restarted. If the
    command procedure didn't delete the symbol(s) on <Ctrl>Y, you should
    have the password and be able to restart the "copy" procedure.

SHOW SYMBOL does not destroy an image, since it is done directly by DCL.  Just
did it to NOTES.

-Mike

    
    
      I checked it out myself and you are right. I guess this is a good
    example of WBT (write before try) operations.
    
             So sorry.

re .9
    Right.  The purpose of this exercise seems to be 'hide the password'.

	    SPAWNing lets you look at lots of things, like symbols,
	open files, and even user-mode logicals.
			<_Jym_>

    
    re: .-1
    true, but....
    
    I don't want to beat this horse too much but if you trapped ^Y and
    clear the symbols in the handler, then SPAWN, SHOW, etc. don't matter
    anymore. The exercise is then academic, since the symbols are no
    longer what they were in the context of the command procedure.
    
    Of course, if you insist on not using a command procedure, then
    you have no ^Y trap available to glitch the symbols, therefore,
    SPAWN, SHOW, etc. work like they are supposed to. That's a feature
    of DCL. 
           
    re: general flame
    
    Since it seems that the need to use your password in network transfers
    (disregarding proxies, et al) is an anomaly (in relation to VMS
    security) rather than the rule (most of the time you WANT access
    to symbols so you can see what's going on) it's not VMS's fault
    that you can do any of the above mentioned things.
    
    Also, it seems we can code around the problem, since DCL is so nice
    to allow us to shut off and turn on ^Y, ^C, etc. and even DO THINGS
    when a user types one of those characters. 
    
    Correct me if someone knows more about this subject, but I am under
    the impression that the need to use password strings in your access
    control lists is a fundamental design "flaw/feature" given the fact
    that every system has it's own SYSUAF,NETUAF,RIGHTSLIST... since
    DCL isn't smart enough to know what you are typing before you have
    finished typing it (that would be a neat trick) we are back to square
    one - if you type your password on the screen and someone sees it,
    it's no fault of DCL, since DCL didn't know you were typing a password.
    If you write a command procedure which knows and asks you at a specific
    point in it's prompt script, and it shuts off your terminal's echo
    (since you told it to) and "hides" the symbol by burying it inside
    a command procedure, that's a bit smarter. Now if you make the
    procedure more airtight by handling bizarre occurrences like ^Y,
    RMS/VMS/DECnet errors, so that some vulture never has the chance
    to see the password, then that's about as good as you can get. 
    
    anybody see anything I missed, I'd love to hear about it!
    
    /pjh
    
    

      I think we need a feature that HP has:  the ability to turn
      terminal echo off and on in the middle of a line by entering
      a key sequence.  I'm no longer certain of what the escape
      sequences were when I was a user of HP systems, but in principle
      it worked this way:  the 2-character sequence ESC-: turned
      echo on and the 2-character sequence ESC-; turned echo off.
      If we wanted to implement this feature into VMS, the terminal
      driver could handle it.  We could use control characters rather
      than escape sequences.  
      
      Let <ON> represent the echo-on sequence and <OFF> the echo-off
      sequence.  Then, you could type 
      
 $ COPY NODE<OFF>"USERNAME PASSWORD"::DEVICE:[DIR]<ON>FILE.TMP *.*
      
      It would appear on your screen as
      
      $ COPY NODEFILE.TMP *.*
      
      SET TERM/PASTHRU should, of course, disable this feature
      
      Dave C.      

	    [RE .15]:  I wasn't addressing your ^Y-trapping command
	procedures so much as the fact that you can use SPAWN to
	retain "perishables" after a ^Y interruption.  I guess it
	is academic.
	    BTW, it is possible to trap ^Y in a compiled program.
			<_Jym_>

    	re: .16
    		It needs support from rather more than the terminal
    driver. DCL must get the password so that it can pass it on to the
    copy command, and DCL has command recall.
    
    		DCL must be made aware that echoing was supressed in
    that command line, and make that command line not recallable. Otherwise
    I can redefine COPY to point to an image of mine that just
    displays its command line, recall that command line and execute
    it.
		I tend to regard all this as a security frill rather
    than a security feature. If you let a good enough hacker get to
    your logged in terminal then you can never be sure that anything
    is safe anywhere. If you know someone is watching, and don't want
    a temporary display of a password on your screen then prop a book
    in front of it, finish typing the line, and hit a lot of contrl/T
    characters before you remove the book.

    I agree with .16 about the toggle-echo feature.  It's extremely
    handy.  My experience was with the Xerox Data Systems (XDS)
    Sigma 6 Operating System.  (Am I showing my age?  It was 15 years
    ago.)  They used the CTRL/P sequence.
    
    re: .18
    Yup, it would be nice if DCL made the command line non-recallable.
    But, I think it's _only_ a nicety.  Most of the time, you're in
    the position of someone looking over your shoulder when you're doing,
    for example, a network COPY command requiring an access control
    string.  You're not worried about recalls because you have no intention
    of performing a recall.  You just want to enter your COPY command
    without compromising account security.  HP and XDS had the right
    idea.  Make it easy for the user to protect himself.
    
    

How about teaching VMS that
	NODE"? ?"::file.ext
prompts on SYS$COMMAND: for the missing item.

Simple to do for copy and other utility programs, hard to
do as a general part of RMS.

Martin.

The immediate toggle-echo feature would be fairly difficult to remember,
so that recall would carefully only retype the echoed characters.
Also, if user edits a line with rubout, it's a bit of a nightmare.

On TOPS20, we had a fairly simple solution.  The syntax of all commands
requiring passwords was that the password was prompted for on a line
of its own.

Perhaps towards this end, we could have a job-wide table of passwords
associated with node names.  A DCL command could manipulate the table:

	$ set password/network nodfoo::noduser
	Password:

This command would cause dcl to turn off echoing when it reads the
password.  Then DCL would put the password in the job-wide table,
associated with the specified NODE::USER.

Since it's in the job-wide table, then ANY program or process in the
job could successfully open filespecs such as

	nodfoo"noduser"::filespec

The specification of a username without a password would indicate
to RMS that the job-wide password table should be used to look up
the password.

Hey you developers out there, how does this sound ?

Here's an example of using the feature.  Suppose user ATLANTIC::JONES
tells me his password over the phone, and instructs me to copy his
LOGIN.COM file to my system.  Here's what my screen looks like:

	$ set password/network atlantic::jones
	Password:
	$ copy atlantic"jones"::sys$login:login.com jones_login.com

/Eric

    
    RE: .21
    
    I'd be concerned about people hardcoding passwords into their LOGIN.COM
    files to "set up" their job environment for getting to
    commonly-accessed remote systems, as in
    
    $ set pass/network blah::user
    userpass
    $ etc ...
    
    John

I consider the state of things on Tops-20 to be pretty close to the
ideal.  You get prompted with the echo turned off, and the utility
remembers the password as long as it is a kept fork.

Martin's suggestion might be the closest approximation to the ideal that I
could expect to see on VMS.

Re .22:

Your objection about people who bury passwords in command files could be
substantially eliminated by making the command SET PASSWORD/NETWORK refuse
to accept password input from a command file.  It would still allow you to
specify the node and account names in a file, and just prompt the user
for popular passwords upon login.  If that is your idea of fun, instead
of waiting to prompt until the first time a password is needed.


It's a shame that the fact that you need privs to set up proxies (which
should almost eliminate the kinds of holes in the recent Stanford breakins)
encourages people to give their password to others (as in the scenario
in .-a few).  I wonder if any systems are smart enough to say "How come
you are logging in over a dialup line when you are already logged in
locally", and freeze the account?  It would get in the way if you are
debugging communications, etc.  However it would be good for most systems
to prevent users from logging in from more than one physical location
at a time.
				/AHM

The original  design for proxies allowed any user to set up proxies. The VMS
implementation is  a  subset  that was done in anticipation of proxies being
added to the DECnet architecture standards. Unfortunately, they have not yet
been added  to  those  standards. See DEC-TR-121 (available from the Maynard
library) for details of the original design.

{RE .23} - Actually, the recent Stanford breakins sound like they used
 something similar to proxies.  The fact that only people with privs
  could make use of them didn't appear to be the problem - it was the
   fact that they left the proxy access lying around when they were
    finished using it.
     <_Jym_>

    I agree that the 'correct' solution is user specified proxies.
    In the meantime, I've found that my most common use for 
    wanting to hide the password is that someone is looking over
    my shoulder.   For that, a simple command file that sets up
    a symbol or logical works just fine.
    
    	KC

My, how people forget.  TOPS-10 at one time had a means for the user to turn
echo off in mid-line - CTRL/B was an immediate toggle of echo/noecho.  I think
this eventually got removed - it came to be seen as very user-hostile, as new
users would accidentally hit CTRL/B and then go into a dither when the computer
"stopped working".

The closest you can come to accomplishing what the base note appears to be
looking for would be to write a privileged program that stored the symbol away
in a page readable only from EXEC mode (so you couldn't use EXAMINE to see
it), in P1 space where it could stay from image to image.  Then you would have
to decide on a policy for allowing access to it.  (Clearly, RMS itself would
not understand the password, so a simple COPY is out - it would have to be
used from suitable programs.)  A privileged, protected shareable image, or
even a user-written system service, would provide access, either by actually
returning the password or by doing the OPEN for the caller.  It could validate
its caller in one of a number of ways, ranging from a password passed by the
caller (secure as long as the calling program's contents remain secret) to
taking a checksum of P0 space and requiring that it match some value (could
be very secure but rather difficult to use).  Alternatively, you could use
the VMS security system and allow only an image installed with appropriate
priv's to read the saved password.
							-- Jerry