Re: limits of end-user "testing"

[Javier Fernandez-Sanguino <jfernandez () germinus com>]

Andrew van der Stock wrote:

> Transaction signing for my point of view is not C/R two factor  
> authentication, which as I said, not that useful. If you pay for trx  
(...)

> Phish threat model for trx signing / sms (A)
(...)

> Now, it may be possible that a user with a trx signing calculator may  
> answer the phone and give these details up, but I doubt it. A user  who 
> gets a SMS transfer message when they're not using the system  would 
> rightly either ignore it or ring the bank. Honestly, a phisher  in 
> Brazil or the former eastern bloc country would have almost zero  chance 
> to make an out of band connection with enough users to make  this 
> worthwhile, particularly since it would require a lot of access  to 
> telephones at the right time and knowledge of a lot of people's  
> numbers. Not impossible, but highly unlikely.

Now, I don't think you've considered the scenario of a wide VoIP 
deployment in which VoIP terminals are able to interact with the 
cellphone network and can provide the same services (i.e. SMS sent 
through VoIP phones, just like you can do that through regular, not 
cell-, phones in some telephone networks).

In that case, attackers have access to a lot of telephones at the 
right time. You don't have the phone number, but you can slightly 
change the MITM session so you ask for the user's number "for 
confirmation purposes".

And consider the "what if?" scenario of cellphones with zillions of 
differnet functions (think Java phones) connected to a 3G network 
which is, for all pursoses, IP based. In this case attackers can 
consider compromising cellphones, yes, cellphones, to do the MITM 
session there too.

Most cellphone networks are working towards UMTS/3G and that means 
that they will be eventually on the same "medium" that your average 
computer is meaning that they will get compromised/trojaned just like 
computers are. Oh, if cellphones would just nowadays just be the 
traditional "call-only, SMS-only" thingies they were years ago. Now 
you have a full computing platform, to which people download software 
into (think: games, sounds) and that can get compromised remotely 
(just look at how virus have spread through weak bluetooth 
implementations)

> MITM threat model for trx signing (B) / sms (C)

(..)

> Scenario B) IB platform asks user for transaction signing for  
> transaction B (usually based upon $, transaction reference and  
> destination account)

IB platform might be compromised as it might rely on the user's 
cellphone and that's already compromised (see above). If the phone is 
trojaned all bets are off.

(...)

> Scenario C is much stronger than no transaction signing, but it has  one 
> weakness - that the user's mobile number might be obtainable  somehow. I 
> really don't think this is practical on a widespread basis  like 
> phishing attacks for non-2FA / non-TS internet banking. For  retail IB, 
> SMS is acceptable right now until trx signing calculators  are available 
> to all IB users.

The problem here is that you assume that the phone network is 
completely separated from the Internet network so that, even if the 
Internet network is somehow compromised (trojan on the PC, MITM attack 
through pharming or phishing) then there is no way to get access to 
the phone network. That is true for your average cellphone network 
right now but it is not that much in the future of 3G networks in 
which cellphones are really just an end-node of a data communications 
network connected to the Internet which just happens to use radio 
circuits instead of your regular fiber or network cables.

In this environment, attackers will focus on compromising computers 
used for Internet banking, get the cellphone through some devious 
means (think: MITM sessions that modify the pages and ask for your 
cellphone number, even if the bank already has it) and then go for the 
cellphones. You could even imagine an scenario in which attackers are 
compromising *both* computers and cellphones and just check when 
somebody's computer (A) uses Internet Banking X to generate a 
transacion and recevies the session confirmation in cellphone (B). 
They correlate these and determine that A and B are associated for X, 
and that's again where the fun begins.

Maybe I'm being too pessimistic, but in a network where everything 
converges to a data IP-based network, all network nodes (from 
computers to cellphones) are feature full (and, consequentely, 
vulnerability-full) cellphones are as useful as an offline C/R 
mechanisms.

Indeed, you are raising the bar in the mid-term (just like if you are 
if using offline C/R) so that *your* bank is more difficult to attack 
than a different bank not using those mechanisms. But, again, given 
sufficient economic incentive, attackers will develop the tools to be 
able to compromise your carefully crafted authentication mechanism.

Just my 2c

Javier