Re: Defeating keyloggers with encrypted one time passwords (a patent spoiler?)

(Sorry for dragging up this thread but..)

First; those one-time passwords are in use at many Swedish banks that
have customers logging in from the internet to pay their bills. You get
a small harware box for 2-factor auth when you get your internet bank
account. I also read somewhere about a 2 factor solution that did
challenge/response over the mobile phone network (which is rather cool)

There ARE programs that effectively can block keyloggers based upon API
functions say SetWindowsHookEx(), see:

Antihook http://www.infoprocess.com.au/
Processguard: http://www.diamondcs.com.au/processguard/

The question is: Can that kind of program be told to "do not disturb
the user" and block untrusted software from creating global hooks... we
will see.

Then we have signature keylogger detection - which is useless; using 2
lines in VB you can make a selfmodifying executable that makes a new
file hash every time it terminates..

A while ago i introduced a new type of keylogger
(GetKeyState/GetAsynchKeyState) which has taken off, but since the
latter are harder to code, i guess that not many keyloggers use those
API calls since you loose out keystrokes if you do it wrong.

(*** On the other side of keyloggers: One of my progs use such an API
call to detect if there is a user there, and use that activity to reset
a 5 minute counter; If that counter go over 5 minutes, it throws out
the cached session keys, passwords and usernames - then asks the user
to reauthenticate - so those API calls can sometimes be used to PROTECT
the security of the application as well.. ***)

Cutting/Pasting passwords into clipboard is also attacked by some
keyloggers, so using OSK.EXE or Charmap.exe is not safe either..

Simulating manual user input through other channels trying to avoid the
API functions, i.e. Sendkeys(Visual Basic) or SendInput() - are not
100% safe either.


IMO, The BEST thing would be to intercept API calls and (while running)
introduce false positives to potential keylogger applications since
YOUR application will be able to tell the difference between what is
desired input and what is crap.

Other processes do not (..or should not) have have any active windows
so sending random keystrokes to the system would be harmless.

Ichinin

.

Relevant Pages

  • Re: Radius Autentication using Chap
    ... There doesn't exist any feasible "decoding" for MD5. ... the passwords in reversible encryption and have your API provide access to ... >I need to authorized users with Chap, the user's names & password are> in an outside application that I have an API to it and they are not> Windows users. ...
    (microsoft.public.internet.radius)
  • Re: How to secure the Dotnet code
    ... As far as the HASP API is concerned, you will need to use your vendor ID and Passwords to call the API functions. ... We only have real world experience with the HARDLOCK dongle, ...
    (microsoft.public.dotnet.general)
  • Re: Keylogger resistance
    ... The onscreen keyboard still sends keys through the API that the ... keylogger will be watching anyway. ... passwords and ask randomly selected characters from each making sure ...
    (sci.crypt)
  • Re: Secure Password Storage
    ... my next thought was removeable media. ... Thats quite a few passwords. ... Depending on your security needs, ... kind of policy would remove the need to worry about keyloggers, ...
    (Debian-User)
  • Re: Logon Password
    ... >> When loggin on to windows 2000, is there a way to record ... The security log only ... >> windows that logs what the wrong passwords were used? ...
    (microsoft.public.win2000.security)