this seems like a very good reason for Google to adopt application-specific passwords. Oh, wait...
Android account passwords are stored on disk in plain text
51–60 of 93 posts
Re: Android account passwords are stored on disk in plain text
#52Earlier quoted context omitted.
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.
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....
[deleted]
Re: Android account passwords are stored on disk in plain text
#53It'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 5…
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?
They don't.
Issue 7589: Android dev team ignores its own bugtracker http://code.google.com/p/android/issues/detail?id=7589
Re: Android account passwords are stored on disk in plain text
#54Earlier quoted context omitted.
But if you have physical access to the phone, why couldn't you root it?
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…
> if you've rooted your
phone yourself, any OS security is null and void
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.
Re: Android account passwords are stored on disk in plain text
#55Cleartext 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://d…
Android 3.x supports full disk encryption.
Re: Android account passwords are stored on disk in plain text
#56Earlier quoted context omitted.
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?
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.
Unless it is a dumb protocol, you should be fine. Session IDs FTW.
Re: Android account passwords are stored on disk in plain text
#57This 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.
Re: Android account passwords are stored on disk in plain text
#58Earlier quoted context omitted.
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 encr…
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…
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%.
Re: Android account passwords are stored on disk in plain text
#59This 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.
Re: Android account passwords are stored on disk in plain text
#60Earlier quoted context omitted.
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…
> if you've rooted your phone yourself, any OS security is null and void 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.
If a phone was rooted like as a action, the exploit to get root in the first place is probably still there.