Slashdot Mirror
Android Password Data Stored In Plain Text
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!"
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.
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.
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?
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.
Program Intellivision!
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.
Assorted stuff I do sometimes: Lemuria.org