The bank fraud blame game

Peter Gutmann pgut001 at cs.auckland.ac.nz
Mon Jul 2 04:15:58 EDT 2007


Adam Shostack <adam at homeport.org> writes:

>I'd suggest starting from the deployment, training, and help desk costs.  The
>technology is free, getting users to use it is not.  I helped several banks
>look at this stuff in the late 90s, when cost of a smartcard reader was order
>~25, and deployment costs were estimated at $100, and help desk at
>$50/user/year.

Banks here have been using SMS-based transaction verification for a few years
now (although not done very well, sigh) without, apparently, any real problems
(I've been trying to get figures for per-transaction costs out of them for a
while now, so far without any success).  Since the SMS-based system is just a
labour-intensive way of doing what I was proposing but using a cellphone
instead of a dedicated device, my guess is that the overhead won't be that
bad.  If it was, the banks wouldn't be doing it now :-).

(Using smart cards as a yardstick isn't terribly useful, as I mentioned in my
previous message they're really a deployment DoS mechanism, not a solution).

>I don't think smartcards (per se) are the answer.  What you really need is
>something like a palm pilot, with screen and input and a reasonably
>trustworthy OS, along with (as you say) the appropriate UI investment.

Smart cards are part of the problem set, not the solution set - they're just
an expensive and awkward distraction from solving the real problem.  What I
was suggesting (and have been for at least ten years :-) is a small external
single-function device (no need for an OS) that can't be compromised by
malware because there's no attack vector for the malware to get at it.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list