Re: Solution for man-in-the-browser

[Jeremy Epstein <jeremy.j.epstein () gmail com>]

Just to echo the other comments - there's already malware out there
that handles per-transaction authorization codes and substitutes in
its fraudulent transaction for the real one.  (If you look at some of
the banking thefts against small & medium businesses, that's what's
happening.)  So this scheme wouldn't even address existing threats,
much less new ones.

Having said that, if the organization being defended is obscure enough
and/or the potential transaction value is low enough, there may be
little enough value to an attacker that even an easily bypassed
mechanism such as that proposed might have a deterrent effect.  Just
as a lock on the front door is no protection against even a moderately
sophisticated thief (who knows how to lock-bump, for example) doesn't
mean that there's no value in keeping the door locked.  It's just
adding a measure of obscurity.  The question is whether the additional
obscurity increases the work factor for a potential attacker enough to
compensate for the additional effort to the user.  Since in this case
it looks like the user would have to enter a one-time transaction
code, the answer is almost certainly "no".

--Jeremy
_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________