
Android account passwords are stored on disk in plain text - wheels
http://code.google.com/p/android/issues/detail?id=10809
======
mrb
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.

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.

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

~~~
mrb
I guess we agree (see my edit).

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....](http://sit.sit.fraunhofer.de/studies/en/sc-iphone-
passwords.pdf)

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

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

~~~
wheels
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%.

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

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

~~~
spolsky
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?

~~~
jed_s
They don't.

Issue 7589: Android dev team ignores its own bugtracker
<http://code.google.com/p/android/issues/detail?id=7589>

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

~~~
drivebyacct2
No. No it's not. please tell me how someone is going to get those passwords
without root. (hint, they're not)

additionally, how is this different than NY laptop with Pidgin accounts, my
IMAP client, Firefox's stored passwords, etc.

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

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

------
markbao
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)?

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

~~~
markbao
Right, but even if you did that, wouldn't you still have to store that key
somewhere?

Also, hi from downstairs!

~~~
FaceKicker
Couldn't you have something like:

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?

~~~
ENOTTY
If you do that, I'd imagine that the phone would not be able to pull updates
from those services while the phone is locked.

~~~
mentat
If you're a registered Apple developer, it's worth watching how they're
dealing with this in iOS 5.

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

~~~
wallflower
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!?"

<http://code.google.com/p/android/issues/detail?id=6914>

------
Incubus
The title should probably mention that it only effects email. Comment #48
explains the reasoning behind it, and frankly seems perfectly reasonable.

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

------
cpeterso
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!

<http://www.zdnet.com/blog/burnette/worst-bug-ever/680>

~~~
eli
That was a bug, this is a design decision.

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

------
cHalgan
I'm not security expert at all, so I have a question.

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?

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

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

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

------
econgeeker
How long until a former SNL comedian is holding Senate hearings about this
major violation of privacy?

------
niels_olson
this seems like a very good reason for Google to adopt application-specific
passwords. Oh, wait...

------
shareme
Its changed in Android 3.0..

Basically they use dm_crypt from Linux Kernel..everything gets encrypted..

see:
[http://source.android.com/tech/encryption/android_crypto_imp...](http://source.android.com/tech/encryption/android_crypto_implementation.html)

Very interesting..full file system encryption

------
Hisoka
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?

------
Raphael
Use appropriate security.

------
grecy
please fix! </me ducks>

~~~
cryos
No doubt you'll get the standard reply "Its open source the community should
fix this".

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

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

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

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

