Finding Passwords

[Michael Griffith]

brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>In article <13 at tdatirv.UUCP> sarima at tdatirv.UUCP (Stanley Friesen) writes:
>> In article <22024:Oct606:35:1090 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>> >In article <652 at puck.mrcu> paj at uk.co.gec-mrc (Paul Johnson) writes:
>> >> If you are worried about physical line security then use encryption.
>> >All that's necessary is that the concentrator and the computer accept some
>> >key sequence (such as break) to unconditionally mean ``I want to talk to
>> >someone I can trust, so gimme a proper prompt and shove any middlemen
>> >out of the way.'' That's it.
>We're only talking about stopping trojan horses. Not about password
>security. Nor about login spoofs.
>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. If it doesn't then my process just goes ahead and does what
ever despite the fact that the line is supposed to be clear. If the signal is
only recognized when when a process such as getty is running then I just
prevent getty from running and emulate the response myself.


| Michael Griffith                     | If I had an opinion it certainly   |
| griffith at eecs.ee.pdx.edu             | wouldn't be the same one as        |
| ...!tektronix!psueea!eecs!griffith   | Portland State University anyways. |