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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <a3a7d6660705140431x52ef4ce6pd44821b5286d4e10@mail.gmail.com>
Date: Mon, 14 May 2007 12:31:30 +0100
From: imipak <imipak@...il.com>
To: "Omar A. Herrera" <omar.herrera@...sg.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Defeating Citibank Virtual Keyboard protection using screenshot method

Omar A. Herrera wrote:


>> Rogier Mulhuijzen wrote:
>>
>>> I'm surprised that banks use such simple things as passwords. Banks here
>>> in the Netherlands use things like one-time PINs, and challenge/response
>>> stuff that uses your chipped bank card. Seems a little safer to me.

[...]

> Nick Fitgerald wrote:
>> Sure, they're a lot more expensive and a lot more "high-tech" but
>> unless they are doing end-to-end client and server authentication and
>> strong crypto _AND_ have their own input and output devices that cannot
>> be interfaced from the host OS _AND_ are required for verifying
>> (virtually) every step of every transaction (in other words -- if you
>> have any of the real-world implementations of banking OTP cards used
>> anywhere in the world, the answer is "no"), they are effectively no
>> better than the Citi OSK's as they are trivially MiTM'ed via on-client
>> malware.
>>
> This is true, and doing it right is even harder than what it seems.
> Providing an independent hardware security module (i.e. with its own
> input/output) for the client would be probably the easier part if we forget
> about the cost.


Something like this?

    http://business.guardian.co.uk/story/0,,2077984,00.html

"All the big [UK] banks [...]  are to demand that online customers use
"chip and pin at home" devices to identify themselves before moving
money out of their accounts, in the biggest change to personal banking
since chip and pin replaced signatures at the checkout.

"Millions of hand-held card reading devices will be sent, free of
charge, to bank customers over the next six months in the latest
attempt to fight online fraud. Regular internet users will be the
first to receive the devices, in which they will have to place their
debit card before making any online banking transactions."



I haven't looked at these in any detail but superficially they seem to
meet your criteria - end-to-end crypto, bidirectional auth, etc. I'd
be surprised if there were any obvious & trivial attacks against these
devices such as malware MitM.

Finally, systems that are only vulnerable to concurrent MitM attacks
(where Dr Evil is replays the client's auth to the bank and vice
versa) presumably restrict the attacker to defrauding one victim at a
time, drastically reducing their takings and thus incentive, as well
as the damage to bank and customer.



> But at the other end, within the bank, there are usually
> hundreds of applications that have different kinds of interfaces through
> which transactions flow.


The risk of insider fraud within the bank's own back-office systems is
much better understood, better controlled, and the threat level has
presumably been fairly constant for the last 20-30 years. (The banks
have had some close calls over the years eg:

http://www.theregister.co.uk/2005/10/21/phantoms_and_rogues/ but
that's out of scope.)

OSKs, CPE chip-and-PIN readers, one-time passwords and smart tokens
are all trying to mitigate the client-side risk.

cheers


/i

-- 
   "I guess we'll have to test what's darker than ourselves
    We said the truth was fixed, it's lost without a trace"     - MSP

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ