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.
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.