full-disclosure - Most common keystroke loggers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri Dec  2 01:19:49 2005
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Most common keystroke loggers?

Kyle Lutze to Blue Boar:

<<snip>>
> > Note, however, that "keyloggers" that grab some portion of the screen 
> > surrounding the mouse pointer every time you click have already been 
> > observed in the wild.  They are designed to specifically defeat this 
> > kind of mechanism.
> > 
> Actually, I think there's a relatively easy solution, make it so every 
> single time they want to login, have a different set of characters line 
> up to their password.
> That didn't make much sense, here's a good example
> 
> say somebody's password is foobar, on screen ...
                                     ^^^^^^^^^
                                     |||||||||

You _really_ don't get the issue here, do you??

"on screen" means that it can be captured.

Thus, _it CANNOT work to avoid capture on a compromised machine_.  If 
you can display it, a (sufficiently determined) attacker can capture 
it.

> ... there would be a page that 
> shows the new alignment of characters,such as saying a=c, d=3, b=z, etc. 
> so instead of typing foobar the password they would type in for that 
> session would be hnnzck.

And, as already pointed out in response to exactly the same suggestion 
from someone else, depending on the _user_ to do the encoding for you 
in a reliable and error-free way is not exactly a recipe for success...

> The next time the screen came up, it would be a=n, b=l, etc. and the 
> password they would enter would be something else. Then, if the computer 
> had a keylogger, not too much anybody could do with that info.

But the keylogger author would rewrite the code to _also_ grab a 
screenshot of the encoding table, or simply to just grab the HTML that 
describes the page if the encoding table is not purely graphical.

If you want to solve this kind of "problem" don't think "what's a 
clever thing I can do to complicate the process?", but think "if I were 
an attacker, what could I do?".  When you understand the _scope_ of the 
options available to the attacker (rather than the _actual instances_ 
of "attack" that are known to already have been implemented) you are 
well-placed to propose "solutions"...

So far, no-one suggesting solutions has fallen into that category (and 
there's a good reason for that).

Regards,

Nick FitzGerald