[mod.protocols.tcp-ip] Password Security in the UCLA ACP

NS-DDN@DDN2.UUCP.UUCP (01/15/87)

 
I know it's hard for some people to believe, but the only locally available
encrypting hardware/software for many users lies under the cranium! There are
still lots of dumb terminals in other budget-consious organizations. Although
Charles' original request specifically ruled them out of his network, I, for
one, have to maintain their support. Consequently, I would like this discussion
to bear them in mind.
 
As Ron said, Charles, we're ignoring the problem of application program
passwords (in this sense, TSO qualifies as such). Having run whatever gauntlet
is implemented to gain access to server TELNET, your users will then have to
logon to your host's applications. Thus you would probably want to monitor the
TELNET session and encrypt the incoming responses for all recognized password
prompts. But you would still be exposed to situations where no prompt is given
unless you encrypted the entire user transmission. For example, assuming an
implementation along the lines of Ron's scenario:
 
    TSO:            ENTER LOGON - 
    Server TELNET:  [Encrypt your response with your ACP password]
    User:           logon myid/mypass a(xyz) 
 
If this is going on through a virtual 3278, you would be forced to negotiate
back to an NVT for that one transaction or create a screen for TELNET's use,
decrypt the datastream returned, unwrap and remap the single line into the
VTAM screen.
 
It also means you would have to analyze your supported applications to
determine where passwords are expected in responses, what those prompts look
like in terms of constants and variables, and maybe software DES would be
running a tight footrace with this kind of overhead.
 
Does the application support command stacking with a special character, such as
a semi-colon? Server TELNET may never see the normal prompt...
 
I'll bet that physical security approach is sounding better and better all the
time!
 
Try suggesting to your IBM marketeer that they provide 370 DES instructions and
supporting software. Also, get involved in SHARE and champion a requirement
that IBM software get its password obscuring act together, recognizing that
users are not always connected by an SNA device.