There is a password manager app for Android that I'm considering using, that reads a database format for a popular desktop password manager. There is one part of this app that is giving me pause; I've approached the author about the issue but the author does not seem very concerned about it. I want to make sure I'm not just being paranoid.

To use this app, you give it the master password for your password database. The app creates a two-part key by combining a 4-digit PIN with a random 256-bit key stored in Google's cloud-based application data. This key is then used to encrypt the master password locally. When you use the app, you enter the PIN, the app retrieves the cloud-based key, and uses both to decrypt the master password and unlock the database. There are no other options for unlocking the database. The cloud-based key is never stored on the device, it is only ever used in memory. The encrypted master password is only stored on the device, it is never uploaded to the cloud.

I'm willing to give the author benefit of the doubt here and assume the key is generated securely, and for the sake of argument I will give Google the benefit of the doubt and assume that this one app is really the only party they'll ever give the data to. Yes, I know this may not be a realistic assumption, but an Evil Google is not high on my list of concerns. If these assumptions hold, then as long as my phone is secure, then only the app on my phone can get at the cloud key directly, and therefore only the app on my phone can decrypt my master password.

However, I thought up this scenario:

  1. Attacker steals phone.
  2. Oooh, look! A password database! Drat...it's locked!
  3. Attacker roots phone.
  4. Attacker launches the password manager app.
  5. Attacker enters a single PIN at random.
  6. App downloads cloud-based key.
  7. Attacker uses root privileges gained above, to dump process memory for the app.
  8. Attacker reads cloud-based key from memory dump.
  9. Attacker brute-forces PIN/cloud-key combinations offline.
  10. Password database is unlocked in milliseconds or less.

Am I right to worry about this attack, or is it implausible/preventable somehow? Right now it's the only thing keeping me from trying the app. I'm not an especially high-value target or anything.

A follow-up question: I'm trying to convince the author to add an option NOT to store the master password, and rather to just ask for it every time I open the app. Assuming the password is secure (I use a phrase of 7 words chosen at random, with dice, from an unabridged hard-copy dictionary), and assuming the password is never stored anywhere, would this likely keep my passwords secure from an attacker who obtains my phone?

I know that root access on a phone can attack any running and unlocked password manager, but in that case, I simply need to (a) not root my phone myself, (b) be careful not to install malware, and (c) carefully lock my database after use. However for this app, there does not seem to be anything I could do to prevent the attack unless I immediately notice my phone is missing, and immediately delete the cloud-based key.

  • 1
    This question about LastPass seems to imply that a similar scheme is secure only as far as the device's physical security is not compromised. I don't think it's an exact duplicate because the method is different (see the answer describing how LastPass avoids storing the password locally; in this case I don't think there is any cloud-stored encrypted master password).
    – Ben
    Commented Apr 6, 2016 at 15:43
  • 1
    What do you mean, you don't use full device encryption with a sufficiently complex PIN? ;-)
    – Jeff Meden
    Commented Apr 6, 2016 at 16:14
  • 1
    I'd love to use encryption. When I got the phone I tried enabling it 3 times and each time it broke something; I had to factory reset and start over unencrypted. So no, it's not encrypted. Although it does have a PIN lockscreen, I assume the old Android I have probably has some vulnerability or another to bypass it somehow.
    – Ben
    Commented Apr 6, 2016 at 16:21
  • @Ben Just curious, are you on stock Android or a custom ROM? My old HTC has that issue, but it was directly related to my custom ROM not playing well with the encryption. Commented Apr 7, 2016 at 17:07
  • Stock Android. Well...the (probably modified) one my carrier provided, anyway. But it's a low-end Kyocera phone that also has other issues (some of which have been fixed for several months, if I can ever get an update) so a screwy ROM is still a likely cause.
    – Ben
    Commented Apr 7, 2016 at 17:23

3 Answers 3


There are a number of mitigations you aren't considering. To directly answer your question: Yes, provided an attacker has full purview over all phone activity (some android phones are difficult/impossible to "root" so this is not a given even at that level) they could capture the cloud part of the key and brute force the combinations within a short time (probably more than milliseconds since they have to test-decrypt the password file with every pass, there is no magic indicator that it worked after computing the key).

But, most cloud password managers allow for remote privilege revocation (i.e. disallow device from fetching key from cloud until it fully authenticates again) which should be practical for you to execute before the attacker roots your device, since it is very simple to do.

Second, mobile device management allows you to permanently wipe the contents of your phone should you find it stolen, again only effective if you act quickly but still should be possible to log in and hit wipe device before the attacker has even had a chance to size up his options with attacking your device.

Third, full device encryption with a strong pin (available in all android versions for a few years) would negate all of the attack vectors in one go, since the attacker would be required to know your pin in order to do anything to the phone at all.

  • 1
    So: technically possible, but probably not going to happen any faster than I can revoke login credentials preventing the attack.
    – Ben
    Commented Apr 6, 2016 at 17:10
  • 4
    Bingo. And honestly unless you're on some sort of watchlist, someone stealing your phone will only put as much effort into it as it takes to sell it for some quick cash.
    – Jeff Meden
    Commented Apr 6, 2016 at 17:13

Am I right to worry about this attack, or is it implausible/preventable somehow?

The attack is semi-plausible, assuming that the user can get past your device's lockscreen (because if you aren't securing that, you have bigger issues). It is not especially likely, as it requires:

  • your device to be stolen

  • for the thief (or a fence) to want to get at the contents of the device, rather than just factory-reset it to be able to sell it

  • for the thief (or a fence) to get past the lockscreen

  • for the thief (or a fence) to have the skill set to do what you describe

  • etc.

Hence, whether it is "right" for you to "worry about this attack" is really up to you.

I'd be far more concerned about the app being useless without an Internet connection.

I'm trying to convince the author to add an option NOT to store the master password, and rather to just ask for it every time I open the app

I'd suggest that you use an existing open source password manager that already implements this. That would seem to be easier.

would this likely keep my passwords secure from an attacker who obtains my phone?

That depends a bit on how the password manager is implemented.

A decent one will use a key-lengthening or key-stretching algorithm to impose costs on trying a passphrase. For example, one backed by SQLCipher for Android would use 64,000 rounds of PBKDF2. That helps defend against certain types of attacks (e.g., rainbow tables IIRC) and forces attackers to go through the actual "front door" (e.g., the SQLCipher API) in their brute-force attempts. The cost means that you might only be able to test a few million passwords per day, and in that case, a sufficiently-long passphrase makes it impractical for anyone to break in, at least without resorting to the ever-popular $5 wrench.

On the far other extreme, if the password manager stores its master password in plaintext as a separate file, the attacker has a somewhat easier time guessing the master password.

  • Thanks. I'm trying to avoid mentioning the specific app I'm talking about to prevent any misunderstandings I have from impacting the developer. But as I mentioned, the app itself uses an existing database format, which I consider fairly secure. As for offline access, if I'm not online, it's true I can't get my passwords; but if I'm offline, I also probably don't have access to whatever it is that I'm trying to log into anyway. There are alternative apps (I'm using one) but this app provides some additional integration features that I'm interested in using.
    – Ben
    Commented Apr 6, 2016 at 16:07
  • I was also under the assumption that a PIN-based lock screen on an unencrypted device could be bypassed, especially for a phone that hasn't received updates in almost a year, because Android. :-(
    – Ben
    Commented Apr 6, 2016 at 16:17

[Disclosure: I work for AgileBits, the makers of 1Password]

As others have pointed out, there are lots of things that need to go wrong for the attack that you describe to happen. But from what you describe (I haven't studied the product itself in sufficient detail to comment on anything other than what you describe), an attacker can end up with something to crack with only a PIN.

You may have a different threat model than most users, but your threat model is certainly coherent. To those pointing out that the device should be locked, that is certainly true, but the design of a password manager should anticipate that data stored on the device can be captured.

One thing that seems like a more plausible attack is on the authentication required to retrieve the key. Presumably there is a long term secret stored by the app on the device that combined with the PIN is necessary to authenticate to the server. So I don't see why the attacker needs to perform the memory attack on your device if they can obtain the long term secret authentication secret. Once they have that, they can try to retrieve the encrypted key without needing anything from your device.

Again, I am commenting based on your description of the system. I have not studied the actual system, which very well may have defenses against that sort of thing.

Anyway, I believe that there should always be an option to require your master password every time you unlock your data.

  • Interesting...so really, the attack may be able to be simplified to not require root. I don't have much experience with such things, but I understand you can extract all the files on the device using adb backup, without having root. If that's the case, and if the app simply stores off an OAuth token or something, then I furthermore assume one could write code to use that token to retrieve the key directly from the Google Drive app data folder. I'm not sure how Google controls access to the "hidden" app data; maybe they have protections against such things.
    – Ben
    Commented Apr 7, 2016 at 21:59
  • Anyway, there is one option for requiring the master password: it's not intended to be used this way, but there is a button in the app to remove the database information from the app (intended for switching to a new database or something). Using that feature will delete the encrypted settings for the database. So I can use it as a "log out" button every time I use the app, if I like. It may have some rough edges since the app wasn't really intended to be used that way, but it will be like the linked LastPass question, where it remains connected to the DB until I manually disconnect.
    – Ben
    Commented Apr 7, 2016 at 22:04
  • 1
    @Ben you can't "extract all files on the device using adb backup". To be precise: I would expect the developer of this app to have disabled being backed up.
    – Ángel
    Commented Nov 20, 2017 at 1:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .