Re: limits of end-user "testing"

[Andrew van der Stock <vanderaj () greebo net>]

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  
signing calculators and use them like C/R tokens, you've wasted a lot  
of money :) At my day job, we're skipping C/R tokens and moving  
directly to trx signing calculators. In volume, they're not a whole  
bunch more expensive than C/R tokens and they work a lot better. For  
now. However, until then, SMS transaction signing is cheap and  
effective. I wish I could find a public article on just how effective  
it is - but for now, you'll just have to take my word for it.

However, let's test the threat model for trx signing calcs and SMS.  
I'd like to see if my thinking stacks up in peer review.

Phish threat model for trx signing / sms (A)

Attacker logs in using phished credentials
Attacker submits transaction
Scenario A) IB platform asks for transaction signing (usually based  
upon $, transaction reference or destination account) or sends SMS  
token to registered user
Attacker does not have token, so has to establish an out of band  
session with the user and get the code within the time out (usually  
30 seconds)

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.

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

User logs in using real credentials
User submits transaction A but it is not submitted
Attacker submits transaction B instead

Scenario B) IB platform asks user for transaction signing for  
transaction B (usually based upon $, transaction reference and  
destination account)
- If the attacker presents "Trx A" details to the user, the  
transaction signing calculator produces the wrong auth code for Trx  
B. Fail
- If the attacker allows IB to present Trx B details to the user, the  
user should notice the change in $ value and hopefully destination  
details. Should fail as the user has to enter them into the calculator.

or

Scenario C) IB platform sends SMS token to the user for Trx B with  
basic details of the transaction (like $ value and the last four  
digits of the destination acct)
- If the attacker somehow has the registered mobile number for the  
user, they can try sending a fake look-alike SMS for trx A. If the  
user accepts this SMS instead of the real one (which would also be  
delivered), yes, the attacker will win

Scenario A is simply not likely as it requires OOB comms with each  
user and for the user to use their trx calculator or to give up the  
SMS they suddenly had without permission

Scenario B is really, really unlikely. Full stop. It requires too  
many things to know and go right for it to be worth the risk to the  
phisher. All trx signing token manufacturers I've looked at (in  
detail, and just this last couple of months) state that you get three  
to six things you can enter as part of the transaction signing and  
strongly sell their solutions on the basis that the $ figure is entered.

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.

thanks,
Andrew


On 17/11/2005, at 11:38 PM, Kurt Seifried wrote:

> > a) have two factor transaction signing (SMS or token based) to   
> > prevent unauthorized transfers via phishing
>
> This doesn't prevent phishing per se. I can setup a phishing site  
> that acts as a man in the middle proxy to the bank's site. You log  
> into my site, I log into the bank's site, get a challenge, send the  
> number to you the victim, you reply and I forward it to the bank,  
> voila.
>
> > I don't think two factor sign on authentication is much of a win   
> > against phishing, but it's better than passwords when you have to  
> > use  potentially trojan'd or untrustworthy computers.
>
> I think people are actually much worse off potentially beccause it  
> will strengthen the bank's case that they were diligent in  
> protecting you the customer, and despite failing they're not to  
> blame and you the customer are left holding the bill (or in this  
> case an empty account).
>
> -Kurt