> 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.
additionally, how is this different than NY laptop with Pidgin accounts, my IMAP client, Firefox's stored passwords, etc.