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!"
Sorry, disagree that SHA/MD5 is a solution (Score:5, Insightful)
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)
Old News (Score:5, Insightful)
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:Well submitter is clueless... (Score:4, Insightful)
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)
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?
Re:Sorry, disagree that SHA/MD5 is a solution (Score:5, Insightful)
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.
Re:Sorry, disagree that SHA/MD5 is a solution (Score:1, Insightful)
Yeah, because it's Android, it's ok...
A few months ago: APPLE STORED YOUR LOCATION DATA IN PLAIN TEXT!!! HOW STUPID ARE THEY? THE ONLY EXPLANATION IS THEY ARE TRACKING YOU!!! PEOPLE WILL BE STALKED USING THIS!!!
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)
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.
Re:Sorry, disagree that SHA/MD5 is a solution (Score:3, Insightful)
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.