It is a painful experience for users to repeatedly enter their credentials on small devices, such as mobile phones. Because of password strength requirements from individual service providers, the combination of upper-lower-case letters, digits and special symbols, makes sign-in on smart phones a very unpleasant process.
To alleviate this unnecessary hassle, many Android applications such as Gmail and Facebook apps are now using Android’s AccountManager to manage the user credential (account ID and password). This enables delegated SSO (not a federated SSO, such as OpenID) for many related applications to share same account sign-on.
For details on AccountManager and account authenticator, please reference Android API, http://developer.android.com/reference/android/accounts/AccountManager.html and http://developer.android.com/reference/android/accounts/AbstractAccountAuthenticator.html
For details on AccountManager and account authenticator, please reference Android API, http://developer.android.com/reference/android/accounts/AccountManager.html and http://developer.android.com/reference/android/accounts/AbstractAccountAuthenticator.html
Now, with user’s consent, an installed authentication service (for specific account type and associated authenticator) enables AccountManager to register and manage user accounts. For each account, AccountManager will enforce the access control of user credential (account ID and password) and auth-token (produced via authenticator).
How secure is user’s account?
The stored password (intended for account’s authenticator) can only be accessed by caller who holds the permission AUTHENTICATE_ACCOUNTS and has the same UID as the account's authenticator.
Android is based on Linux kernel and uses Linux security model; it leverages Linux user accounts to silo applications. When installed, applications are given an unique UID, and the application will always run as that UID on that particular device. Applications signed with a different key can never request to be run with the same UID, enforced by Android’s PackageManager.
Thus, one might reach the conclusion that it is safe to store account passwords in Android. Unfortunately, however, it is untrue.
To understand the security impact due the subtle difference on account management approaches, let’s first examine standards-compliant password management.
As we all know, the only confidentiality between a registered user and the account provider, in ID/password based authentication system, is achieved by “securely managed” password validation.
Only user can set and supply account password, and the account provider cannot retrieve or recover user’s password by any means, even though it can validate the correctness of user's password.
On user’s side, password is normally stored in user’s memory, not on a notebook, computer or any physical device. On the account provider side, the user's password should not be directly stored in its “secure” system, even with encryption (such as AES). Account provider would only store cryptographically hashed value of password (such as SHA). Because of this one-way-“encryption”, the user’s password cannot be retrieved from the system by the account provider, as well as inside and outside intruders. The authentication process is based on the matching of the hashing value, not exact password matching.
This trust model only leaves a small window of opportunity for password leaking: during registration (or password reset) or authentication process (password guessing attack is not considered here).
Now back to Android account management model, the user's password was stored on a physical medium (phone) besides user’s memory, which could be retrieved by “trusted” Android processes.
Unfortunately, this security model suffers similar fate as when user writes password on notebook, since both can lead to password leaking when the physical medium (phone or paper) becomes lost or stolen.
Although it is difficult for ordinary folks to retrieve stored passwords from a stolen Android phone, it is fairly easy for hackers and criminals. A valid password is more valuable than auth token or other secondary credential, since it can be utilized more easily on ATO (account take over), possibly on many other accounts for same user, since many users tend to reuse same password for multiple accounts, due to complex password strength requirements; it is hard for user to remember many cryptic words.
How can hackers retrieve stored password from a lost or stolen Android phone?
It is extremely simple to gain a root access on any Android phone. There are readily downloadable programe (such as, unrevoked) to root an Android phone in a few minutes.
After rooting, one can easily access the underline OS and file system as a super user via Android’s adb. The following example shows a window session to access system data files, including accounts.db, password.key and packages.xml, etc.
With the help of open-source Android OS, one can easily create a modified program to retrieve stored account info, including passwords.
So what’s different between Android’s account manager and other password safes? The major difference is that the encrypted passwords stored in password-safe require a master-password from user to decrypt, while Android’s account management doesn’t. A lost or stolen password-safe cannot be cracked easily unless the hacker cracks master password.
If Android account management system could employ master password to store and retrieve account passwords by the authenticator, then it can significantly reduce the security concern for lost or stolen phones. Since the master password is only for your phone’s account manager, one can choose a much simpler and easy-to-type-and-remember sequence based on his/her phone's key board without worry about password strength requirements imposed by the account providers.
In conclusion, the current Android account management system is not safe; avoid it whenever you can. Unfortunately, many preinstalled Android apps, such as Gmail and Facebook, are already using it, so be aware what you get when you enjoy the convenience of those delegated single-sign-on.
