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
