Next version of Android might introduce new security risks for online banking, 2FA, and more

Google is preparing new functionality for Android that will allow apps to retrieve and auto-fill security codes from SMS. Last year Apple introduced a similar feature to iOS and macOS, for which we discovered security risks for online banking, two-factor authentication, and other services. Will Google come up with a better design? In this post, we analyse what we know about this feature so far. 

The latest developer beta of Google Play Services (18.7.13 beta) contains code fragments that show a new Android permission to automatically retrieve verification codes from text messages. This feature has not yet been fully implemented, but the available code allows for some analysis and early evaluation for possible security risks, akin to similar risks we demonstrated in 2018 for the Security Code AutoFill feature in iOS and macOS.


It seems that Google is updating the “Autofill Framework”, introduced with Android 8.0 in 2017, to include the new functionality. Previously, this framework’s sole purpose was to support the autofill functionality of password managers in Android apps and websites. The code fragments of this new feature reveal the names and descriptions of the associated system setting and corresponding runtime permission requests, shown below.

A screenshot of an Android phone.
The likely UI of the new setting in Android to enable/disable SMS Code Auto-fill.
The picture of an Android runtime permission request.
The likely UI of the new runtime permission request in Android to deny or allow an application’s access to the SMS Code Auto-fill feature.

Android’s Autofill Framework for passwords allows apps and websites to self-declare whether and where they want to activate the password autofill feature, e.g. using android:autofillHints=“password” and android:importantForAutofill=“yes”. The picture below shows how Android autofill suggestions for passwords look. We can assume that the autofill suggestions for SMS security codes will look similar.

The picture of an Android phone with Password Autofill user interface.
Autofill UI displaying available user login credentials. If the user taps on “dataset-2”, this username and the corresponding password will be inserted into the app or website (source: Android Open Source Project).

The Risk of Autofilling Security Codes

SMS Code Auto-fill appears linked to Android’s Autofill Framework, which enables apps and websites to determine whether and where to make autofill suggestions. We currently don’t know all the details of the upcoming SMS Code Auto-fill in Android and can only re-create a likely workflow based on the available code snippets and its current implementation of password autofill. However, if this workflow remains unchanged with the introduction of SMS Code Auto-fill, there will likely be security risks similar to those we previously discovered for the Security Code AutoFill feature in iOS and macOS. This risk is particularly likely if Android’s Autofill Framework continues giving apps and websites control over whether to suggest to its users that security codes be auto-filled into a particular form field.

One such threat would be when an attacker manipulates Android into suggesting to autofill a security code on a different webpage than where the code is intended. Such an attack vector could be used for phishing of two-factor authentication security codes. These codes are commonly used to secure online accounts, including email and banking. Another threat is when the SMS contains context information which the user is supposed to verify before quoting the security code, such as the amount being transferred in an online payment. If the autofill suggestion removes this salient context information when presenting the code, the user is effectively encouraged to autofill the code without first verifying the correctness of said context information.

Automatically inserting security codes from SMS into their intended destination form field would be a significant improvement to usability. Users would be relieved from switching apps to access security codes in their SMS application, copy or memorise it, and then switch back to the intended destination app or webpage and quote the security code. However, for autofill to be secure, the insertion must be made in the intended app or webpage, and the recipient must have an opportunity to read and verify salient context information beforehand. We have informed our contacts at Google about our concerns.

Coincidentally, later this week I will give the first public presentation of our findings on the risks of Security Code AutoFill in iOS and macOS at the “Who Are You?! Adventures in Authentication Workshop (WAY)” on the 11th of August 2019 in Santa Clara, California, USA. I will be there for this workshop and during the co-located conferences SOUPS 2019 and USENIX Security ’19. Feel free to approach me and discuss the security issues surrounding the transmission of security codes via SMS, or anything else related to usable security and privacy.


This work has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 675730.

Leave a Reply

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