PSD2: Is this the End of SMS-based Authentication?
Banks and payment service providers sometimes rely on SMS to verify the identity of a person who wishes to make a wire transfer or confirm a payment. They send an SMS message with a one-time password (OTP) to the person’s mobile phone, and the user has to enter this OTP into the application of the bank or payment service provider.
In this blog post I discuss whether SMS-based authentication will still be acceptable when the Strong Customer Authentication (SCA) requirements under PSD2 come into force. In August 2016, the European Banking Authority (EBA) published its draft proposal for the Regulatory Technical Standard (RTS) on Strong Customer Authentication (SCA). My analysis is based on this addendum to PSD2. We expect the RTS to be finalized by the EBA in the coming weeks.
In order to answer the question whether SMS-based authentication will be acceptable, we consider three scenarios for using SMS. We then discuss which of the three scenarios meet the requirements of the RTS.
Scenario 1: two-device authentication (2da)
In this case the user has two independent devices: one device to access a banking website or banking app, and another device to authenticate himself or a payment. The first device, which we refer to as the banking device, is typically a desktop PC, laptop, or a mobile device (e.g. phone, tablet) that runs a mobile banking app. The second device, which we call the authentication device, is a mobile device that receives the SMS. We assume that the user authenticates himself towards the banking website or app using the OTP from the SMS, and a password or PIN.
This solution is compliant with the RTS when it is used to logon to the banking website or app. The solution can be compliant for signing a transaction, but only if two conditions are met. First, the SMS message must contain the transaction details (e.g. amount, beneficiary). Second, the content of the SMS message must be protected against alteration during transit and receipt by the mobile device. This latter requirement is not easily met by SMS messages, as they are usually not protected.
Hence, in general, SMS-based authentication can be used for logon, but not for signing.
Scenario 2: two-app authentication (2aa)
In contrast to 2da, this approach does not rely on two different devices, but on two different apps running on the same mobile device. The apps interact via so-called app-to-app communication. We refer to these apps as the banking app and authentication app respectively. The authentication app requests and receives the SMS messages.
Standard SMS-based authentication is not compliant for two reasons. First, the SMS can be intercepted and altered in transit. Second, the SMS can be intercepted by malware on the mobile device, meaning the channel segregation requirement from the RTS is not met.
The solution can be made compliant if the content of the SMS message is protected using an end-to-end secure channel that terminates in the authentication app, so that only the app can decrypt the SMS. However this is not the standard approach.
Scenario 3: one-app-authentication (1aa)
In this case the user not only uses a single device, but also a single app to initiate and authenticate transactions. The user does not employ a separate authentication device or app.
This scenario is not compliant with the PSD2 requirements, because there is no channel segregation. The usage of SMS does not influence this.
Conclusion
We are still waiting for the final requirements on Strong Customer Authentication under PSD2. However if nothing changes compared to the current proposal, it is quite clear that SMS-based authentication will have a hard time meeting the requirements, especially those related to approving payments.
