It's Too Easy for Fake Android Apps to Steal Passwords

UPDATED 5:25 p.m. EDT Sept. 27 with information about how password managers operate on iOS.

Top password managers can be fooled by fake Android apps into coughing up usernames and passwords, Italian researchers say.

Credit: Sharaf Maksumov/Shutterstock

(Image credit: Sharaf Maksumov/Shutterstock)

The problem exists because many password manager apps on Android, including Dashlane, LastPass and Keeper, simply use a third-party app's package name — the app name that other Android apps see, rather than the name the user sees — to determine which set of credentials should apply.

But there's nothing preventing a fake Android app from giving itself a name that includes the words "face" or "facebook". That could happen often enough to fool a password-manager app, which would then suggest that you autofill your Facebook credentials into the app.

"We found that it's easy to trick PMs into believing that a malicious app is actually the legitimate (for example) Facebook app: this triggers an auto-suggestion for credentials," researcher Yannick Fratantonio wrote on Twitter.

MORE: Best Password Managers

If you click "OK," then the password manager could input your credentials, and the fake app could then send that information to a remote attacker. The attacker could then log into your Facebook account, lock you out, and take it over. Using Google's own Instant Apps feature would only speed up the process.

Meanwhile, the 1Password Android app doesn't suggest specific credentials, but lets you choose among all stored credentials. So a fake Facebook app wouldn't need to have "facebook" in its name — it would just have to look enough like the real thing to fool you.

Google's own Smart Lock for Passwords, which works on Chrome and Android, is largely immune to these attacks because it uses a different method to identify third-party apps. (The researchers didn't test any other Android password managers aside from the ones mentioned here.)

The researchers urged that Google let password-manager app developers use that method in the future. They also suggested that password managers not interact with Instant Apps at all, because Instant Apps are too susceptible to abuse.

Fixes on the way

LastPass and Keeper have already patched their Android apps to mitigate, if not fully, fix the flaw. 1Password told us that they're working on it, and Dashlane told us that they've also mitigated the problem by adding more user notifications.

We've also reached out to Fratantonio to ask whether iOS password managers might be vulnerable to similar attacks. Meanwhile, there's no evidence that any malicious hackers have used these attacks "in the wild."

"We have already implemented changes to our LastPass Android app to mitigate and minimize the risk of the potential attack detailed in this report," a LastPass spokeswoman told Tom's Guide. "Our app now requires explicit user approval before filling any unknown apps, and we've increased the integrity of our app associations database in order to minimize the risk of any 'fake apps' being filled/accepted."

For its part, Keeper explained in a blog posting that it had added a pop-up message that appeared when a user links an app to existing credentials, warning users that Keeper could not "validate the authenticity" of apps. The patch was applied in July with Keeper for Android 12.1.1.

Dashlane told Tom's Guide that it "took immediate steps to reduce the risks to our users and decrease their potential exposure."

We asked for further clarification, and were told that Dashlane "started notifying users before they completed autofills and also prompted them to our Help Center to provide them more information on the autofill process and how they can protect their data from potentially malicious apps.”

Fratantonio, of the EURECOM research center in southeastern France, told ZDNet that his team made and gave Google code that would help third-party password managers use Digital Asset Links, the same system that made Google's own Smart Lock immune to the researcher's attacks.

1Password told Tom's Guide that it was taking exactly this approach.

"We are moving forward with what [the researchers] recommended: Using Digital Asset Links (DAL)," 1Password Chief Defender Against the Dark Arts Jeffrey Goldberg told Tom's Guide.

"We had not done so earlier because the tools for doing so were not as robust as they have now become," Goldberg added. "We also wanted to make sure that we implement DAL in a privacy preserving way. If someone has a login for we would rather not know about it ourselves.

Guessing incorrectly

The main issue, explained in a blog posting by the researchers (Simone Aonzo, Alessio Merlo and Giulio Tavella of the University of Genoa, along with Fratantonio), is that password managers are really designed for desktops, web browsers and websites. Mobile password managers shoehorn this process into Android by associating user credentials — usernames and passwords — with websites, not with mobile apps.

Because of this, every new app that a mobile password manager encounters can be "mapped" to a website for which the password manager has a set of existing credentials.

Dashlane, Keeper and LastPass try to make things easy for you by reading the new app's package name to guess which website the new app might be associated with. So, for example, if any of these three encounters the legitimate Facebook app — whose package name is "com.facebook.katana" — it correctly guesses that the app is associated with

LastPass and Dashlane do this if any part of the package name looks like "facebook", which is too forgiving. With Dashlane, "the package name 'xxx.face.yyy' triggers an auto-suggestion for credentials," the researchers wrote. With LastPass, "com.facebook.evil" worked.

Keeper handles things better. It adds the package name to the standard Google Play Store URL to make sure the app has a legitimate Play Store page — e.g., "".

If the Play Store page exists, Keeper checks it for the listed developer website — in this case, "". If that website matches one for which Keeper has stored credentials, then Keeper will suggest that you autofill the app form fields with your Facebook credentials.

However, a shifty app developer could also list "" as his or her developer website — in which case Keeper would also auto-suggest your Facebook credentials.

"We were able to create an app (with an arbitrary package name) and to publish it on the Play Store specifying as the developer's website," the researchers wrote in their academic research paper. "In this way, when a user opens our app, the Facebook credentials (and only these credentials) are suggested."

1Password, on the other hand, leaves it all up to you. When it encounters a new app, 1Password simply presents you with a list of all your stored credentials, and lets you choose one.

"In other words, it is possible to autofill any requesting app with any stored credential," the researchers wrote.

That does put more control into the hands of the user. But humans are easily fooled, and a phony Facebook app wouldn't even need to include "facebook" in its package name to get your Facebook credentials — it would just have to look a heck of a lot like the official Facebook app. You would choose your Facebook credentials from 1Password's list, and the hacker's work would be done.

Hidden password fields

A malicious app wouldn't even need to visibly display a password field to capture your password, the researchers found. The app could present you with a username field, but then "hide" the password field by setting the field to 1-percent transparency, or by making it the same color as the rest of the screen, or by making it only one pixel square, or by even using the "invisible" tag.

You wouldn't see the password field, but the password manager would, and it would pop up a suggestion to enter stored credentials. Because you'd only see the username field, you wouldn't realize that you were also giving up your password.

Instant bad karma

The researchers really didn't like what happened with Android Instant Apps. That's a relatively new Android feature that lets you "try before you buy" with regard to apps.

Click on a link, which can be embedded in a website or in another app, to the app developer's website, and a lightweight version of the app in question will open up on your device without anything being actually installed.

The problem is that Android password managers can't tell the difference between an Instant App and a real app, and will auto-suggest credential-filling for either.

"It is possible to combine mobile password managers and Instant Apps to build new phishing attacks," the researchers wrote.

They carried out their own phishing attack by loading a malicious webpage of their own making into Chrome for Android. The webpage had a Facebook "Like" button, commonly found on thousands of sites.

Click the "Like" button, and a suggestion pops up to open the link with an app. Click "Open App," and an Instant App loads. LastPass then suggests that the user autofill his or her Facebook credentials into the Instant App — which could have come from anywhere.

To turn off Instant Apps on your Android device, go to Settings > Google and look for "Instant Apps" or "Google Play Instant." Click on that and select "None" under "Instant Apps account."

UPDATE: Fratantonio and Aonzo responded to Tom's Guide (and other people) on Twitter and via email to say that they had learned that iOS forces password managers to use a system similar to Google's DAL.

In order to use iOS 12's autofill feature, apps must be "bound" to specific websites during app installation, and sites that comply do so by putting specific files on their websites that these iOS apps can access for this purpose.

For example, here is Facebook's Apple App Site Association file:

"From quickly reading stuff around, it also seems that Autofill API doesn't work for most apps yet because of missing mapping entries, but that's good: web developers will start pushing for it," Fratantonio tweeted. "This seems the right way to me.

Paul Wagenseil

Paul Wagenseil is a senior editor at Tom's Guide focused on security and privacy. He has also been a dishwasher, fry cook, long-haul driver, code monkey and video editor. He's been rooting around in the information-security space for more than 15 years at, SecurityNewsDaily, TechNewsDaily and Tom's Guide, has presented talks at the ShmooCon, DerbyCon and BSides Las Vegas hacker conferences, shown up in random TV news spots and even moderated a panel discussion at the CEDIA home-technology conference. You can follow his rants on Twitter at @snd_wagenseil.