Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


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.

    • by maxume ( 22995 )

      If the app-server combo has a decent session protocol, the app can get a session token from the server and discard the password.

      • by mysidia ( 191772 ) *

        If the app-server combo has a decent session protocol, the app can get a session token from the server and discard the password.

        I agree that's a very good idea. Why don't we implement Kerberos on our Android phones, and insist on GSSAPI with a Kerberos service ticket to access POP3/IMAP/etc from the phone?

        Or certificate-based authentication, where we install a X509 certificate on our phone, and the server requires we authenticate with the right X509 certificate and use TLS/SSL in order to gain ac

    • by gweihir ( 88907 )

      Was just about to post the same thing. The OP seems to have no clue how password security works.

    • 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 sjames ( 1099 )

      I would argue that a simple transformation is worse than storing in plain text because it provides security theater with no substance.

      The real choices are simple:

      1. It can be left as-is with known risks.
      2. Make the user enter the password every time the mail app starts up
      3. Keep the password in a lockbox and make the user enter a master password every time the phone starts up (or needs the screen unlocked).

      It might be nice to offer a choice, but I suspect most would end up choosing the current situation with

    • by guruevi ( 827432 )

      The problem is not that the password is stored on the device, that is a problem occurring regardless of the device. The problem is that the program stores the password in an open, unauthenticated data store that other programs can access and is not encrypted. You can create your own encrypted container and store passwords in it (like Firefox stores passwords internally) or rely on a system-wide per-program encrypted container (like Mac OS X Keychain). Android just uses an unencrypted SQLite database with ha

  • by Kjella ( 173770 ) on Sunday July 24, 2011 @02:46PM (#36864126) Homepage

    SHA and MD5 are hash algorithms, there's no way to recover the actual password from a hash. And since you need the password to log in, that doesn't make the slightest bit of sense. The best they could do is some symmetric encryption with the key hardcoded in the software as security through obscurity.

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

      • with a key that's only physically accessible to the encryption engine.

        The last time that was tried, where not even the owner of a device can access its keys, that was called the "Trusted Platform Module", and the Slashdot crowd was up in arms against it.

        • by Mr Z ( 6791 )

          You may've missed the part where I said "Heck, TPM does this same stuff." TPM itself isn't evil. It can be put to good uses also.

      • by Tom ( 822 )

        That would make the sqlite file useless to an attacker, yes.

        But if he can fetch the sqlite file, he has deep enough access to access other data on the device, very likely including the in-memory decrypted password.

        You'd need more than just a safe storage. You would need an OS that does the proper segmentation as well. If you're doing that anyways, making sure nobody who shouldn't get access to the sqlite data in the first place is a lot easier.

        For maximum security, of course, you'd want to do both.

        • by Mr Z ( 6791 )

          You'll note that I did say you'd need to be careful with the information when it's outside the bag. That's true whether the password gets stored on the phone, or the phone makes the user type the password every time it's used. If the password only gets stored in RAM, though, you can do things such as wipe buffers immediately after use, etc. to at least limit the size of the window involved. Finding the right bytes in the right VM page (after hacking your way to get access in the VM!!) isn't nearly as tri

      • by wasabii ( 693236 )

        Doesn't really help for PLAIN or LOGIN methods though, does it?

        Or even DIGEST, really. That stuffs simple to break.

      • by godrik ( 1287354 )

        Instead of hardware encrypted key, you could use a master password provided by the user and either stored in RAM for the whole session or forgotten after some time in a way similar to sudo. That won't prevent anything from malware that achieve root access since they could read the key when typped in by the user, but that will prevent the diffusion of password when a phone is stolen or if the password file is compromised.

        You could also imagine that applications need to ask the user permission to access each

  • 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?
    • Re:Old News (Score:4, Interesting)

      by bonch ( 38532 ) * on Sunday July 24, 2011 @04:41PM (#36864794)

      Oh, well, hey, if a major security flaw is almost a year old, it's no longer news!

      Why are Android security problems always justified and dismissed on Slashdot? If this was iOS, I suspect your post would be completely different.

    • Why does it matter?

      1) Anyone doing full system backups is probably also copying this database on to a computer, where anything could read it.

      2) Storing core passwords out in the open implies there is no system framework to store secure credentials. That means in turn any application storing a username/password would be probably storing it in plaintext in the application directory. If that application directory is on an SD card, anything could read it.

  • by microbee ( 682094 ) on Sunday July 24, 2011 @02:56PM (#36864170)

    MD5 is a one-way hash, not encryption. You store the password in this form, you cannot go back to the original form.

    You need the plain text password for interoperating with the email servers (or whatever services that need password). They may support a different transformation of the password instead of MD5. So there has to be a way to go get the original plain text password.

    On the other hand, if you use SHA or other means of encryption, the phone still has to decrypt the password. There are two ways for the phone to get the key:
    1. embedded on the phone, maybe generated randomly for each user. Still the key has to come from somewhere, so theoretically it's possible for any malware to find the key and use it.
    2. ask for the key or passphrase from the user everytime the phone boots, like Firefox's password manager.

    • Correcting myself, SHA is a hash function too. I got it confused with the public key encryption.

    • This. Maybe you could do some sort of hardware-level black-box encryption system (kinda like I how SIM cards already work). That way, simply reading the file system wouldn't be sufficient, you would need to actually be able to perform a hardware level request to decrypt the password. Doesn't add much security, but maybe better than nothing? Don't think it would be worth the cost, though. Anything able to read your filesystem if probably gonna be able to get around this.

      What we really need are device tokens

  • It should generate a certificate for access to your account. The password should only be used the first time you log in to establish the certificate as one which has access to your account. You should then be able to go to the web and see what kind of history of access and operations each authorized certificate has been performing, and allow you to revoke any certificate which is misbehaving.

    But that, of course, is good security that isn't a huge pain and a headache for the user. And, as we all know, and th

    • by growse ( 928427 )
      Given that a certificate is effectively just a very very long structured password, what stops me pinching the cert off the phone and using that to sign into the relevant service? A certificate doesn't solve the problem, it just changes the terminology slightly. It's still bits and bytes stored on the phone that can be used as a secret to access a service as a user.

      If you want a device-specific password, Google already support that for their services through their two-factor authentication with applicatio [google.com]
      • Nothing. But there is no way data can be stored on the phone that cannot be used to access the service.

        The best you can do is make sure that it's apparent when the phone is being used to do something via the service so a user can monitor it and cut off access is something untoward is happening.

        • by growse ( 928427 )
          It's a good idea, and Google already do this. Scroll to the bottom of gmail and on the right there's a link that opens a windows giving a list of current open logged in sessions, as well as a history of sessions, giving datetime, IP address and type (Mobile, browser, IMAP, etc.).
          • by swalve ( 1980968 )
            "Google already do this"?

            How many Googles are there?
      • If you want a device-specific password, Google already support that for their services through their two-factor authentication with application specific passwords [google.com].

        What I want is a password that is unguessable. Storing any kind of user password at all is totally unacceptable. I haven't used a password to remotely log into any of my computers for at least a couple of years now. Somebody who somehow got a copy of my password database would be unable to use it to get remote access to my computer. They'd have to get private keys instead.

        I have separate private keys for each device capable of physically authenticating me. So if I lose any of those devices I can easily revo

        • by growse ( 928427 )
          And that's brilliant, but what I'm saying is a private key is just a long password. They fall into the same password-factor space of 'something you know'. By thinking that a private key makes you any more secure than a password on the basis of anything other than password length is wishful thinking.

          I believe you're also free to set your Gmail password to be 100 characters, making it effectively 'unguessable'.
          • There is no algorithm at all that will help you if your cell phone is compromised. Two factor authentication or no, once your cell phone is compromised it's game over.

            But having your gmail password on your cell phone is a very bad thing because you might use that password for other things, or your passwords might follow a theme, or any number of other things. You should never store a password if you can help it, and you certainly shouldn't be storing it on a cell phone.

            So, that leaves a password that's basi

        • by DavidTC ( 10147 )

          Yes, and the second IMAP supports this standard you've invented, feel free to pester the Android people to implement it.

          This article, however, is retarded. Of course the password is stored on the device. It couldn't access email if it wasn't.

          As some people said, they could make it slightly better by encrypting the filesystem or the file, and requiring people to enter a password to decrypt it on startup. Although considering that telephone 'passwords' tend to be only 10000 different combinations, uh, those

      • by TopSpin ( 753 )

        what stops me pinching the cert

        The cert won't help. A 'cert' implies some form of public-key cryptography, where one must have a private key to be authenticated. Anyone may have the cert and its public key; it is public material and dissemination compromises nothing. The question is how does one secure the private key.

        One can imagine an HSM [wikipedia.org] embedded in a portable device. This could isolate key material such that recovery, if possible, would require time, physical possession and destruction of the device.

        Someone is actually attemp

    • by Tom ( 822 )

      The only thing certificates, hashes, challenge-response, etc. etc. gain you is the attacker doesn't learn your password itself. If you use the same password for other things, that's an advantage. But it doesn't prevent him from accessing your account after cracking your phone.

      (and yes, /., it took less than a minute to type that. moronic system)

  • Given that by default you're auto-logged into your Google account, if someone has the phone they have email access. Would be nice if there was better security of course.
  • I would not blame this on Android's fault for the same reason many others have noted.

    However, if this system is so insecure, why not use something else? I agree that standard mail-based servers have no choice, but maybe other services would be able to use other authentication systems such as token-based (OAuth style) or some sort of host verification procedures (using public-key cryptography, just like with SSH) instead of using the insecure password-based authentication mechanism.

    Again, I understand that t

    • by Tom ( 822 )

      The entire point of this kind of password storage is to remove user interaction.

      Which at the end of days, no matter how you skin the cat, means that the phone must contain all the data it needs to authenticate itself to the server and access your e-mail account.
      So no matter what solution you come up with, it will break at this point.

      Yes, there are challenge-response or hashing ways that gain you one thing: Someone cracking your phone can access your mail, but he doesn't know the password itself, only its ha

      • by swalve ( 1980968 )
        No, the phone could be a Blackberry, and the passwords would not be on the phone.
        • by gl4ss ( 559668 )

          you guys are suggesting to make the phone a thin client terminal, in that case some credentials would be stored anyways there. anyhow, many, man phones from many, many vendors have sqlite db's full of juicy shit. anyways, the sqlite db itself should be user level protected on the android device itself, so if you or others don't root it, regular apps don't get to steal your passes --- this is the big deal really why this would matter. imagine if any application you let read files could read your email/g pass

      • Yes, I know that the point is to remove user interaction, that was also my point :)

        If its insecure, then I would rather have no password at all be stored in the device, and instead have a token like you suggested, and like most modern authentication systems work.

        However, many standard services don't have the notion of tokens and still work with passwords.

        At first glance, it would seem like for those password-based systems you either store the password in the device or forget about removing user interaction.

  • Using public WiFi spots is a much more dangerous issue, since a lot of websites still don't employ SSL encryption of the traffic and your POP3/IMAP/HTTP credentials can be easily eavesdropped.

    Like it's mentioned earlier not storing passwords in an open or reverse encryptable form is not possible, since your Android device has to supply plain text password to many Internet servers.

    • by Haeleth ( 414428 )

      Using public WiFi spots is a much more dangerous issue, since a lot of websites still don't employ SSL encryption of the traffic and your POP3/IMAP/HTTP credentials can be easily eavesdropped.

      That's not a problem Google can solve.

      Protecting my passwords from people who steal my phone is a problem Google can solve.

      Please don't divert attention from an easily-solved issue just because you think some other thing is more important. Or I might just ask why the fuck you're wasting time on Slashdot instead of wor

      • Every time you want to access your encrypted data, you need to supply a secret key/password.

        The whole point of Android to store the password is NOT to ask you every time for it. Any full-disk encryption solution, Truecrypt or any other, is totally useless if you skip the step of the user entering the password for unlocking the data, because you would then be storing the password - you guessed it - in plain text!

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

  • People like the submitter and the ones who filed the bug are the reason hacks occur all the time. They think they know something about security and they've heard that plain text passwords is bad but they have no idea how and why they are bad. These people go and implement "secure" systems that get hacked. Encrypt the password on the same device that has the encryption key and then think it is secure

God made the integers; all else is the work of Man. -- Kronecker