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]

Message-ID: <43909CB8.3090603@thievco.com>
Date: Fri Dec  2 19:13:03 2005
From: BlueBoar at thievco.com (Blue Boar)
Subject: Most common keystroke loggers?

Frank Knobbe wrote:
> That's why I emphasized that the use of tokens should not only be made
> for initial authentication, but also for *each transaction*. Any
> transaction can be hashed with a one-time code generated by a token and
> sent as a control with the transaction parameters. Any MITM interception
> and modification will invalidate that hash thus voiding the transaction.

I agree.  I'd also like to point out that the "token" has to actually do 
the transaction processing for it to still be secure.  The PC at that 
point is more-or-less just another untrusted pipe.  The banking industry 
probably should be looking into making $40 USB co-computers with a 
2-line LCD display and accept/decline buttons.

Reason being that the user still needs to use the compromised computer 
to type in what the transaction is, and for how much.  The token needs 
to display the size and type of the transaction for approval.  I.e. if 
Grandma says to transfer $50 to PG&E, she needs to see that the token 
doesn't say transfer $1000 to Nigeria.

And I'd STILL not be happy with how easy it would be for clueless users 
to authorize such a transaction.  But I don't know how to fix that.

						BB