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