🚀 go-pugleaf

In article <1935@enst.enst.fr>, tardieu@cyclone.enst.fr writes:
|> In article <77925@hydra.gatech.EDU>, gs26@prism.gatech.EDU (Glenn R. Stone) writes:
|> -> In <1992Dec9.123607.22649@nntp.nta.no> styri@hal.nta.no (Haakon Styri) writes:
|> -> 
|> -> >[...] dan@cubmol.bio.columbia.edu (Daniel Zabetakis) writes:
|> -> >|>     Is there a way to detect password trapping programs.
|> -> >If the login program was able to authenticate itself to you before you
|> -> >revealed your password the problem would be solved.
|> -> 
|> -> Something I saw at the University of California: login was hacked to 
|> -> attempt to open $HOME/.secret (presumably mode 600) and display it
|> -> as the Password: prompt; each individual had his own, custom .secret
|> -> file that he could change from time to time.  If the right challenge
|> -> isn't displayed, then you know that that isn't the real login program.
|> -> 
|> -> 4.3 BSD UNIX (ucscb.UCSC.EDU)
|> -> 
|> -> login: thrush
|> -> What's the haps?
|> 
|> I don't understand the utility of this soft: you just have to make a little
|> Perl or C program which tries to login under each username, and you'll
|> obtain all sentences.
|> It's easyer if you want a particular password.

A real good solution to this problem is to use a one-time password system.
Spoofing would be outdated. However, you'll have to introduce a new system
and probably invest some money.

A poor mans hack to the "individual challenge" scheme outlined would be to
have more than one password prompt. Not perfect, but harder to beat. The
paranoid user should of course change password every time a login fails...

---
Haakon Styri