Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Finding Passwords
Message-ID: <12411:Oct919:40:1290@kramden.acf.nyu.edu>
Date: 9 Oct 90 19:40:12 GMT
References: <13@tdatirv.UUCP> <9105:Oct910:13:5190@kramden.acf.nyu.edu> <278@pdxgate.UUCP>
Organization: IR
Lines: 17

In article <278@pdxgate.UUCP> griffith@eecs.cs.pdx.edu (Michael Griffith) writes:
> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >Under the assumption I made---that each communications line is direct
> >and has some unconditional way to remove any middlemen---Trojan Horses
> >are stopped. There's no need for encryption to solve this problem.
> And what, pray tell, guarantees that the line is clear? If the break key
> clears the line and prevents processes from accessing it, I sure as hell
> don't want users bumping into the break key and losing processes because
> they can't attach to the tty file.

Yes, I really do mean ``unconditional'' when I say ``unconditional.''
It's a user interface problem if people accidentally bump into the break
key. One solution is to have a harder-to-accidentally-type break
sequence. Another is to let the user reconnect to a session later if it
was accidentally cut off; pty lets you do this.

---Dan