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.
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.
Live today, because you never know what tomorrow brings
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?
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.
Yup, as an Android owner and developer I admit I've mocked other manufacturers for their school boy errors. Guess what my reaction was? Something along the lines of "oh for fucks sake, they had better fix this pronto".
That said, my fetchmailrc file on machines contain plain text passwords and rely on only the owner having read rights, so maybe I'm a hypocrite. Any encryption key will have to live on the device, so it'll be interesting to see opinions and suggestions.
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.
Where did it say that any app can copy it? They can't - it's stored in /data which is off limits to any app, unless you've rooted the phone.
Dilbert RSS feed
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
I don't think you actually understand anything about the issue. Do you know where the actual passwords on the device are stored? If you look into that, you'll see why further obfuscation is unnecessary. If a user can get access to the folder where these files are stored, they already have enough information to break any remaining encryption on the device.
It's sad that you see this as 'platform-centric hypocrisy' instead of what it is - a non-story dredged from a year old post by an Android engineer that only confirms what other rational people already know.
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
Rooting an Android phone doesn't break the security model either. It's not like apps suddenly run as root by default.
Apps can't read the database on non-rooted phones. So yes, you need physical access so you can root the phone first to get at the data.
There is nothing interesting going on at my blog
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
No, I did not. The negative of being off limits to any app is not being accessible to all apps.
When you root, it can still be off limits to any app as long as you don't run any app as 'root'. It doesn't break any security model more than having an admin account breaks the security for normal user accounts.
Dilbert RSS feed
From the GPP:
it's stored in /data which is off limits to any app, unless you've rooted the phone.
If that's inaccurate start by correcting the person I responded to, not me.
The person to whom you responded is accurate, as far as I know, but "it's stored in /data which is off limits to any app, unless you've rooted the phone." still does not imply that rooting the phone causes /data to cease being off-limits to apps. You're drawing a false conclusion.