Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Android Encryption Handhelds Security IT

Android Password Data Stored In Plain Text 261

jampola writes "The Hacker News is reporting that Android password data is being stored as plain text in its SQlite database. Hackers News says that 'The password for email accounts is stored into the SQLite DB which in turn stores it on the phone's file system in plain text. Encrypting or at least transforming the password would be desirable.' I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"
This discussion has been archived. No new comments can be posted.

Android Password Data Stored In Plain Text

Comments Filter:
  • by mysidia ( 191772 ) * on Sunday July 24, 2011 @02:42PM (#36864090)

    I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"

    No, I would not agree to that. I cannot say what most would think, but they would be misunderstanding the requirements and a misunderstanding of SHA/MD5 security for password stoarge, if they suggest SHA/MD5 as a solution.

    When your android needs to access an e-mail account, knowledge of the actual login password is required, to connect to the remote server. Storing a SHA or MD5 hash does not retain knowledge of the password, so automatic e-mail login on the Android device would no longer be able to function with only a SHA or MD5 stored.

    The e-mail server itself can potentially store a PBKDF2 derived strong hash for plaintext authentication over TLS (the server may require plaintext for CRAM-MD5 or other authentication mechanism selections), but your software needs to authenticate with the mail server, which requires either that actual credentials be stored, OR that credentials be entered by the user.

    To quote the complaint from the article:

    The password for email accounts is stored into the SQLite DB which in turn stores it on the phone's file system in plain text. Encrypting or at least transforming the password would be desirable.

    I will agree that encrypting or transforming the password in the database is possible; something such as a Windows or OSX style keychain should be possible. HOWEVER, the decryption key has to be stored on the phone, and any transformation has to be reversible, for the device to still work without prompting the user for the password and saving in RAM or prompting the user every time e-mail is to be checked.

    Therefore, the security benefits of doing this are absolutely minimal. Anyone who is actually trying to extract the password will learn about the transformation, and any reversible transformation is not a significant improvement.

    Saving the unencrypted password in RAM may be just as good [or bad] as saving it on the filesystem, since phones are rarely rebooted, and RAM is subject to analysis just like a sqlite DB is subject to analysis.

  • Encrypt The Phone (Score:4, Insightful)

    by steevven1 ( 1045978 ) on Sunday July 24, 2011 @02:48PM (#36864136) Homepage
    As a precaution, you can encrypt the entire phone's filesystem. The Droid Pro, for example, offers this feature as a part of the OS. Unfortunately, for this to be fully effective, this means choosing a STRONG (ie long and complex) password with which to unlock the phone each time you want to use it, which may be impractical.
  • Old News (Score:5, Insightful)

    by Pirow ( 777891 ) on Sunday July 24, 2011 @02:49PM (#36864138)
    1. This is almost 1 year old "news".
    2. Why does it matter? These passwords are generally transferred in plain text without any sort of encryption anyway (which is another issue, but these old protocols are well known to be insecure without SSL etc.) so if you have access to get to the file in question you have access to sniff out these passwords anyway which is just as simple.
    3. Any one way hashing is no solution if you need to transfer the passwords in plain text anyway, what's your POP3 server going to do with a MD5 hash?
  • by Mr Z ( 6791 ) on Sunday July 24, 2011 @02:53PM (#36864156) Homepage Journal

    An alternative to security by obscurity would be to have an actual secured device-specific key on the device, and an encryption block that has sole access to that key. I've actually architected products in the past that have such things, and one of the use models was "user's bag of sensitive data", where you could put items in the bag (passwords, credit card #s, etc.) in a secure manner, and only pull them out as needed. You need to be careful with how you handle the information once it's outside the bag, but the main point is if someone takes the bag (the SQLite database, in this instance), it's valueless to an attacker.

    The bag itself could be stored encrypted in whatever bulk storage is convenient, with a key that's only physically accessible to the encryption engine. The key is "device specific", meaning each chip gets a random key blasted into it in the factory. You couldn't take the secure bag image from one phone and plop it on another and read it.

    Lest this sounds like science fiction, it isn't. The same technology is used and widely deployed for DRM and other such purposes. Heck, TPM does this same stuff. It could be used to protect your passwords, but there isn't as much money or emphasis on implementing that.

  • Re:Old News (Score:0, Insightful)

    by Anonymous Coward on Sunday July 24, 2011 @03:05PM (#36864220)

    Why does it matter?? Had it been another very popular, alternate OS, you guys would be jumping all over it and screaming revolt. But hey, why does it matter right?

  • by Macthorpe ( 960048 ) on Sunday July 24, 2011 @03:11PM (#36864252) Journal

    Incredibly, if you actually RTFA, it's written by someone both technically incapable and clearly illiterate. It's also based on a comment made by a member of the Android team posted nearly a year ago, and the comment also points out exactly why they do it this way:

    Simply obscuring your password (e.g. base64) or encrypting it with a key stored elsewhere will *not* make your password or your data more secure. An attacker will still be able to retrieve it. [...] If you can obtain *any* data from files in /data/data/* on a non-rooted device, this is a security problem in the device.

    So basically, it's hidden from view on a non-rooted device, people who root their devices have already technically cracked their own security anyway, and even if it wasn't in plain text it would still be trivial to decrypt as the key has to exist somewhere on the device to do it.

    All in all, very boring, very old, and very stupid to post.

  • by node 3 ( 115640 ) on Sunday July 24, 2011 @03:18PM (#36864294)

    Yeah, because it's Android, it's ok...


    Somehow, the OS X and iOS keychain manages to use encryption to protect passwords, the entire disk on iOS (after the 3GS, I think, maybe the 3G) is encrypted, and processes are blocked from reading files outside of their sandbox.

    But on Android, it's +5 Insightful to say that plaintext password storage is hunky-dory. In fact, it's preferable! And as referenced by posts below, merely posting a story where someone says, quite meekly, that it might be "desirable", or a "good idea" to up the security on Android is grounds for mocking.

  • get a clue (Score:4, Insightful)

    by Tom ( 822 ) on Sunday July 24, 2011 @04:08PM (#36864574) Homepage Journal

    I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"

    Yeah, because SHA1 and MD5 are one-way hashes which are just great if you actually, you know, need to know the password so you can tell the mailserver.

    When I started reading /., one of the reasons was that the editors had enough of a clue to weed out submissions from people who had not the slightest idea what the fuck they were talking about. At that time, /. stood out from the mainstream publications, who generally didn't employ geeks and the normal journalist had to ask his geek friends about what this "HTML" thing he noticed at the end of every webpage address was.

    Please. One thing we really don't need more of is people with half-a-clue meddling in security and giving advise. For us security professionals, the clueless secretary is not our worst enemy. She at least knows she knows nothing and will listen to us. Our worst enemy in the company environment is the self-proclaimed power user who think he knows what he's doing, but is in fact only messing things up. And because he thinks he's smart, he won't listen to the security department.

    Now yes, there are better ways than storing the passwords in plain-text. Encrypting them would help. You'd think. But in order to decrypt them, you have to have the key. Which means you have to store it on the phone. Or in other words: Right next to the database.
    So encrypting the sqlite data would be the equivalent of having a really good lock on your door, and hanging the keys on a nail right next to it. Anyone who breaks your phone enough to get the sqlite file will also be able to get the key file the same way. All you're doing is making everything more complicated and wasting CPU cycles on pointless crypto.

  • by timothyb89 ( 1259272 ) on Sunday July 24, 2011 @06:42PM (#36865702) Homepage
    For the record, TFA is only referring to the Email app (often called Email.apk) which is just a normal app. Unlike Apple's apps it has no special access to system APIs, keychains, or the like. On top of that, it isn't even included on many Android devices. HTC uses their own which could very well handle things differently, and I'm pretty sure other manufacturers do the same. On my CM7 device I don't even use it in favor of the dedicated Gmail app, which seems to take security quite a bit more seriously. Call me crazy for actually reading TFA but an Android dev made a very helpful comment on the situation:

    Now, with respect to this particular concern. The first thing to clarify is that the Email app supports four protocols - POP3, IMAP, SMTP, and Exchange ActiveSync - and with very few, very limited exceptions, all of these are older protocols which require that the client present the password to the server on every connection. These protocols require us to retain the password for as long as you wish to use the account on the device. Newer protocols don't do this - this is why some of the articles have been contrasting with Gmail, for example. Newer protocols allow the client to use the password one time to generate a token, save the token, and discard the password.

    And as demonstrated by many others here, the keychain is not actually the be-all, end-all solution to the problem, as it either leaves the decryption key elsewhere on the disk, making it useless, or requires the user to constantly enter a password, making it annoying. Android leaves it up to the app to handle passwords (as does iOS in most cases, I believe), and in this case the Email app doesn't really have a choice. Asking the user to enter their keychain password every time the Email app wants to grab new emails would get annoying quickly, and the protocols that it needs to support can't use the more secure token-based systems. Unfortunately there's no other feasible way to do it, and this debate is ignoring the real issue: mail servers that don't support secure authentication.

    tl;dr: Article is not about "Android", only one app, and said app doesn't have much of a choice.

Exceptions prove the rule, and wreck the budget. -- Miller