[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <439057F7.880.2CF3274F@gmail.com>
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
Powered by blists - more mailing lists