W8 IZ ~SCURE

[Dave Birch] I think most of us are familiar with services that use text messaging as a mean to authenticate a transaction. When I log in to PayPal, for example, it sends a six digit code to my phone and I have to type this code in to continue. It’s not PayPal’s only defence of course, because they have a sophisticated and well-developed infrastructure for fraud detection and prevention, but it presumably further tips the balance away from the fraudster. By itself, however, SMS isn’t the answer.

The lobby group for Australian telcos has declared that SMS technology should no longer be considered a safe means of verifying the identity of an individual during a banking transaction… Today, SMS authentication is used by three of the four largest Australian retail banks as a preferred mode of second-factor authentication for transactions to unfamiliar accounts.

[From Telcos declare SMS ‘unsafe’ for bank transactions – News – iTnews Mobile Edition]

I have to say this isn’t entirely unexpected. Security experts have long regarded SMS as vulnerable and from a risk analysis perspective seen it as only one of a group of appropriate countermeasures that need to be deployed in transactional systems.

I saw Charles Brookson, the head of the GSMA security group, make a very interesting point recently. Charles was talking about the use of SMS for mobile banking and payment services and he made the point that SMS has, to all intents and purposes, no security whatsoever. The spoofing of SMS originating numbers, in particular, is trivial (this is why M-PESA, for example, encrypts and signs all SMS messages using a SIM Toolkit application).

[From Digital Identity: SOS SMS]

Some months before this, I’d cautioned about that same issue in a post about SMS from that risk analysis perspective (which is not surprising, since the risk analysis of transactional systems is, frankly, something of a specialty of Consult Hyperion).

My guess is that this is a general result: once you train customers to perform some simple action in order to obtain security, they won’t do any of the other cross-checks and because they think (for no reason) that SMS is somehow secure, then SMS-based approaches may be even more exposed.

[From Digital Identity: Out of band, out of mind]

One of the reasons for writing this piece was that the attacks on SMS were not hypothetical. (And, naturally, I wanted to trumpet tha the SIM-based architecture that we had developed for M-PESA was not subject to these same frauds.) In fact, at the time of writing, substantial frauds had already occurred.

The customer’s SIM card gets falsely declared stolen by the fraudster at the service provider. A replacement SIM card is issued, rendering the customer’s original SIM card void. What this means is that all security messages and codes sent to the customer by Standard Bank are sent to the fraudsters who utilise the customer’s replacement SIM card. Using the bank’s secure OTP, the criminals were able to change and add beneficiaries and transfer money out of the customer’s account using the original information obtained through the phishing compromise.

[From Digital Identity: Out of band, out of mind]

So where does that leave us? Well, I think that we need to move away from the idea that text messaging is a solution and look at implementing a generalised, SIM-based, MNO-interoperable, PKI. We already know how to do this (because some MNOs already do it) so perhaps it needs a vehicle to get anywhere. The wallet plays such as Oscar seem to me to be an obvious mechanism, especially given everything that is being said about mobile wallets needing to evolve identity-based value-added services as payments are commoditised.

These are personal opinions and should not be misunderstood as representing the opinions ofÂ
Consult Hyperion or any of its clients or suppliers

These are the personal opinions of Consult Hyperion and its guests and should not be misunderstood as representing the opinion of its clients or suppliers. To discuss how any of the technologies discussed in this post can benefit your business, please contact Consult Hyperion.

Comments

  1. Steven Murdoch says

    I think what is happening here is that the telcos are trying to avoid liability for fraud which comes about through exploiting insecurity of SMS. I think this is fair enough, and understandable.

    The telcos never designed SMS to be secure, and the customer authentication system (e.g. against SIM replacement) is designed only to be secure enough to defend against someone trying to steal phone service. The banks are saving money and the telcos are worried about being blamed e.g. http://www.itweb.co.za/index.php?option=com_content&view=article&id=4754

    With M-PESA and other SIM toolkit-based applications, the telcos get a cut of the profit and can use this money to modify their security measures, so sounds much more incentive compatible. I’d say that this aspect of M-PESA is arguably more important than any security features implemented on the SIM.

  2. Pat Carroll says

    I believe that this is the first time that the Australian telcos have publically stated that sending a One-Time-Password by SMS is no longer a safe means of verifying a financial transaction. It’s great that they recognise that serious threats exist to this method of OTP delivery, and that recognition is a step in the right direction, but they, the banks, and security providers now need to go one step further and solve the problem.

    Whilst the fraud is sophisticated, the good news is that it can be prevented. Security solutions exist to detect whether a SIM has been swapped or a telephone number has been ported, and therefore it is possible to prevent a fraudulent transaction occurring.

    If we can prevent the fraud, customer trust will be restored, banks will save money, and telcos won’t be blamed for allowing the fraud to happen – it really is a win-win-win solution.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>