Password storage on Android devices

A number of Android device owners are upset to learn that their trusty products store sensitive credentials — such as email account passwords — in plain text. The bug tracker entry has amassed an impressive number of votes, but as the attached discussion reveals, any proposed solution butts up against consumers' conflicting expectations — such as that the device continue to check for messages as long as it is turned on, yet never inconvenience the user by demanding a password.

The root of the trouble is that POP, SMTP, IMAP, and other email protocols may require the client to provide the account password on every connection attempt. Thus, in order for the phone to check email silently in the background, the OS must have access to the password in plaintext. Google's default email application does just this, storing account passwords in the clear inside a SQLite database. Google's Gmail-specific client application, which uses a different, token-based authentication protocol, does not require the password on each connection, but the token itself may serve just as well. Discovery of that password "flaw" spawned a tremendous public outcry in the comments section of Android bug #10809.

Of course, Android is not alone in this regard. Apple's iOS and other mobile platforms also store passwords on the device in plain text, and a client application on any other computing platform faces the same challenge: Thunderbird, PINE, Evolution, KMail, etc. — even IM clients — all send the account password to the server when left running unattended. Consequently, they must either store the password in plain text, ask for it on every connection attempt, or encrypt it and require the user to enter a different passphrase to unlock the storage location.

Analyzing the problem

The difference is that mobile phone users are unaccustomed to logging into their phones with a username and password, and even if they do, they tend to leave their phones on (and thus leave themselves "logged in") 24 hours a day. A password store decrypted at login time would be readily available to a pickpocket, even if it is stored securely when the phone is deactivated. The pickpocket attack reveals another challenge to mobile password security: there is a difference between security measures that protect user credentials on "disk" when the phone is off, and measures that protect the credentials during an active session.

Android will be implementing its own form of full-disk encryption with 3.0 ("Honeycomb"), which will offer protection against extracting information from the flash storage card. But this will not help any users on earlier versions of Android, nor does it protect against attackers who steal running phones.

Google cannot force third-party application developers to store passwords wisely, but many commenters on bug 10809 feel that the company ought to provide a more secure option for the set of default Android applications. The discussions on the bug tracker and on external sites like Android Central make for interesting reading.

Some suggested encrypting (or obfuscating) the password file itself, and storing the key to that file elsewhere, such as on a "keychain" stored on the device. But as Android developer Andy Stadler pointed out, this does not improve security, it only moves the weak link to a different file. The password safe must be decrypted for the application to use it, which means the password to the password safe must itself be stored in plain text for unattended access. As he put it, there is "a simple test: if you can boot up the device and it will begin receiving email on your configured accounts, then the passwords are not truly secure. They are either obfuscated, or encrypted with another key stored somewhere else."

Others suggested not storing the passwords locally at all, but storing only a hash of the password instead. This approach does not work either, as user hyperhacker noted, because hash functions are one-way, and the original password is what must be sent to the server. Thus in practice either the user will be prompted for the password to validate the hash value (in which case the stored hash is clearly useless), or else the "hash" function is actually an encryption function, and the scheme is no different from the other encrypt-the-password-file proposals mentioned above.

Inconvenient security

The "executive summary" of the situation is that either the OS has access to a password in plaintext without user intervention, or else the user must be prompted to supply a password that is stored nowhere on the device. The real question is how much inconvenience the user will tolerate.

A scheme that asks the user for a boot-time passphrase to unlock a password safe is not very secure because of how long phone sessions typically last. As user mahashel put it in a related bug report:

One alternative would be to re-prompt the user for a passphrase whenever the device is awakened from an idle or sleep state. User aigarius argued that this would prevent the device from checking email in the background. "If you 'tie' it to the unlock code, then you can only check the email when the phone is unlocked, which is clearly quite useless." This is not true in the strictest sense: the OS could "forget" the password only when the user begins the unlock procedure — that way the background process could continue to check messages and activate alerts, and a pickpocket would still be locked out — but it still requires the user to enter a passphrase, PIN code, gesture, or some other form of credential every time he or she picks up the phone to do anything. That level of inconvenience seems to be anathema to most consumers.

User solinym suggested biometrics might be better received among consumers than passwords, with a caveat: "If you think key rotation is a PITA, you haven't tried replacing your fingerprints." He also raised the question of hardware security, tamper-resistance in particular, suggesting that the hardware required to prevent hardware key-extraction would add little to the cost of modern smartphones.

Gertvdb suggested storing a "master password" on the phone's SIM card, because SIM cards are more secure by default, they limit the number of attempts to enter the PIN code, and they have storage capacity. "The phonebook / SIM SMS message store should have enough space, even on 8k SIM cards. (And doesn't seem to be used by Android) (Some compression might make sense, to reduce the amount of storage needed)." Of course, not all phones use SIM cards, and on those that do, denial-of-service is a risk, as an attacker (perhaps a casual one just snooping around) could exceed the allowed number of PIN guesses and lock out the phone owner, even if they do not gain access to the data on the device.

As is typical of security debates, the talk returned time and time again to whether or not providing some form of weak security was worthwhile (to prevent casual attackers), or whether, in the absence of a foolproof solution, all other solutions give users a "false sense of security" and are "a complete waste of time" for developers to attempt.

Eventually a number of suggestions arose that amount to offering user-selectable "security levels," through which security-conscious users could enable strong encryption of their credentials at the cost of automated access, and the more laissez-faire could dispense with it. User danthanos called for a public API providing a secure storage service:

Tangential issues

Google has not responded with a game plan. Stadler, who marked the bug as "medium" importance last September, also commented "rest assured, I am not closing this bug. We recognize that this is causing concern for some users, and we're going to look at identifying steps that can make your data more secure" — which remains the last public word on the subject from the Android team.

The full-disk encryption debuting in Honeycomb is unquestionably a step in the right direction, because it does offer protection against exposing one's password in the event of a memory card theft. Intriguingly enough, however, another commenter reported that Android already has an internal "Credential Storage" API that is not documented for public use. Several third-party Android discussion forums have also brought up this API, so it appears to be in the wild already, but there is no official discussion of it. It appears to be used by applications for storing VPN certificates and other credentials not chosen by the user, but without a published API it is not likely to be useful to developers (and abusing it may break important things as well).

Android does have a "remote wipe" function (as asked about by hyperhacker in the bug discussion thread) for administrators to activate in case of theft, although it must be set up in advance. Needless to say, a remote wipe is hit-or-miss: if activated before an attacker accesses the phone, it works, if activated afterward it does no good at all. Remote wipe can also be used in ways that users may not expect.

In the meantime, security-focused users and developers can always turn towards third-party Android Market tools to offer additional layers of protection. There are stand-alone applications for bulk password storage, although these do not automatically sign-in to email (or other services). There are applications that provide password-protected access to the application as a whole, and there are PGP clients and directory encryption utilities galore. Even with all of those add-ons activated, however, it will still be up to the user to make the final choice: would you rather have your phone check your email in the background (and store your account password in plaintext), or have your phone keep your password safe (and force you to supply a password for access). There's just no way to have it both ways.