Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!XEROX.COM!Murray.pa
From: Murray.pa@XEROX.COM
Newsgroups: mod.protocols.tcp-ip
Subject: Re: secure replacements for passwords
Message-ID: <870111-133755-4114@Xerox>
Date: Sun, 11-Jan-87 16:37:50 EST
Article-I.D.: Xerox.870111-133755-4114
Posted: Sun Jan 11 16:37:50 1987
Date-Received: Sun, 11-Jan-87 23:22:41 EST
References: <8701110003.AA06976@topaz.rutgers.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 30
Approved: tcp-ip@sri-nic.arpa

As long as you can work on the software at both ends, then your goals
are reasonable. Needham and Schroeder published a scheme back in '78.
Check out the Dec '78 CACM.

The basic idea you are looking for is pretty much the following. The
user calls the server, and sends his claimed identity (username) in the
clear. The server picks a random number and a session key, encrypts them
with the users password and sends them back to the user. The user
decrypts them, and uses the session key to encrypt the random number and
sends that back to the server.

DES will eat a lot of cycles if you do it in software. That's not a
problem if you only use it for authentication, but if you are encrypting
everything going to/from a terminal session, response will probably be
unacceptably slow. Micros are getting pretty fast these days. Check it
out. You might just make it. (Sorry I don't have any numbers handy.)

I strongly suggest a physically separate network for administrative
work. Don't even connect it to the rest of the world via any gateways.
This transforms the problem back into physical security. Most
administrative people understand that. In any case, it becomes their
problem and you (we?) can't get a black eye because some tricky point
got overlooked. Keep in mind that observing terminal traffic is just the
tip of the iceberg. As your users get more sophisticated and upgrade to
more powerful machines, you will have to worry about printing things
directly from a workstation, swapping to remote disks, remote debugging
sessions, and strange new things that nobody has even imagined yet.

Our administrative people upstairs have their own ethernet (and printer
and file server and ...).