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 for Android: free password hash cracker in your pocket

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

Message-ID: <43904CCC.13101.2CC78620@gmail.com>
Date: Fri Dec  2 00:32:09 2005
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Most common keystroke loggers?

mz4ph0d@...il.com to Lyal Collins:

> >In 1996, this virtual keypad concept was broken by taking 10x10 pixel images
> >under the cursor click, showing the number/letters used in that password.
> >
> >Virtual keypads are just a minor change of tactics, not a long term
> >resolution to this risk, imho.
> 
> While it's obviously NOT the most secure way, that absolutely
> nothing can be considered secure if the system is compromised,
> that it would depend on either depending on either Javascript
> being enabled on the client-side or using Java (or perhaps
> Flash) for the interface elements, and using a random system
> to interpret the results (because the interaction with the server
> over the network can also likely be parsed), etc, etc ...
> 
> What about a system that used a randomly built and placed
> keyboard ...

What's with this obsession with annoying the user with random 
placement?

And _much_ worse, random key layout?

Neither buy you anything, nor does the combination, so stop suggesting 
them already.

> ... where the button (or more effectively the entire
> keyboard, though less usable obviously) went blank on
> mouseover and click?

Absolutely trivially broken.  As most key loggers already monitor the 
web page (or the domain of the web page) all they need do is add a 
"grab a screen shot when the randomized keypad window pops open from 
<URL>" and maybe a "grab the top-left window location of that window" 
then all the "keylogger" needes to do is record the positions of mouse  
clicks.

Broken.  Perhaps twenty minutes coding... 

And don't get me started on the usability issues -- it would be 
entirely useless for most fine-motor or visually impaired users who 
would be able to use a normal (onscreen) keyboard...

> That would at least stop two of those problems, those being
> basic keylogging, and screenshots of the hotspot on click.

Yet it entirely fails to solve the problem of recording the keys that 
the user "presses", "types" or however you prefer to express it.  The 
_point_ is not to prevent keylogging _pre se_ but to prevent stealing 
the _information_ conveyed in the "keying".  Your suggested scheme is 
precisely useless for solving that problem.

> At least then if a system like this is the only one that is
> deemed doable it would be more secure than one that
> didn't have those features. Yes? It may as well be on the
> higher end of insecure than the lower end, (if "insecure" can
> be seen as a scale, as unfortunately it often has to be in the
> real world with budgets and stupid management).

This is just as insecure as a plain onscreen keyboard, and with less 
usability.  Sounds like a bargain at any price -- NOT!

You are deeply confused if you think "is totally trivial and hasn't 
been attacked _yet_" is in any meaningful way "more secure" than "is 
equally trivial and has already been broken".

> Z.

Yes, go back to sleep...

Regards,

Nick FitzGerald