6 ms·

Android account passwords are stored on disk in plain text

193 points by wheels 15y ago

mrb 15y ago
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 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 15y ago
  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 15y ago
    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.pdf http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords....
    - walexander 15y ago
      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 15y ago
        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 15y ago
        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 15y ago
        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.
  - Tichy 15y ago
    The email client checks for new mail in the background, though. How is it supposed to do that if the user is currently "logged out" (assuming you mean the pin for unlocking the screen)?
- rjd 15y ago
  Not when there is already a market harvesting data from stolen phones. I think you probably haven't considered the impact for the standard user around using email as a authentication authority point. 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.
  - mentat 15y ago
    If someone has root on your phone, they have your passwords. It doesn't matter how they're stored on the disk. Protecting a key from someone who has full access to storage and memory is very hard.
- there 15y ago
  http://whispersys.com/whispercore.html http://whispersys.com/whispercore.html implements full-disk encryption for android. unfortunately it requires unlocking the boot loader and installing that company's android rom, so it's not an option for many users.
- xiaoqmaxee 15y ago
  welcometo: http://www.fullmalls.com http://www.fullmalls.com The website wholesale for many kinds of fashion shoes, like the nike,jordan,prada,, also including the jeans,shirts,bags,hat and the decorations. All the products are free shipping, and the the price is competitive, and also can accept the paypal payment.,after the payment, can ship within short time. free shippingcompetitive priceany size availableaccept the paypal ===== http://www.fullmalls.com http://www.fullmalls.com ===== jordan shoes $32nike shox $32Christan Audigier bikini $23 Ed Hardy Bikini $23Smful short_t-shirt_woman $15ed hardy short_tank_woman $16Sandal $32christian loubo utin $80 Sunglass $15 COACH_Necklace $27handbag $33AF tank woman $17puma slipper woman $30 ===== http://www.fullmalls.com http://www.fullmalls.com ===== ===== http://www.fullmalls.com http://www.fullmalls.com ===== ===== http://www.fullmalls.com http://www.fullmalls.com ===== ===== http://www.fullmalls.com http://www.fullmalls.com ===== ===== http://www.fullmalls.com http://www.fullmalls.com =====
- zyb09 15y ago
  The difference between Pidgin and Android is, Google provides the whole stack from the OS to the Mail App and also dictates hardware requirements. Clearly the can come up with a better way to store the, for many people, most important password they have.
- st3fan 15y ago
  Cleartext passwords are perfectly fine in this case. I speak as a software engineer specialized in security. These passwords should of course be stored in a Keychain-like component that the OS provides. Are you sure you are specialized in security?
  - lotu 15y ago
    The OS can't provide a key ring because the user dosen't use a password to login. Or if they do have an unlock code they are short and numeric, making brute forcing them trivial. So yes, in this case plain text is acceptable because there is no truly better alternative.
    - nightpool 15y ago
      On one hand, both gesture unlock codes and longer alphanumeric codes, both of which android supports, would probably make good candidates to secure the key ring with. On the other hand, the email application, for example, still needs to receive email even when the screen is off, which makes anything entered on screen un-lock a bad candidate for key-ring solutions. Boot is better, but how often do you turn your phone off while not using it?
- Sephr 15y ago
  Android 3.x supports full disk encryption.
- gst 15y ago
  A passphrase won't really help, because passphrases user's typically use on a secure device will be too simple.
- odiroot 15y ago
  What's wrong with a keyring? Or something like KDE's wallet.
wheels 15y ago
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.
- daeken 15y ago
  Edit: This is COMPLETELY INCORRECT (as pointed out by wallflower) but left for context. 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.
  - wallflower 15y ago
    No, /data/data/* is protected (as it should be) on non-rooted phones. mediapc:platform-tools media$ ./adb shell $ ls /data/data opendir failed, Permission denied $
    - chopsueyar 15y ago
      But if you have physical access to the phone, why couldn't you root it?
      - ConstantineXVI 15y ago
        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.
grecy 15y ago
please fix! </me ducks>
- cryos 15y ago
  No doubt you'll get the standard reply "Its open source the community should fix this".
  - jrockway 15y ago
    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 15y ago
      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 15y ago
        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.
Incubus 15y ago
The title should probably mention that it only effects email. Comment #48 explains the reasoning behind it, and frankly seems perfectly reasonable.
- rjd 15y ago
  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.
markbao 15y ago
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 15y ago
  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 15y ago
    Right, but even if you did that, wouldn't you still have to store that key somewhere? Also, hi from downstairs!
    - daeken 15y ago
      1) Assuming a virgin device, applications can't access the DB this stuff is stored in, or other applications' files (if an application wants to safely store stuff on its own, outside of the OS mechanisms), so it's not too big a concern that applications be unable to do this. 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.
      - deleted 15y ago
        [deleted]
    - FaceKicker 15y ago
      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?
cpeterso 15y ago
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 http://www.zdnet.com/blog/burnette/worst-bug-ever/680
- eli 15y ago
  That was a bug, this is a design decision.
cHalgan 15y ago
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 15y ago
  > 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 15y ago
    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.
supersillyus 15y ago
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 15y ago
  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 15y ago
    They don't. Issue 7589: Android dev team ignores its own bugtracker http://code.google.com/p/android/issues/detail?id=7589 http://code.google.com/p/android/issues/detail?id=7589
oomkiller 15y ago
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 15y ago
  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 http://code.google.com/p/android/issues/detail?id=6914
niels_olson 15y ago
this seems like a very good reason for Google to adopt application-specific passwords. Oh, wait...
Sephr 15y ago
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.
kungfu71186 15y ago
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.
econgeeker 15y ago
How long until a former SNL comedian is holding Senate hearings about this major violation of privacy?
Hisoka 15y ago
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 15y ago
Use appropriate security.
shareme 15y ago
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_implementation.html http://source.android.com/tech/encryption/android_crypto_imp... Very interesting..full file system encryption

193 points by wheels 15y ago

mrb 15y ago

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 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 15y ago
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 15y ago
  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.pdf http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords....
  - walexander 15y ago
    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 15y ago
      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 15y ago
        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 15y ago
        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.
- Tichy 15y ago
  The email client checks for new mail in the background, though. How is it supposed to do that if the user is currently "logged out" (assuming you mean the pin for unlocking the screen)?
rjd 15y ago
Not when there is already a market harvesting data from stolen phones. I think you probably haven't considered the impact for the standard user around using email as a authentication authority point. 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.
- mentat 15y ago
  If someone has root on your phone, they have your passwords. It doesn't matter how they're stored on the disk. Protecting a key from someone who has full access to storage and memory is very hard.
there 15y ago
http://whispersys.com/whispercore.html http://whispersys.com/whispercore.html implements full-disk encryption for android. unfortunately it requires unlocking the boot loader and installing that company's android rom, so it's not an option for many users.
xiaoqmaxee 15y ago
welcometo: http://www.fullmalls.com http://www.fullmalls.com The website wholesale for many kinds of fashion shoes, like the nike,jordan,prada,, also including the jeans,shirts,bags,hat and the decorations. All the products are free shipping, and the the price is competitive, and also can accept the paypal payment.,after the payment, can ship within short time. free shippingcompetitive priceany size availableaccept the paypal ===== http://www.fullmalls.com http://www.fullmalls.com ===== jordan shoes $32nike shox $32Christan Audigier bikini $23 Ed Hardy Bikini $23Smful short_t-shirt_woman $15ed hardy short_tank_woman $16Sandal $32christian loubo utin $80 Sunglass $15 COACH_Necklace $27handbag $33AF tank woman $17puma slipper woman $30 ===== http://www.fullmalls.com http://www.fullmalls.com ===== ===== http://www.fullmalls.com http://www.fullmalls.com ===== ===== http://www.fullmalls.com http://www.fullmalls.com ===== ===== http://www.fullmalls.com http://www.fullmalls.com ===== ===== http://www.fullmalls.com http://www.fullmalls.com =====
zyb09 15y ago
The difference between Pidgin and Android is, Google provides the whole stack from the OS to the Mail App and also dictates hardware requirements. Clearly the can come up with a better way to store the, for many people, most important password they have.
st3fan 15y ago
Cleartext passwords are perfectly fine in this case. I speak as a software engineer specialized in security. These passwords should of course be stored in a Keychain-like component that the OS provides. Are you sure you are specialized in security?
- lotu 15y ago
  The OS can't provide a key ring because the user dosen't use a password to login. Or if they do have an unlock code they are short and numeric, making brute forcing them trivial. So yes, in this case plain text is acceptable because there is no truly better alternative.
  - nightpool 15y ago
    On one hand, both gesture unlock codes and longer alphanumeric codes, both of which android supports, would probably make good candidates to secure the key ring with. On the other hand, the email application, for example, still needs to receive email even when the screen is off, which makes anything entered on screen un-lock a bad candidate for key-ring solutions. Boot is better, but how often do you turn your phone off while not using it?
Sephr 15y ago
Android 3.x supports full disk encryption.
gst 15y ago
A passphrase won't really help, because passphrases user's typically use on a secure device will be too simple.
odiroot 15y ago
What's wrong with a keyring? Or something like KDE's wallet.

wheels 15y ago

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.

daeken 15y ago
Edit: This is COMPLETELY INCORRECT (as pointed out by wallflower) but left for context. 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.
- wallflower 15y ago
  No, /data/data/* is protected (as it should be) on non-rooted phones. mediapc:platform-tools media$ ./adb shell $ ls /data/data opendir failed, Permission denied $
  - chopsueyar 15y ago
    But if you have physical access to the phone, why couldn't you root it?
    - ConstantineXVI 15y ago
      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.

grecy 15y ago

please fix! </me ducks>

cryos 15y ago
No doubt you'll get the standard reply "Its open source the community should fix this".
- jrockway 15y ago
  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 15y ago
    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 15y ago
      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.

Incubus 15y ago

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

rjd 15y ago
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.

markbao 15y ago

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 15y ago
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 15y ago
  Right, but even if you did that, wouldn't you still have to store that key somewhere? Also, hi from downstairs!
  - daeken 15y ago
    1) Assuming a virgin device, applications can't access the DB this stuff is stored in, or other applications' files (if an application wants to safely store stuff on its own, outside of the OS mechanisms), so it's not too big a concern that applications be unable to do this. 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.
    - deleted 15y ago
      [deleted]
  - FaceKicker 15y ago
    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?

cpeterso 15y ago

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 http://www.zdnet.com/blog/burnette/worst-bug-ever/680

eli 15y ago
That was a bug, this is a design decision.

cHalgan 15y ago

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 15y ago
> 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 15y ago
  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.

supersillyus 15y ago

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 15y ago
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 15y ago
  They don't. Issue 7589: Android dev team ignores its own bugtracker http://code.google.com/p/android/issues/detail?id=7589 http://code.google.com/p/android/issues/detail?id=7589

oomkiller 15y ago

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 15y ago
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 http://code.google.com/p/android/issues/detail?id=6914

niels_olson 15y ago

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

Sephr 15y ago

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.

kungfu71186 15y ago

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.

econgeeker 15y ago

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

Hisoka 15y ago

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 15y ago

Use appropriate security.

shareme 15y ago

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_implementation.html http://source.android.com/tech/encryption/android_crypto_imp... Very interesting..full file system encryption