Is attacking a password manager on android with root access a plausible concern?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

[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.