Comments: Two-channel breached: a milestone in threat evaluation, and a floor on monetary value

I wonder --- couldn't, shouldn't, the bank sue Vodafone? After all, their lax security cost the bank 45k.

Posted by Hasan at December 8, 2011 03:34 PM

@ Hasan,

"I wonder --- couldn't, shouldn't, the bank sue Vodafone? After all, their lax security cost the bank 45k"

Err not realy.

Look at it this way Vodafone's security is about the costs incured for using the phone as a phone not as a security token.

Thus from Vodafone's point of view if their security lapse caused a large phone bill to be run up then they would be liable for the cost of those calls ONLY...

This mismatch of security drivers was something I missed back in the late 1990's when I proposed a method of doing two channel transaction (not communication path or entities) authentication.

Without going into all the details I've been warning against the use of mobile phones for two factor and side channel authentication for some time now, and certainly since the birth of smart phones.

If you think about it a lot of people do online banking on a smart phone (very very stupid see CarrierIQ debacle for just the latest reason) and the chances are that they also use the same smart phone for their "second channel". Which means it's not a second channel at all...

There is also the problem that many smart phone browsers leak information about the phone ID. quite deliberatly. And this ID can be fairly easily used to find out the phone number and other details.

The problem is that for a transaction to be secure it must be two way authentication on each and every transaction, and the authentication must be done not only through a secondary secure channel but also include the human into the security chain otherwise an attacker can do an "end run" around the security.

This requires the user to have a token into which they enter the transaction details it produces a secure messsage the user types in at the computer keyboard, the user then enters the response they see on the computer screen sent back by the bank into the token and then type in a second secure message from the token into the computer and send it back to the bank as a secure confirmation. Not only is it labourious process for the user, it's expensive for the bank to make such tokens. Oh and users have a habit of leaving the token at home when they need to use it at work or on a trip etc or worse doing the opposit...

Posted by Clive Robinson at December 10, 2011 07:53 AM

@ Iang,

Maybe it's time for you to do an analysis of what is actually required to do banking and other monetary transactions in something aproaching a "secure manner".

Posted by Clive Robinson at December 10, 2011 07:56 AM

Ha! Well I did that, I built a secure payments system back in the old days called Ricardo (see next post). It didn't have any of the discussed two factor or two channel things in it, only because it was well above the security required at the time. Partly this was because of a very small user community, also partly because it had strong back-end traceability that is easier in a 3 party payments model. Banking payment systems being a 4 party model, it requires inordinate degrees of discussion to get a one byte change in place... there being no surprise that they are problematic and holey from a security pov.

E.g., part of your question there is "who for?" If you talk about a bank, it would be "which one" and "which products." A security analysis is very personal, very particular.

Which leads into the whole "core business" question: a security analysis for a bank, which is about risk & security, shouldn't really be outsourced. Otherwise, you're outsourcing your soul...

Posted by Iang at December 11, 2011 07:14 AM

Hi,

Well the big problem I saw with phishing an MITM is the multiplication value by doing it large-scale for free. You can send out millions of phishing emails without much effort, and collect lots of money from lots of MITM´ed computers.
Now with this attack, you have to do phone-calls to the telcom providers. You can´t do millions of phone-calls to take over millions of mobile phones. So even if it is attackable, we are still back to a normal fraud scenario, and the barrier has been raised considerably. You have to attack both the PC with an MITM, take over the smartphone.
And I heard of telecom provider already increasing their security, by asking for things like the PUK when you want to transfer your number to a new SIM-card.
By the way, I heard about the same attack a few years ago from Turkey, so this is not new, and it has not become mainstream in the past few years.

So if you are paranoid about your money, ask your mobile phone operator how they verify your identity if someone else wants to transfer your phone number.

Posted by Philipp Gühring at December 11, 2011 09:42 AM
Post a comment









Remember personal info?






Hit Preview to see your comment.
MT::App::Comments=HASH(0x5583c2f44778) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.