Cleartext passwords are perfectly fine in this case. I speak as a software engineer specialized in security.
This bug report was filed by someone who doesn't understand that obfuscating a password is different from encrypting it. No matter how you store it, the application must be able to extract a cleartext password from whatever storage options are available on the Android device.
That said, one defense-in-depth mechanism that I would like to see on portable devices like phones would be to have an encrypted storage area that is only accessible after typing a passphrase at boot time (the key derived from this passphrase should be stored in volatile memory only). That way if the device is shut down, this secure area would not be decryptable.
Edit: I am defending the mail application because from its viewpoint it is fine to use cleartext passwords. On the other hand the OS should provide a secure storage area as described in my previous paragraph.
Actually, they are not perfectly fine in this case. They should take the Apple approach and use PBKDF2 to derive a key from the PIN/passphrase, if one is set, then use that to encrypt the database. Anything less is simply not OK.
Edit: You should also use some sort of hardware ID in addition to the PIN/passphrase, otherwise it's trivial to distribute a database of, say, all the <=7-digit PINs.
Unfortunately even with a unique salt, 7-digit PINs are not strong enough if, from a theoretical viewpoint, we assume they can be bruteforced at a few thousand per second.
If you use a TPM to store your device encryption key, a PIN combination should be fine. Of course, by definition that requires hardware support.
I work in Android security in particular for a manufacturer. We came across the unencrypted email pass ourselves, but decided it was fine for two reasons:
1) If you don't get rooted, there should be no way to pull from /data/data/* in the first place.
2) With filesystem encryption turned on, you essentially get the benefit of encrypting that pass along with everything else.
A TPM is obviously the best solution here, on all counts, but it's not possible to put one into every phone that's already been sold, so clearly we need a software mechanism that at least helps.
As it stands, if an attacker gains root on your device (which could be locally, via a malicious app running a local root, or via a malicious page exploiting a browser bug and then escalating with a local root), they have the keys to the castle. This is true whether you have filesystem encryption on or not.
Leaving these in plaintext is equivalent to storing plaintext passwords in /etc/shadow; yes, only root can access it, but getting root is by no means impossible. If an attacker does get access to it, it shouldn't be an immediate game-over for your passwords.
To amplify that a bit, in terms of accessing the file system, it's a pretty common security assumption that physical access and root access are equivalent. Since my phone is the system where I trust physical access the least, by extension it's the one where I'd most want a security model that doesn't assume that one can't read the file system the most.
For my purposes, the chances of an attacker having physical access to my systems in a rack in a major data center approaches 0%, whereas the chances of an an unauthorized party at some point having access to my phone approaches 100%.
There is certainly some benefit to encrypting removable flash. However, for non-removable flash, the speed at which normal attackers could pull items off of internal flash without the device running should be relatively long. I'm not totally sure what the limitations are with adb but if it's using Honeycomb style encryption, if you have permission to read the file it's going to be automatically decrypted.
Well, a TPM would be fine assuming a hard limit on rate of attempts or total attempts. Apple, as far as I understand it, uses a TPM but had an interface that didn't properly limit attempts, hence the elcom brute force attack.
Android supports text passwords as well. Also, in a sane security model, it'd be possible to separate having a long password for elevated privileges (i.e. things that could further open the door to compromises like booting and installing apps) from the one simply to unlock the screen.
Your average consumer probably wouldn't avail themselves to such measures, but it'd let the paranoid and companies with security policies at least have semi-reasonable security as an option.
Do you guys know that there's a mechanism in SIM cards that blocks the access if you enter the SIM PIN wrong three times in a row? Carriers store unique long PUK code for each SIM card, which is used to unblock the SIM. So the SIM card and it's contents can't be brute-forced. Wouldn't it be appropriate protection to store the unique salt or key on the SIM card?
The email client checks for new mail in the background, though. How is it supposed to do that if the user is currently "logged out" (assuming you mean the pin for unlocking the screen)?
Not when there is already a market harvesting data from stolen phones. I think you probably haven't considered the impact for the standard user around using email as a authentication authority point.
Its like a skeleton key to your personal data, and with that you can get access to financial services very quickly. Hence why a black market exists, and I garantanee there is already rooting kits out there designed to own that data in seconds.
BTW obfuscation is not a security measure, and IMO its shameful and irresponsible to perpetuate that myth.
If someone has root on your phone, they have your passwords. It doesn't matter how they're stored on the disk. Protecting a key from someone who has full access to storage and memory is very hard.
The OS can't provide a key ring because the user dosen't use a password to login. Or if they do have an unlock code they are short and numeric, making brute forcing them trivial. So yes, in this case plain text is acceptable because there is no truly better alternative.
On one hand, both gesture unlock codes and longer alphanumeric codes, both of which android supports, would probably make good candidates to secure the key ring with. On the other hand, the email application, for example, still needs to receive email even when the screen is off, which makes anything entered on screen un-lock a bad candidate for key-ring solutions. Boot is better, but how often do you turn your phone off while not using it?
The difference between Pidgin and Android is, Google provides the whole stack from the OS to the Mail App and also dictates hardware requirements. Clearly the can come up with a better way to store the, for many people, most important password they have.
It's nice to bring interesting bugs to light, but I hate how posting links to bugs always results in a pile on of useless comments. It evens says "Each comment triggers notification emails. So, please do not post "+1 Me too!".
Instead, click the star icon." next to the comment box, but people apparently think things like "please try to fix it , security on mobile devices need to be more powerful" are worth emailing 500+ people about.
In a sense, it may be Google Code's fault; they shouldn't call them "comments". It's the same terminology that is used on YouTube, HN, and other such sites where people who aren't involved are free to weigh in with whatever they say (albeit with moderation and voting). It should probably be called a "Status update" or some such, as that would give a more accurate impression of what that box is for.
I completely don't understand these public bug tracking systems that turn into YouTube threads, for all intents and purposes. How does any working engineer get anything done like that?
I recently joined the cult of the smartphone (after my feature phone finally kicked the bucket). Since I, like presumably many folks, set things up so that I could check my email, used the web browser and let it store some passwords, I became curious about how those passwords are being stored.
It turns out that it's just an SQLite database where they're stored in plain text. This leaves me somewhat disconcerted since I carry my phone around everywhere (and have a bad habit of losing them – hence waiting for ages to get a smart phone until they dropped below the price of "this won't hurt too much if I lose it"). My assumption had been that since I set a password to unlock the screen (and have a SIM card password) that it'd be tied into a keychain mechanism that unlocked access to an encrypted password store.
While normal apps can't read said file (unless the phone is rooted), it's still a pretty huge vector for identity theft making it rather trivial to extract passwords from a lost / stolen phone.
1) Official root methods (see `fastboot oem unlock`, as made famous by the Nexus phones) as well as many less official methods require a wipe, thus rendering this attack moot.
2) In the event your phone isn't covered by the situation in #1, having a passcode lock and not enabling ADB (developer mode) should be sufficient to protect from a root attack in most cases.
It's worth noting that you're still vulnerable to a root attack that doesn't wipe and can bypass your passcode (runs from fastboot/recovery, or a hole in the passcode lock itself); though I've yet to come across a phone personally with this situation.
And it goes without saying, if you've rooted your phone yourself, any OS security is null and void. If you're rooting, you should realize this already.
But, if you're rooted, you likely have a custom recovery and bootloader which will accept commends freely, so it is pretty trivial to pull arbitrary stuff from the phone. You should, however, be safe from other routes, so long as you disable adb (which also freely accepts commands as root in most ROMS), Filesytem encryption would close all these attacks, but I'm not aware of any particular implementations (I'm pretty sure there aren't any popular ones)
Not only does the custom recovery in itself open up a hole, if you've made full-device backups with root tools, those backups will be sitting on your microSD card totally unprotected. Clockwork essentially dd's your NAND, and Titanium will leave a folder of conveniently named sqlite files ready for the taking.
Plus, "detecting" a rooted device is rather easy depending on how extreme your changes have gone. Seeing the AOSP lockscreen or a status bar that doesn't match the OEMs skin is a dead giveaway that the phone's been rooted. With that in mind, an attacker could simply pop open the battery cover, remove your SD card, replace it with a blank (so you don't notice the 'missing SD card' warning), and put everything back together in under a minute. By the time you notice something's up, the attacker will be long gone with your card full of plaintext backups.
PS: even if you don't keep backups on your device, merely having Clockwork installed makes the act of an attacker getting one (while bypassing your passcode) trivial. The attacker simply needs to power off your device (yank the battery), insert his SD card, reboot your device into Clockwork (on HTC phones, this is vol-down + Power), run a backup, remove his SD card and replace yours, and reboot again. This can be done in the space of 5 minutes, and you will never know unless you pay very close attention to your phone's uptime. And of course, how do you know your phone wasn't just having a bad day and rebooted of it's own free will?
Full device encryption is part of the Android platform as of 3.0; besides that some OEMs (I believe Motorola is one of them) have taken the liberty to implement it themselves. As well, Whisper[1] has produced a solution for the Nexus phones.
Ah, but how does this Superuser.apk achieve root privileges? By calling the setuid root `su` program, you say.
And how does this setuid root program actually gain root privileges? Why, the OS is able to execute arbitrary code with arbitrary privileges, and it makes an exception for `su`.
Wait... so Android could run processes with root privileges without asking you? Whoa!
Now consider that adbd on a rooted device runs with root privileges...
Superuser.apk does not achieve root privileges and su does not blindly run your program with root privileges. su asks superuser.apk, if your program is allowed to run as root and only when superuser.apk agrees (and displays toast), then your program is run.
Also, the arbitrary privileges are reserved for setuid programs, which is not easy to achieve. Basically, su and Superuser.apk are gatekeepers to uid 0, which short of bugs, you can't get around.
Also, did you know, that you can disable adbd? Or remove root privileges from it?
Thank you for leaving the original for context, it's drives me nuts when people delete a message or edit out the content when there's a string of replies.
In the mean time, be sure to enable two-factor authentication on your account. I'll admit it's not much solace as usually the second factor uses your phone...
- the password you store on the phone (in cleartext) is not the real account password, it's a string for this device only and you can revoke access at any time
- Someone should not be able to use your phone (via call/text message) as unlock device, unless you lost it
- In that case you should lock the SIM for for a multitude of reasons anyway - and you'll get a new SIM that you can use to recover your account
I think the first one is the most important though: You just don't have to store your real password.
> No. No it's not. please tell me how someone is going to get those passwords without root. (hint, they're not)
By running an exploit to get up to root, or by attacking it physically. Neither of these are particularly difficult or unlikely.
> additionally, how is this different than NY laptop with Pidgin accounts, my IMAP client, Firefox's stored passwords, etc.
It's not, if you're saving passwords without a master key. If you're using, say, 1Password, then your master key has to be compromised to get the passwords.
>By running an exploit to get up to root, or by attacking it physically. Neither of these are particularly difficult or unlikely.
Keeping in mind that root-escalation bugs are back ported and shipped to consumers quickly and often silently, I find that claim to be a bit bold. In fact, the popular root escalation of choice these days is very specific and must be used in conjuncture with ADB. Rogue software is going to have a hellofa time just accessing this file.
>If you're using, say, 1Password, then your master key has to be compromised to get the passwords.
I'm not sure we're talking about the same thing, or you missed my point: if I teach Pidgin how to login to my IM accounts (or Thunderbird, IMAP; Email.apk, my POP server; my Facebook notifier, my FB account credentials)... then those applications HAVE to cache those passwords in plaintext. Unless you're so security conscious that you type them in every time you launch your IM client. (Props if you do, but that's the scenario I'm discussing. I'm just taken aback by the pure ignorance exuded in the linked bug report)
Basically, even with this "vulnerability" that absolutely can't be avoided in many cases... Android is still better off than your laptop, barring an unlikely root escalation bug (remembering of course Google's stewardship of the Market and them taking down applications using such exploits)
edit: I have no problem with the notion of using oAuth to mitigate or eliminate this problem. Unfortunately, as a user or even a third party developer, that's not really a decision I get to make.
Actually Android phones cannot use two way authentication so after you enable it in google account you will have to create an application specific password: that means that your android phone will login to google account using your usual username and a "per application" password randomly generated by google. That is the one that is stored in the sql db.
All google has to do is to make sure that you cannot login using that same password from two concurrent sessions.
So if your phone is stolen: you revoke the android-specific password; if your db is phished or acquired, google will revoke the android-specific password once the attackers tries to use it.
If you're using a password management utility, root access to the filesystem isn't enough because all stored passwords are encrypted a password that is never stored on disk. One example of this, I believe, is Keychain using your login password for encryption in OS X.
Unfortunately, this doesn't work as well on a phone. Because of the awkward entry mechanism, passwords are likely to be shorter and to contain much less variation.
Well that's just it isn't it. If you took (not mine, but most people's laptop), you'd be able to read out all of their cookies (fun, in and of itself), read the contents of their saved Firefox passwords, read the cached/stored passwords for Pidgin, etc, etc.
You can't really remove the flash memory from an Android phone. I mean, you could, but if someone's that interested in you, they're going to get the information through easier or nastier means. Meanwhile, that file is protected by Android, and lacking a root exploit, not much is going to happen.
Google's stewardship of the Market combined with their backporting of root escalation bug fixes makes it very hard for me to get as scared or ironically angry as those in the linked bug report.
Well, what's the right way to encrypt this kind of stuff?
Even if you're doing some kind of public-key cryptography, you're still going to have to store the private key at some location on the device, to decrypt the password for IMAP/SMTP/whatever authentication.
Is there some foolproof way to do this that I'm not aware of? How are you supposed to store a password for future retrieval, not in plain text or basically plain text (encrypted but with the key on the device)?
You derive a key from some piece of user input and use that to encrypt it. If you also mix in, say, a hardware ID, then you also make it impossible to distribute a set of common keys.
1) Assuming a virgin device, applications can't access the DB this stuff is stored in, or other applications' files (if an application wants to safely store stuff on its own, outside of the OS mechanisms), so it's not too big a concern that applications be unable to do this.
2) If you get physical access to the device, you can pull the DB and whatever IDs are involved. Without encryption, this is game over instantly; with encryption, your goal is to delay it as long as humanly possible.
The correct answer is to use a TPM - Trusted Platform Module - for that key. Accessing the TPM itself requires a password, but the hardware prevents against bruteforce/dictionary attacks.
The iPhone does not, and I'm not aware of any that do. Even the Blackberry, which is intended for high security of such things, simply uses PBKDF2. However, a TPM is the best solution here.
the truely right way of doing that is having a digital key, not a password, that is part of your keyring, which do not reside on the phone, and be able to revoke that key when you lose the phone
additionally that key should be protected by e.g. your PIN code although its quite crappy its better than nothing
note that the key is only there in my post because its way easier to revoke and regen than to memorize a new complex password every time.
ideally the phone should also be encrypted with a non trivial key (not your PIN)
The comments on this page are pure gold. So many people jumping on the bandwagon without a clue as to the actual security issues/solutions. Like this one:
I personally think that delivering a quick update with MD5 encryption would be a fast patch for the moment.
This is another epic thread (dated and not as relevant now) that may be entertaining to you...
"Issue 6914: Make android use the GPU (if available) for UI and browsing."
"I agree with the common opinion here... It is very hard to pitch Android to someone who is not tech savy, simply because of the choppy and sluggish UI. This has also become the talk of the masses, most people who haven't even used Android say the following: "I've seen Android, its cool, but its not as smooth and stable as the iPhone."
The iPhone's hardware fails a lot (I've exchanged my 3Gs twice in less than a year), it also freezes at times and drops calls, but what do people see and remember!? UI!! If android wishes to ever compete seriously with iOS, GPU acceleration is a must!
On a side note, who cares about the older phones!? they can keep being sluggish... There's less than a handful of Android phones that won't support GPU acceleration, there's more than 30 that do...
Conclusion: MAKE THIS A PRIORITY, its time to put the choppy UI days behind us, this year is going to bring amazing hardware to the table, and the new iPhone is good, but not THAT good... As it stands, all iOS has on Android is a "smoother experience", why hesitate to fix it!?"
The problem there is email is generally used as an authentication authority for most online services, and a stolen phone hands over exactly what organised criminal outfits need to begin start real indentity theft.
Having done some work with financial services this was a huge problem, as soon as an email acocunt is compromised hackers used automatic services to reset every password they can find... because the email was the point of authority.
Because of this the product we designed had a two point authority process. But alas the second point was a text message sent to the stored cellphone number, which would mean in this case all your data is pwned.
I see most banks I deal with now have moved to phone call only authority checks. But in all honest once you have access to a decent a email account you can harvest the needed information quickly. My current banks just wants name, access code (printed on my card FFS), birthday, mailing address and bingo I'm in.
I am reminded of the Android "reboot" bug where every keystroke was sent to the foreground application and an invisible terminal running as root. Try sending a text message with the word "reboot" and your phone would instantly reboot!
This only affects email accounts as far as i can see. It does not affect gmail accounts though. Only emails where you have to use other protocols like POP3. Although i still believe it shouldn't be plaintext, but it's not nearly as bad as it seems.
This issue should have been closed with the release of Android 3.0, which introduced full disk encryption. It is no longer an issue on the latest Android devices (albeit being limited to tablets), and will soon b available on phones with the release of Android 4.0.
> If I lock my phone using pin does it mean that my passwords and keys (mentioned in comment #48) are not encrypted using pin+some phone HW ID?
Yes.
> Also does encrypting my passwords and keys using pin+some phone HW ID really solves the problem?
Yes. No. Sort of. It really depends on what you're trying to protect against. It's absolutely not a panacea, but it will certainly make most attacks against it, where you solely have the DB and any relevant IDs, significantly more expensive. However, it won't help if, say, you can escalate to root from an app (or remotely!) and backdoor the PIN entry.
A PIN short enough for almost any user to be bothered entering it to unlock the phone is not going to be long enough to resist brute force attacks, even with a 10,000x PBKDF2 work factor.
A general question about Sqlite databases in Android and iPhones... since an application can read and write to it.. can't they read records written by other applications as well? Isn't this a security risk if you install an app that tries to look for passwords in your Sqlite DB?
The person who wants the software fixed should fix it. This isn't a cop-out, it's simple economics. If you want a pony, go buy a pony. Otherwise, STFU.
If I buy a pony I expect to be a pony, not to be a donkey.
Its definitely a total cop out because no one is taking responsibility on the matter, bugs are being ignored, and Google has made a history so far of passing blame and not addressing issues with Android.
Lastly thats a moronic statement "The person who wants the software fixed should fix it". Android tends to attract lower income people who tend not to be IT orientated. If you told any of these peoples the dangers of identity theft they would want this changed, but its out of there capability to address. TBH I don't know how you can even have such a stupid stance.
Sure, Google should fix it. But they're not. So now what?
One of my main problems with people in general is that they want to assign blame, not solve problems. So, okay, blame Google. But that's not getting you closer to a solution. Typing in code to fix the problem is the solution.
Finally, to address one point:
If I buy a pony I expect to be a pony, not to be a donkey.
That's reasonable, but this is software. You know all those CAPITAL LETTERS rambling on about NO WARRANTY. That's what this is. There's a defect and they don't have to fix it because you signed away all your rights to get the software. Vote with your wallet: only buy software that's proved correct.
> Vote with your wallet: only buy software that's proved correct.
For all intents and purposes, people in last 50 years proved, that they do not want correct software. In many cases, they can't even describe what correct software should do. They want cheap (= keyword!) software, that kinda-sorta is fit for intended purpose.
This bug report was filed by someone who doesn't understand that obfuscating a password is different from encrypting it. No matter how you store it, the application must be able to extract a cleartext password from whatever storage options are available on the Android device.
For a longer explanation: http://developer.pidgin.im/wiki/PlainTextPasswords
That said, one defense-in-depth mechanism that I would like to see on portable devices like phones would be to have an encrypted storage area that is only accessible after typing a passphrase at boot time (the key derived from this passphrase should be stored in volatile memory only). That way if the device is shut down, this secure area would not be decryptable.
Edit: I am defending the mail application because from its viewpoint it is fine to use cleartext passwords. On the other hand the OS should provide a secure storage area as described in my previous paragraph.