Finding Passwords

[Nick Andrew]

jlf at mirsa.inria.fr (Louis Faraut) writes:

>Hello interns !

>Here is my little contribution to the logins Trojan issue .

>What about a two-ways authentication, modifying the getty program to
>oblige the computer to authenticate itself ?

	So far so good. I have written a modem-smart getty, and I think
I'll include an anti-trojan concept of some sort before posting.

>This could be achieved the following way, by use of a secret keyword, 
>sort of secondary passwd :

>	- CPU prompts "login:"
>	- type your login name
>	- CPU uncrypts your secret keyword and display it on screen .
>(Each user keeps up his own secret keyword encrypted in a personal file ;
>only the owner and root can read/modify this file )
>	- CPU prompts "passwd:"
>	- Now you can either type your usual passwd if the secret
>keyword was right, or do anything else possibly aborting the session .

	BEEP! You lose ... anybody can type your name at the "login:"
prompt, so the trojan author will know what to print out when you login.
Maybe you meant "type your login name, then your 'secret-keyword-encryption-
key'(tm)", and the getty uses the key to decrypt your secret keyword.
The caveat with the method is that the user should expect the s-k-e-k(tm)
to be compromised if there is a trojan running, but not the user's
password (the user detects the compromise and does not type the password).
This leads to a meta-problem ... the trojan author can collect the
s-k-e-k(tm) from several users and feed them back into the getty program.

	It seems that the s-k-e-k must be a one-time pad, so the trojan
author cannot collect s-k-e-k/response pairs to fool the user. I would
suggest a file in $HOME filled with at least 1000 s-k-e-k/response tuples.
Each tuple is only usable once. The tuples need not be encrypted - as it
is the user doing the verification, I don't see that encryption would be
any benefit (see the problem above). But obviously the tuples must be
protected.

Cheerio,
	Nick.