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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ