Finding Passwords.

Louis Faraut jlf at mirsa.inria.fr
Wed Oct 10 23:01:09 AEST 1990


Well, I think that the break-driven signaling mechanism is a good way
to prevent Trojan login problems, but I'm not yet convinced it does
not exist other solutions than those involving Unix kernel/driver
modifications or special hardware.

The protocol I proposed in my previous posting was of course too
simple to work efficiently (many of you have found easy ways to attack
it), thus I would like to suggest you a more elaborated scheme to
manage the secret key .  The challenge is "How could the system
display my private key at login while avoiding a bad guy to use this
key ?" .  I believe I have got an answer .

Let's try once again ...

Suppose you have a daemon to manage users's key -call it "keyd"- and
a program to query the keyd -call it "query"- .

Suppose the following scenario (-- introduces comments):

Login:foo
-- at this point a request is made to the keyd to choose a new key for
-- user foo.
-- keyd picks a word at random in /usr/dict/words and displays it on 
-- screen, then it remembers the user/key pair .

Password:<something>
-- Here, if the person who has typed foo is a bad guy, he does
-- not know foo's passwd yet, thus the login fails and a notification is 
-- made by root to the keyd forcing it to forget the pair
-- foo/foo's key and the bad guy has just got an obsolete key !
-- Else, for the good guy, a plain login occurs :
--
< login in progress >
--
< .profile executing >
-- In the first line of his .profile, user foo queries the keyd daemon for
-- his key . User foo can check this key against the previous displayed
-- key knowing immediately if he has been a victim of Trojan login .

KNOWN BUGS:
Of course this does not prevent Trojan, you *cannot* stop someone from
writing "Login:" on a screen, but it warns you quickly of problems .

Also, it is a bit annoying to visually compare both occurrence of your
key on screen, but they are some benefits of this protocol (no
encryption no driver hacks no special hardware)

I'm not sure this can prevent the pty hack (?)

--

Thus, should I missed something important here ? If so, please let me
know .

Thanks in advance .

	Jean-Louis Faraut
	(ESSI Sophia-Antipolis, France)

English always bad, idea better ?



More information about the Comp.unix.internals mailing list