Account Takeover Risks with iOS Security Code AutoFill [With Video]

The last twelve months saw significant changes to the security and cybersecurity landscape for organisations that send security codes via SMS text message to their customers for the purpose of user authentication, transaction authentication, or device binding. This article by Andreas Gutmann, Researcher at OneSpan's Cambridge Innovation Centre, explains the steps such organisations can take to improve the security of their services and their user’s online accounts.

Account takeover (ATO) fraud, whereby a fraudster gains unauthorized access to a user's online account, is one of the biggest security threats many organisations face. Frequently used account takeover methods include social engineering, man-in-the-middle attacks, web browser attacks, public WiFi attacks, malware via a webpage or email attachment, and credential stuffing. The most common defence against account takeover fraud is the use of security codes for multi-factor authentication (MFA), transaction authentication, and to achieve device binding for mobile applications. Such security codes are commonly sent via SMS to the consumer’s mobile phone. In the past we discovered unique security risks in how iPhones handle such security codes using autocomplete features and Apple patched some of the reported auto-filling vulnerabilities at the end of 2020.

Security Code AutoFill feature in iOS 14: A partial fix for the vulnerabilities in iOS 12

The Security Code AutoFill feature in iOS is a convenience feature to remove friction in the user experience and, thereby, improve the consumer’s experience when handling security codes delivered via SMS to an iPhone (and MacBook / iMac if consumers share SMS between their devices). The feature automatically extracts security codes from the incoming SMS and provides an interface for consumers to insert those codes into websites or apps with a single tap.

Figure 1: Suggestion by the Security Code AutoFill feature in iOS to fill the security code 834956 into a form field on a website (not shown in this image) by tapping once on the autofill suggestion above the keyboard.

Crucially, consumers are no longer required to open their SMS application and read the SMS when they follow an autofill suggestion. Yet, the autofill suggestion itself does not provide essential contextual information about the received security codes that could be read from the SMS. As a consequence, consumers may be unaware of who sent them a security code and for what purpose. These circumstances can be exploited by malicious actors, as we previously demonstrated here.

Subsequently, support for a security technology called Domain Binding was added to the Security Code AutoFill feature with the release of iOS 14 in late 2020. This enables the sender of a SMS to specify the website on which a security code should be inserted. In the absence of this specification in the SMS, the Security Code AutoFill feature could suggest the insertion of the security code on any website. The required syntax for Domain Binding of security codes in SMS is visualised in the following illustration:

Figure 2: Illustration of the syntax required for domain binding with Security Code AutoFill. The first line is human-readable text intended for consumers who open their SMS application and manually copy the security code. The second line is machine-readable code, whereby @example.com refers to the web domain of https://example.com and #123456 is a security code intended for that domain.

Note that iOS 14 does not support the following devices: iPhone 5S, iPhone 6, and iPhone 6 Plus. These devices will remain vulnerable and will not benefit from Apple’s partial fix through the integration of the domain binding technology.

The following video is a recording of a lecture I gave on this topic at Northumbria University in the UK. In this lecture I go into more details about the security vulnerabilities we found in iOS and the partial fix implemented by Apple.

Improvements for Multi-Factor Authentication

Multi-factor authentication use cases are the main beneficiaries of the addition of domain binding technology to the Security Code AutoFill feature. Organisations that utilise security codes delivered via SMS for enhanced protection during their customers’ website logins can utilise the Security Code Autofill feature with domain binding to provide a usable and secure customer experience.

Security Tip:

Organisations with such use cases should embrace the domain binding technology and adapt the layout of their corresponding SMS. In the (rare) case that organisations use security codes via SMS for MFA on mobile applications, I’ve included an additional security tip below.

Necessary changes for device binding

The domain binding technology, as implemented by Apple, does not support use cases for mobile applications on iPhones, i.e. organisations can only specify websites but not mobile applications as the location where a security code should be entered. Thus, autofill suggestions of such security codes could appear on other applications and websites, such as phishing websites.

Security Tip:

To remedy this problem, organisations could phrase the corresponding SMS such that the security codes do not get recognised as security codes by iOS. Organisations can evaluate different layouts by sending SMS to themselves. If the security code is underlined with a thin grey line, iOS recognises it as a security code. As example, organisations can prepend a few letters which identify their organisation to their security codes in SMS and pre-fill those letters in the corresponding form field where it should be entered by the customer. Such an implementation for Bank A could use “BA-124680” when transmitting the security code “124680” and then pre-fill the symbols “BA-“ in the corresponding form field in their application. Yet, while iOS currently does not recognise such constructs as security codes, we cannot exclude the possibility that this might change in the future. Thus, it will be necessary to actively monitor such developments.

Ramifications for transaction authentication

Transaction authentication is the least supported use case for the Security Code AutoFill feature and brings the largest risks for organisations that deliver security codes via SMS.

The first issue is that domain binding technology is not appropriate to alleviate typical security risks associated with transaction authentication, for which the main security concern is transaction manipulation rather than phishing. Since the Security Code AutoFill feature decontextualises security codes, users would remain unable to verify that their transactions have not been manipulated when utilising that feature.

A further issue is that if the Security Code AutoFill feature detects an amount of money in a recognised currency it displays this amount next to the autofill suggestion, yet the feature does not recognise many currencies. As a consequence, customers in a country with a recognised currency (e.g. in the UK) could get used to seeing this information whenever they authorise a transaction. Yet, if an adversary were to change the currency to an unrecognised one when manipulating a transaction (e.g. change the currency from Pound Sterling GBP to Swedish Krona SEK), the customer could be deceived into thinking this was a code for Multi-Factor Authorisation.

Figure 3: The image on the left side shows an autofill suggestion for a transaction authorisation security code linked to a transaction of value GBP 100. The image on the right side shows an autofill suggestion for a transaction authorisation security code linked to a transaction of value SEK 1500.

Security Tip:

Organisations could phrase corresponding SMS such that the security codes for transaction authorisation do not get recognised as security codes by iOS. More information on this approach can be found above in the security tips for device binding use cases.

In addition, consider using stronger security mechanisms than security codes sent via SMS:

• For transaction authentication in online banking, software- or hardware-based authenticators could be used.
• For transaction authentication in online payments, Out-Of-Band authentication (OOB) or in-app codes for transaction authentication could be used instead of security codes via SMS.