Android account passwords are stored on disk in plain text
code.google.com
code.google.com
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.
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.
By "hardware ID", you mean a unique salt.
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.
Does Apple IOS really use PBKDF2? The Fraunhofer paper does not mention it. http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords....
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.
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.
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%.
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.
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.
These passwords should of course be stored in a Keychain-like component that the OS provides.
Are you sure you are specialized in security?
unfortunately it requires unlocking the boot loader and installing that company's android rom, so it's not an option for many users.
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.
Issue 7589: Android dev team ignores its own bugtracker http://code.google.com/p/android/issues/detail?id=7589
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.
I can't test right now, but if your phone has ADB enabled, can't you pull this file over USB? I could be totally, totally off on that, though.
mediapc:platform-tools media$ ./adb shell
$ ls /data/data
opendir failed, Permission denied
$
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.
Are you sure? If I am not mistaken, even with a rooted phone, a program has to ask the user for root permission via the Superuser.apk app.
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.
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?
- 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.
additionally, how is this different than NY laptop with Pidgin accounts, my IMAP client, Firefox's stored passwords, etc.
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.
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.
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.
My iPad 2 was recently stolen (sad face) and I just had to revoke the different passwords I used for the different apps (Reeder, Mail, Safari, etc.).
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.
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.
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)?
Also, hi from downstairs!
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.
key = hash(hardware serial number, user password)
And then store the key only in memory every time the user unlocks the phone and wipe it from memory when they lock their phone?
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)
I personally think that delivering a quick update with MD5 encryption would be a fast patch for the moment."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!?"
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.
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?
Also does encrypting my passwords and keys using pin+some phone HW ID really solves the problem?
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.
Basically they use dm_crypt from Linux Kernel..everything gets encrypted..
see: http://source.android.com/tech/encryption/android_crypto_imp...
Very interesting..full file system encryption
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.
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.
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.