A new feature for iPhones in iOS 12 – Security Code AutoFill – is supposed to improve the usability of Two Factor Authentication but could place users at risk of falling victim to online banking fraud.
Two Factor Authentication (2FA), which is often referred to as Two Step Verification, is an essential element for many security systems, especially those online and accessed remotely. In most cases, it provides extended security by checking if the user has access to a device. In SMS-based 2FA, for example, a user registers their phone number with an online service. When this service sees a login attempt for the corresponding user account, it sends a One Time Password (OTP), e.g. four to six digits, to the registered phone number. The legitimate user then receives this code and is able to quote it during the login process, but an impersonator won’t.
In a recent development by Apple, announced at its developer conference WWDC18, they are set to automate this last step to improve user experience with 2FA with a new feature that is set to be introduced to iOS in version 12. The Security Code AutoFill feature, currently available to developers in a beta version, will allow the mobile device to scan incoming SMS messages for such codes and suggest them at the top of the default keyboard.
Currently, these SMS codes rely on the user actively switching apps and memorising the code, which can take a couple of seconds. Some users deploy alternative try strategies such as memorising the code from the preview banner and hastily typing it down. Apple’s new iOS feature will require only a single tap from the user. This will make the login process faster and less error prone, a significant improvement to the usability of 2FA. It could also translate into an increased uptake of 2FA among iPhone users.
If users synchronise SMS with their MacBook or iMac, the existing Text Message Forwarding feature will push codes from their iPhone and enable Security Code AutoFill in Safari.
Reducing friction in user interaction to improve technology uptake for new users, and increase the usability and satisfaction for existing users, is not a new concept. It has not only been discussed in academia at length but is also a common goal within industry, e.g. in banking. This is evident in how the financial and payment industry has encouraged contactless (Near Field Communication – NFC) payments, which makes transactions below a certain threshold much quicker than traditional Chip and PIN payments.
As architects and designers, especially in computer security, we know that when making changes to one part of a system, we need to evaluate how this affects every other part that it interacts with. In the case of the upcoming Security Code AutoFill feature in iOS 12, this not only includes 2FA but also Transaction Authentication Numbers (TANs).
Transaction authentication, as opposed to user authentication, is used to attest the correctness of the intention of an action rather than just the identity of a user. It is most widely known from online banking, where it is an essential tool to defend against sophisticated attacks. For example, an adversary can try to trick a victim into transferring money to a different account than the one intended. To achieve this the adversary might use social engineering techniques such as phishing and vishing and/or tools such as Man-in-the-Browser malware.
Transaction authentication is used to defend against these adversaries. Different methods exist but in the one of relevance here – which is among the most common methods currently used – the bank will summarise the salient information of any transaction request, augment this summary with a TAN tailored to that information, and send this data to the registered phone number via SMS. The user, or bank customer in this case, should verify the summary and, if this summary matches with his or her intentions, copy the TAN from the SMS message into the webpage.
SMS based OTP, whether used for 2FA or transaction authentication, has been criticised for not being the most secure choice of technology. For example, in recent years the National Institute of Standards and Technology (NIST) initially publicly criticised SMS as a communication medium for secure authentication, labelling it as insecure and unsuitable for strong authentication. However more recently, they have softened their language and instead deprecated SMS 2FA. Yet, it’s still considered secure enough to be used for Strong Customer Authentication under the new EU Payment Service Directive 2.
This new iOS feature creates problems for the use of SMS in transaction authentication. Applied to 2FA, the user would no longer need to open and read the SMS from which the code has already been conveniently extracted and presented. The code is detected in a message based on heuristics such as proximity to the words ‘code’ or ‘passcode’, which are used in messages delivering 2FA codes and TANs alike. Security Code AutoFill on a webpage or in an app is then suggested if the input field is tagged accordingly.
Unless this feature can reliably distinguish between OTPs in 2FA and TANs in transaction authentication, we can expect that users will also have their TANs extracted and presented without context of the salient information, e.g. amount and destination of the transaction. Yet, precisely the verification of this salient information is essential for security. Examples in which Security Code AutoFill could pose a risk to online banking security include a Man-in-the-Middle attack on the user accessing online banking from Safari on their MacBook, injecting the required input field tag if necessary, or where a malicious website or app accesses the bank’s legitimate online banking service.
Even if the new Security Code AutoFill feature can distinguish between those SMS messages, users will inevitably get used to the convenience of this functionality. They might, very reasonably, expect similar convenience from other security technologies, not realising that this can be unrealistic. This can, in turn, discourage the uptake of more secure technologies, such as dedicated hardware tokens in transaction authentication.
We are excited about the anticipated improved usability of 2FA and hope that it will encourage more iOS users to adopt 2FA. But as a socio-technical environment, we can hardly predict the future. SMS based transaction authentication might well remain an established technology in online banking, with banks holding customers liable if they do not verify the transaction information. Whether it is justified to place the burden on users who behave as encouraged by the technology is both a philosophical and legal question.
At OneSpan and University College London, we are currently investigating the interaction between usability, friction, and security of transaction authentication. This project is focused on how misconceptions can be linked to security properties. We evaluate state-of-the-art technologies and investigate potential improvements. This project is funded by the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 675730.
Update (2018-06-13): After a discussion with Vincent Haupert in the comments, I’ve updated the article with more information how Secure Code AutoFill could be utilised in an attack, added references to Apple’s developer conference WWDC18, and updated the embedded pictures.
Codes sent via SMS aren’t secure to begin with.
At first, this feature seems to be a threat to transaction authentication via SMS. I have, however, two main doubts that all this is really relevant:
1) I do not think that SMS for strong customer authentication are compliant with the RTS of the PSD2 as they *at least* do not provide confidentiality. Even the VASCO article you mention states that “SMS-based authentication will have a hard time meeting the requirements.”
2) Both apps and websites have to explicitly mark their input fields to support this feature [1]. Yes, this feature also works with Safari on macOS, where SMS are synced automatically. This is, independent from all this, a problem [2].
[1] https://developer.apple.com/documentation/security/password_autofill/enabling_password_autofill_on_a_text_input_view
[2] https://link.springer.com/chapter/10.1007%2F978-3-662-54970-4_24
@Vincent,
On your point (1), I guess we will have to see. UK banks do seem to be continuing to use SMS, but by the time the SCA RTS is enforced (September 2019) there may be other options. At least initially each country’s regulator will have quite a bit of discretion as to how they interpret the rules.
On point (2), I don’t think that’s a problem for the attacker in the scenarios discussed. If the app or website is malicious, or there’s a MitM attack, the HTML for the input field can simply be modified to have allow autofill. The only thing the legitimate bank has control over is the SMS and I don’t know if this can indicate that it should not be autofilled.
ad 2)
No – Security Code Autofill is enabled by default. You have properties to enabled it always, but apple also use some heurstics methods and enable it to application even when developer don’t want it. Unfortunatelly there is no way to disable it (we contact with apple)
Hey Steven, you are of course right about (2). Thanks for pointing that out. I actually meant that this feature might educate customer’s to not verify the transaction details and to go straight for the OTP (unfortunately, most probably do this anyways). But as this is an opt-in feature, it at least won’t happen automatically. Maybe this point of view is too much on my mind due to a current research project.
Even though your attack scenario appears valid to me, I still don’t see much value of a transaction authentication method that takes part on the very same device. One problem are vulnerabilities and another problem are the design decisions of these platforms. On Android, the situation—particularly for SMS, but also for app-based authentication—is even worse, particularly due to its accessibility service.
@Vincent,
Thank you for your comments and interesting discussion points.
I think we all agree that SMS is not the most secure method for transaction authentication. Yet, I believe that this method will stay with us as long as alternatives technologies are inaccessible to some users.
Even in developed countries such as the UK, only 83% of adults have broadband (fixed and mobile). And while 94% of adults in the UK have a mobile phone, only 76% of adults have a smartphone.
(Source: OfCom https://www.ofcom.org.uk/__data/assets/pdf_file/0017/105074/cmr-2017-uk.pdf)
Thus, there’s a considerable number of people in the UK who’d need to rely on public WiFi (or Internet cafes) to access their online banking. Using separate hardware would, in most cases, require hardware tokens, which usually need to be purchased. Some banks provide their customers with free hardware tokens, but usually only on accounts with a monthly fee. People who can’t afford that, need to rely on their mobile phone. And without a smartphone they could only receive a TAN via voice call or SMS.
Legislation such as PSD2 puts limits on the use of SMS in transaction authentication but only applies to European countries. I expect to see more use of this method outside the EU and for a longer time than inside.
The article says that SMS-based authentication is “still considered secure enough to be used for Strong Customer Authentication under the new EU Payment Service Directive 2”, and refers to a blog post that I wrote.
However my blog post mentions the opposite, namely that SMS-based authentication may not be compliant with PSD2’s dynamic linking requirement. It is not straightforward for SMS to meet the confidentiality and integrity requirements of dynamic linking.
@Frederik
Thank you for your comment.
The reference to your blog post is intended as further reading on that topic, which is only marginally related to the topic of my blog post. This gives the interested reader access to more details, for which your blog post provides a nice and intelligible illustration of challenges faced by SMS under PSD2.
Yet, when reflecting upon your comment, I gained awareness how this could be confused and am happy to provide some clarification. In doing so, I’m focused on the interested reader and assume that professionals and experts working with this are already aware of the relevant and detailed documentation: The Regulatory Technical Standards (RTS) for Strong Customer Authentication (SCA) (and Common and Secure Open Standards of Communication (CSC)) under the Revised Payment Services Directive (PSD2).
The Regulatory Technical Standards (RTS), which come into force in September 2019, define specific security measures and are more concrete than the PSD2. This clarifies, among many other things, the requirements for two independent authentication factors and dynamic linking of authentication codes (a.k.a. TANs) for remote transactions, e.g. internet and mobile payments. A breach of these requirements (by a Payment Service Provider) can allow a victim of fraud to claim full reimbursement. It further specifies a number of exemptions from these requirements, such as
Focusing back on the use of SMS to deliver Transaction Authorisation Numbers, we can see how the above exemptions continue to provide space for it within the EU under PSD2. I do not claim that this technology will remain in widespread use within the EU, but the argument made in the blog post was that even heavily security focused legislation such as PSD2 didn’t completely rule it out, so we as researchers should expect to keep seeing it being use worldwide in the foreseeable future.
I want to stress that these clarifications are still in a simplified form and not comprehensive. Providing an exhaustive and detailed overview would fill a blog post on it own, and there are more knowledgeable people that are more suitable to do it.
SMS authentication is considered the weakest of the various authentication methods employed during 2fa authentication.
Whist it is still easy to implement and an improvement on username and password only, there are better and more secure alternatives available.