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.
Q & A
Question 1: Full ack. Single-device SMS authentication is definitely not secure.
But also two-device SMS authentication (Scenario 1) is dangerous in case the customer has his banking app on the smartphone – what is very common: A trojan on the smartphone first wiretaps the banking password when the customer enters his banking account (he may check his account balance, for example). With the stolen password the smartphone trojan later secretly enters via smartphone Internet the banking account, fills the money transfer form with a malicious money transfer, submits it, intercepts the SMS sent from the bank to this smartphone, and finally submits within the secret banking session the OTP to the bank. The bank will execute the malicious money transfer.
I dont understand the distinction Scenario 2 und 3: SMS ist always send to the SMS-App on the smartphone?
Answer 1: The distinction between scenarios 2 and 3 is as follows: in scenario 2 (“2aa”), the user has two apps (a banking app and an authentication app that interact via app-to-app communication). In scenario 3 (“1aa”), the user has a single app (the banking app).
Scenario 3 is not allowed under PSD2 because it violates the channel segregation requirement. Scenario 2 is allowed in my opinion, but not when used with standard SMS to deliver an OTP to the authentication app. One reason is that the content of the SMS is usually not protected.
Your remark about scenario 1 is valid indeed. Although SMS-based authentication is probably compliant with the RTS requirements regarding authentication of the user when he accesses a payment account, it is not that secure. There have already been many attacks against SMS-based authentication used by banks, for instance.
Question 2: What will be the answers of the mobile operator to have a sms solution compliant with PSD2?
Answer 2: I don’t expect changes to SMS technology itself. Take into account that the usage of SMS is generally declining. Perhaps app developers will protect the content of SMS messages when they contain payment data.
Question 3: Could display technology on the customer’s card be used to generate a secure OTP?That would mean the customer has utilises a mobile device’s security protocols to access the application, and uses the OTP generated from their payment card to authenticate?
Answer 3: That would be two-device-authentication (2da), which indeed complies with the current requirements in the EBA’s RTS.
It’s important that the display card allows the user to enter the amount and beneficiary’s account number of the payment, and that the display card calculated the OTP based on the amount and beneficiary’s account number.
Question 4: Could an individual use the security on a mobile app to access and then use a OTP generated via display functionality on their payment card to authenticate? That would be two device authentication.
Answer 4: This is indeed two-device-authentication.
Source: Vasco.com
Banking 4.0 – „how was the experience for you”
„So many people are coming here to Bucharest, people that I see and interact on linkedin and now I get the change to meet them in person. It was like being to the Football World Cup but this was the World Cup on linkedin in payments and open banking.”
Many more interesting quotes in the video below:
