I have looked around and found no information on how Android manages to store passwords on the device. Especially Gmail passwords. I'm looking to learn how Android encrypts and stores passwords ? What key does it use and where is this key stored, and what encryption algorithm it uses.

Why should the stored password be encrypted with a key? This would only mean that one has to enter the key every time the password is required, then you could simply not store the password and enter it every time.
–
FlowSep 12 '12 at 11:52

Um, the key could be device specific, obtained from the phone IMEI or something. Which means, the software can get the key without having the user to type it in everytime.
–
asudhakSep 12 '12 at 13:27

1

What prevents any other software piece running on the phone to get the key? This approach adds no extra layer of security
–
FlowSep 12 '12 at 13:48

2 Answers
2

Gmail's official appdoesn't store password in your device. Your password is 100% safe if you use this app.

This is how it works: The password is used by Google's authentication servers for the first time ONLY. After first successful authentication, an Auth Token is downloaded to device which is stored in accounts.db file as plain text. For all subsequent logins, this Auth Token is used, NOT your original password.
So, if your device is stolen, all anyone can get is Auth Token which becomes invalid once you change your password. So, you'll be in ultimate command.
For ultimate security, I'd recommend you to enable 2-Factor Authentication & create Device Specific Password for your device. After losing device, all you need is to disable that device. You don't even need to change main password.

Note: These all aren't true if you use third-party email apps for Gmail viz. Stock Email app, K-9 Mail etc. IMAP or POP protocol needs original password to authenticate users everytime. So, plain password needs to be available to email app before sending it to server. So, most of email apps store passwords in plain text (hashing/encryption is useless because hashing/encryption key needs to be stored locally). In this case, I'd recommend you to enable 2-Factor Authentication & create Device Specific Password for your device. After losing device, all you need is to disable that device.

Update:
Technically, its possible to store passwords locally in encrypted/hashed form without keeping encryption key/ hashing key in plain text locally. Thanks to @J.F.Sebastian for pointing it out. Unfortunately, such implementation for Android isn't available yet. Starting ICS, Android provides KeyChain API using which an app can store a password locally in secure form. Apps using KeyChain API are rare, but stock email app uses it (Thanks to @wawa for this info). So, your password will be safe with stock email app as long as your screen is locked. Remember, KeyChain isn't safe if device is rooted and its not available on pre-ICS devices.

@J.F. Sebastian: even assuming that you completely trust the third party that stores your passwords, those were only marginally more secure than simply storing the password in the device itself. The device still need to be able to retrieve the plain text of the password from the cloud storage and the device still have to cache the password locally because you don't want to have to reconnect your dongle everytime you get into a tunnel or areas with weak reception. The worst thing to do in security is to provide a false sense of security.
–
Lie RyanSep 12 '12 at 5:56

4

@J.F.Sebastian: in conclusion, the only truly secure way authentication is to do what Google did with Gmail app, i.e. use non-standard authentication scheme with auth token. Even if someone managed to stole your auth token, you can remotely invalidate the token, and you don't need to change your password because the password plaintext was never compromised. The other secure way is to use dongle without sessions; well, you know what happens when you do that, your users will just leave the dongle permanently attached.
–
Lie RyanSep 12 '12 at 9:58

5

@J.F.Sebastian: I think you're missing the point. Encrypting the password is not any more secure than just storing it in plain text, not even by one bit. Any attacker that manage to copy the accounts.db can also copy the decryption key along with it; the only thing the encryption gives you is a false sense of security, which is worse than no security. Yes, there are solutions that are much better than storing plain-text password, but all of them requires changes to the email protocol, so we got to live with what we currently have. Or do it properly in a non-standard way like Gmail did.
–
Lie RyanSep 12 '12 at 10:11

3

@J.F.Sebastian Apples keychain service or the one provided by the Linux kernel is not a more secure option. The password still hangs around in memory and if the keychain is unlocked even unencrypted. So it's likely only slightly harder to obtain as the root readable only .db file. Google implemented the best possible practicable solution by using a auth token that can be invalidated in case the device is compromised. The next more secure option would be to enter the password every time or to simply avoid using e-mail at all.
–
FlowSep 12 '12 at 11:58

Android passwords used with the built-in Email application are stored in plain text inside a SQLite Database. This is in contrast to the Gmail application, which uses Auth Tokens as described in Sachin Sekhar's answer.

For Jelly Bean, the database location is:

/data/system/users/0/accounts.db

The above location varies with the Android version

This location on a non-rooted device is secured and protected by the Operating System.
On rooted devices, users have already technically cracked their own security, and even if it wasn't in plain text it would still be trivial to decrypt as the key has to exist somewhere on the device to do it.

Now, with respect to this particular concern. The first thing to clarify is that the Email app supports four protocols - POP3, IMAP, SMTP, and Exchange ActiveSync - and with very few, very limited exceptions, all of these are older protocols which require that the client present the password to the server on every connection. These protocols require us to retain the password for as long as you wish to use the account on the device. Newer protocols don't do this - this is why some of the articles have been contrasting with Gmail, for example. Newer protocols allow the client to use the password one time to generate a token, save the token, and discard the password.

I urge you to review the article linked to in comment #38, which is well-written and quite informative. It provides some very good background on the difference between "obscuring" passwords, and making them truly "secure". Simply obscuring your password (e.g. base64) or encrypting it with a key stored elsewhere will not make your password or your data more secure. An attacker will still be able to retrieve it.

(In particular, some claims have been made about some of the other email clients not storing the password in cleartext. Even where this is true, it does not indicate that the password is more secure. 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.)

Wow. That amazes me. I wasn't aware of the fact that it is stored in plain text. Forget rooted or not rooted. If your device is stolen, an unscrupulous person could easily obtain your credentials even if you were to lock the phone with a security key. Given this fact, are you also aware of any disk wide encryption mechanisms.
–
asudhakSep 11 '12 at 23:14

1

Whatever they are, they're something that can be used to gain access to the account. But, @SachinShekhar, the accounts.db file is protected from being read by accounts other than system.
–
WyzardSep 12 '12 at 0:34

1

Zuul, I appreciate your effort you put in the answers but I think this answer is highly misleading. If you go through the quote you have quoted again, Gmail app doesn't store the password. --edit check @SachinShekhar answer too.
–
roxanSep 12 '12 at 2:52

1

@asudhak If any app is using original password, there's NO way to protect it. A hacker can decode encoded string from accounts.db after finding encryption/hashing key which needs to be stored locally because email app would need this key to compile the original password before sending it to server.
–
SS-3.1415926535897932384626433Sep 12 '12 at 8:46

1

@roxan I could not find anything that points to the password not being stored by the Gmail app. Can you provide a quote or a link?
–
FlowSep 12 '12 at 11:50