1Password for Android Autofill vulnerability?
When I recently opened the 1Password app on my Android device, I was greeted by a pop-upmessage:
One more thing!
Enhance your 1Password experience by enabling the following...
[And one of the options is:]
Autofill: Fill and save usernames and passwords in apps.
However, I also recently read an article on the Sophos NakedSecurity blog:
Android password managers vulnerable to phishing apps
28 Sep 2018
https://nakedsecurity.sophos.com/2018/09/28/mobile-password-managers-vulnerable-to-phishing-apps/
The article discusses a recently discovered vulnerability and concludes with a suggestion to turn the autofill feature off.
So we have conflicting advice
The 1Password message is suggesting that we turn autofill on to enhance our 1Password experience, and the NakedSecurity team is suggesting we turn the autofill feature off in order to protect against this vulnerability.
Any comments from your team?
Thanks!
Here are some of the relevant passages from the NakedSecurity article:
"Researchers have discovered that several leading Android-based password managers can be fooled into entering login credentials into fake phishing apps.
"Password managers can be used to create, store, enter and autofill passwords into apps and websites. As well as allowing users to maintain scores of strong passwords, password managers can also provide some defence against phishing – their autofill features will enter passwords on sites they’re associated (and their mobile apps), but not on fakes.
"The University of Genoa and EUROCOM’s Phishing Attacks on Modern Android study explores the difference between accessing a service through its mobile app and accessing it through its website on a desktop browser.
"With desktop browsers, when a site is visited for the first time the password manager creates an association between its domain (verified by its digital certificate) and the credentials used to access it.
"However, when somebody uses the website credentials to log in to an app, the process of verifying the app is more complicated and potentially less secure.
"The main way password managers tell good apps from bad apps is by associating the website domain for that app with the app package name, a metadata ID checked using static or heuristically-generated associations.
"The flaw is that package names can be spoofed – all the attacker has to do is create a fake app with the correct package name and the password manager will trust it enough to present the correct credentials.
"The researchers found that several popular password managers were vulnerable to this kind of mapping weakness – LastPass, 1Password, Dashlane, and Keeper – with only Google Smart Lock (which isn’t primarily a password manager) able to resist...."
[The article concludes with:]
"Naked Security believes that using a password manager is still one of simplest and most effective computer security steps you can take, and closer integration with mobile apps makes using a password manager easier.
"You are much more likely to be burned by password reuse than by an autofill attack on a fake app. However, if you are concerned about this kind of attack, or similar attacks that exploit autofill features using hidden password fields, don’t abandon your password manager, just turn autofill off."
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
That is a very good question, @Toshen.
Short answer is that in the case of 1Password, you should turn auto-fill on.
Now for the longer explanation of why that answer is correct.
First, do no harm
We took a very different approach to this problem than some other password managers. 1Password will not suggest a specific login to use if we can't trust the source of the information. This is why 1Password doesn't make such specific suggestions in these cases. Instead 1Password will let you chose from among all of your logins instead of making it seem as if some particularly ones are the "right" ones when we can't actually be confident that they are the right ones. This is acknowledge in the full research paper, that "this attack is less practical [against 1Password] than the other ones as the attacker does not have fine-grained control over the list of credentials that are auto-suggested."
No password manager can promise to prevent all phishing (although well designed ones offer a great deal of protection) , but we want to make it sure that 1Password never enables enables phishing. So using 1Password should never make you less safe than not using it. This design principle not only was behind our decision to not offer auto-fill suggestions in this context, but is also why we never allowed automatic auto-filling on the desk top despite it being a frequently requests (mis)feature.
Anyway, if we can't prevent being manipulated into making incorrect auto-suggestions, then we won't make any auto-suggestions.
Reliable bindings
The paper advocates the use of Digital Asset Links (DAL) to get reliable bindings between the apps and websites. This is something that is built into iOS, but is newer and less prevalent for Android. When we first looked at DAL the resources weren't fully mature, and so we decided to hold off on it at that time. When Aonzo et alter's paper (PDF) was released, we started to take another look. (We only learned about this then.)
Checking privately
There is potentially a slight privacy concern with using Google's DAL API. If 1Password checks to see whether apps X is linked to domain Y, performing that check would let Google servers know that 1Password on your device is performing that check. And so it is letting Google's service know that you have opened that app and triggered this check. This lets them know that you are opening X and going through its authentication process.
This is probably not much more information than they already have. They know what apps you have and you will almost certainly be using Google DNS servers, and so this is only a tiny amount of additional information; but this is still the kind of thing that we need to consider when using the API. Our current thinking is to give DAL another try. The reasons that we didn't adopt it early don't seem to apply now. But I am not going to promise any features until they are delivered.
Although some communication went astray early on (we weren't aware of the study until it was made public), I've had great conversations with the authors since then, and I'm looking forward to meeting them personally is a couple weeks at ACM CCS 2018.
0 -
Thank you for the clear and thorough answer.
0 -
Glad Goldberg was able to help. It's definitely something that's always on our mind as we build 1Password. We can't stop people from putting sensitive information where they shouldn't, but we do want to ensure that 1Password doesn't encourage risky behaviour. Stay safe out there! :)
0
