Re: Most common keystroke loggers?

[Shannon Johnston <sjohnston () cavionplus com>]

This is fantastic! I like all the feed back that has been coming
through. I think that it would be helpful to explain a bit more.

The original question about keystroke loggers was an effort to find some
loggers that were in use (with screen capture capability) so they could
be used in our testing.

The actual problem stems from our efforts of trying to secure an
application keeping in mind that a user's system may be compromised,
and/or the user has been socially engineered into giving out important
credential information.

We've been playing with 2-factor authentication, randomized graphical
"keyboards", S/Key, one time passwords (sent via email/SMS), even
getting to the point where the system will call a user on the phone and
ask for a verification word when authentication is attempted.
I know that education of the end user is the best defense, but there
will always be people who just don't get it. With that logic I almost
have to consider the user an untrusted source.

The goal of the project is to see if we can design a system that
prevents an uneducated user from shooting themselves in the in the foot.

Shannon



On Fri, 2005-12-02 at 12:01 +1300, Nick FitzGerald wrote:
> deepquest wrote:
>
> > To me the only thing that can defeat keystroke is what a software
or  
> > trojan can not do: See (OCR is just a partial application of guess  
> > but not applicable in that case)
>
> Then you are so far inside the box you cannot see the walls...
>
> The OP said "keystroke logger" BUT he also said "compromised".  If
the 
> machine is compromised you cannot limit yourself to "keylogging" as a 
> compromised machine may be running _anything_ (including something
not 
> yet written, as we are talking about a hypothetical future situation, 
> so the OP limiting the original question to "the most common
keylogger" 
> is further evidence that the OP does not understand the actual
problem 
> set he has been posed).
>
> > Imagine a web page with a virtual keyboard page (clickable). In
order  
> > to prevent the localisation on the keys mapping based on position
of  
> > the mouse, display the keyboard on random location of the
screen.  ...
> Trivially, and already long ago, overcome by screen-shot keyloggers.
>
> > ...  Add  
> > a random password and challenge authentication process.
>
> Why?
>
> This adds nothing but annoyance to the user, thus reducing
usability.  
> If you're going to move to OTP, why _also_ move to an onscreen 
> keyboard?  It's almost like you believe that taking two unrelated 
> approaches that indivdually make no improvement whatsoever will 
> suddenly make some real improvement when combined.  A hint -- zero
plus 
> zero equals ??????
>
> As already explained ad nauseum to the other naïve "use OTP", if you
do 
> not do something "out of band" _relative to any and all possible "bad 
> code" that could be running on a compromised machine_, you have
lost.  
> To achieve that requires a second, "secure" piece of _hardware_ that 
> simply uses the network connection through the compromised machine to 
> communicate in a crptographically secure way with the server.  The OP 
> made no mention of designing hardware
>
> > my 2 cents,
>
> If that's really what the above "advice" is worth, inflation must be 
> _really bad_ where you are!
>
>
> Regards,
>
> Nick FitzGerald
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/