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.
I remember all of the mocking Android users did of Apple's security faux pas. Tables have turned.
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
Is obvious that someone complaining about software storing passwords in plain text doesn't know how things work.
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.
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 the TSA is fond of reminding us, security must be a tradeoff between ease of use and good security. So I'm guessing that solution will never be adopted.
Need a Python, C++, Unix, Linux develop
My phone's "power off" is a suspend-to-RAM mechanism by default. HTC calls it "fast boot". Only by disabling "Fast boot" is power off really power off. Else yanking of the battery becomes a requirement.
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.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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.
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 this is not possible for a service that only supports passwod-based authentication, but maybe Google could have provided a way of trusting them with your password (as in storing your passwords in their servers) and using a more secure authentication scheme on the smartphone--goog servers link.
Yup. Blackberry is the same way. Phone is never really 'off' unless the battery was pulled.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
They only found this out now?
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.
And where does the iPhone store the encryption key protecting those passwords? On the device? Makes it a little bit useless then.
As that article notes, you need physical access to the device. Not just being able to run software n the device, actual physical access to pull out the system keys.
You are trying to equate that to storing password in plaintext in a database that any app can just copy and send anywhere?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
My password already looks like it's encrypted.
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
yep, and you can't turn it off and then pull the battery. You have to pull the battery while the phone is on.
Did they take so many days to figure this out? I mean, Android was open source.
The problem is "keyless" (no password or secret bits needed) encryption doesn't actually add any real security because the passwords have to be accessed without being "unlocked" first.
What do I mean? Imagine you protect the password database with a single password (e.g. the unlock code). Now swiping the password database wins me nothing because it still needs unlocking. Now imagine I have a desktop with password-less autologin - my choices are now complicated. I must either
The first one is unweildly for a phone (does an unlock code really provide enough bits to securely lock the database?). The second and the third are effectively the same. In fact the second case reminds me of the old password database from Netscape where if you swiped the password database and a key file you could find out the real passwords.
Why not use a cookie sort of system like web browsers use? When I sign into yahoo email it will keep me signed in, but the browser isn't storing my password in browser history. The email protocols would need to be changed to support this though.
MD5 and SHA1? Are you serious? If they were in-fact stored as MD5 or SHA1, than those hashes would need to be sent to the mail server...in which case they are vulnerable to a pass-the-hash attack and would be just as effective as if they were in plain-text! In order for someone to get into your phone's SQLite database, it would involve stealing it and than running forensic tools until they found the database itself. And anyone here who assumes that there wouldn't be tools provided to decrypt any kind of potential Android e-mail encryption is fooling themselves.
A Android user complain that , All passwords are stored in plane text on Disk via a message on discussion board of Android.
so you see, it's not storing in "plain" text but in "plane" text which is completely different
obviously
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
What weakness are you talking about? GPP did not imply that rooting the phone causes /data to cease being off-limits to apps.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The link to the thread on Android SD protection did not work before so here it is for completeness.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
1. Lack of encryption was a complaint due to the fact that backups to the laptop happen automatically and is not encrypted by default
If that was an issue where do Android backups go if you synchronize them to a computer?
It seems like it's kind of hard to do a full system backup, but for those that do would not the database be exposed on the computer you are backing up to?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
sqlite is a crime. Linus should just hard code it into the kernel; the quality fits.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I will recommend the Android Pro to all my drunk-dialing and drunk-texting friends.
You are being MICROattacked, from various angles, in a SOFT manner.
"I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"
Why do I even come to slashdot?!...
I started reading slashdot for the articles/submissions... Then when the submissions went to shit, I read it for the comments... Now the submissions suck even more and all the comments just state that fact...
I think it's time for a break from slashdot! - afterall there are a lot more useful sites with 'REAL news for nerds' on it!
I develop for iOS and Android, and I am responding to your point about "twitter app directories".
I have produced only a single app which used twitter/facebook (I usually write enterprise apps), so I might have this wrong.
Twitter and Facebook both rely upon oauth, and both of these services provide libraries/jars for access. I think storing/caching a raw password is actually a ToS violation. I know my app doesn't store the password.
HTH
TPM itself isn't evil. It can be put to good uses also.
TPM with owner override can also be put to good uses, but the TCG has refused to implement it.
you say that like its a bad thing
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
That's a good point, although Twitter did not used to require OAuth...
But it stands for any other application that is holding credentials. I know I've used the keychain in a number of applications to store credentials.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
that they are storing to use to login, to say a mail server, is an idiot (or I guess running on a super computer or ten). Only beaten in the idiot stakes by someone suggesting it would be a good idea.
The premise is that if you have access to the keychain, you can decrypt the stored passwords. The keychain is, as you say, just another layer of security. It adds complexity to the system, making it harder to get the password back out, but it doesn't add any security; if someone has access to the keychain, it only requires a token amount of additional effort to acquire the password.
"Secrets are fragile; once they're lost, they're lost forever. Security that relies on secrecy is also fragile; once secrecy is lost there's no way to recover security. Trying to base security on secrecy is simply bad design. "
Bruce Schneier
The premise is that if you have access to the keychain, you can decrypt the stored passwords.
The Keychain has been around forever on the Mac and is a pretty advanced system for securing important data. It's more than just a single layer of security, it's a true security framework with many layers.
It can for instance require a passcode plus a salt. Please read through the extended details of how the iOS keychain works.
If you have set data to require the device to be unlocked, then if the user has a passcode having the hardware itself even means very little to you in terms of unlocking - you'd still have to crack it as if you knew nothing about the passcode because it's not on the device.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
SHA and MD5 are hash algorithms, there's no way to recover the actual password from a hash.
Interestingly, this is not universally true: hash algorithms can be used for encryption in certain block cipher modes. This was explained to me by user Goaway in this comment.
I concur that the submitter was completely off base referencing the use of hash algorithms in the context of stored passwords within a SQLite database. However, I believe the potential for nonstandard use of one-way hash functions for encryption to be quite interesting in a "thinking outside the box" sort of way.
It's hashing, not encryption you illiterate fucking morons.
Fuck you slashdot, you should know better. More than that, if my fucking mail password is hashed, it can't be passed to the servers. Slashdot is such a flaming piece of shit these days.
BeauHD. Worst editor since kdawson.
Since Android has access to the Javax.crypto API, just use it to encrypt the password before putting it into the SQLite DB. The SQLite DB interface in Android has an 'sql builder' interface, but the most useful way of doing things is using SQLiteDatabase.execSQL() which you can use to run any SQL rather than the crippling SQL builder type classes which can't do complicated joins etc.
Anyway, here is an example of using javax.crypto: http://exampledepot.com/egs/javax.crypto/DesString.html
WTF? How does it possibly stop you from removing the battery when the phone is turned off? Isn't the battery held in with some sort of mechanical latch, with either a slider, something to depress to release the hooks, or similar? Which blackberry model are you talking about specifically?
By reading this signature, you hereby agree with the content of the above comment.
The effect isn't the same. You'll get a better reset by pulling it while it's on. I'm discussing all models, I speak with RIM Support fairly often, you see...
I agree with all the one way hash arguments, but why couldn't they make an option to encrypt it with the PIN you already enter in to unlock the phone? Added bonus points for doing what Blackberry does and also encrypting it with the serial number of the device. Google really just needs to offer whole disk encryption. I know that both iOS and Blackberry now offer these features, I don't see why Google doesn't. As for the CPU cycles argument throw in a crypto chip to lower the power requirements and offload the power from the main CPU. What this guy is saying (while clueless) is still a valid problem. It would be nice in corporate environments to offer these features. Until Google offers whole disk encryption, I don't see them as a valid contender in the enterprise market.
Disclaimer: I own a Droid 2, and really do like it.
I have signed up for Google 2 level encryption, this means that when I need a password (to check my email for example) I have to key in my password (something you know) followed by a text token sent to the phone of my choice (something you have).
If you don't have access to your nominated phone there are other ways to obtain a token (you can ask Google to call you instead, an automated voice reads the token to you), failing that I have a series of valid tokens for emergencies, printed in an unmarked piece of paper (since the password in my head is still used the tokens can't be used on their own to access my account).
There is no reason why applications in Android phiones could not receive text tokens automatically in order to allow login.
If you are concerned about email security, use a BlackBerry.
You didn't actually read that thread, did you? Applications stored on the SD card are stored in an encrypted filesystem that's loopback mounted. The key stays on the phone, so the threat model you suggest doesn't work.
Yes, the external storage APIs don't provide security, but guess what: those APIs are intended for storing and accessing external files, i.e. stuff that's supposed to be public. Even with SD-based apps, the databases maintained using the system standard database API are secure.
Applications stored on the SD card are stored in an encrypted filesystem that's loopback mounted. The key stays on the phone, so the threat model you suggest doesn't work.
I did miss that part (I read through much of the earlier thread).
But it still doesn't stop an attack from another application accessing data from that mounted SD card on the device (which was always the greater danger anyway).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I enabled two factor authentication for my google account. I had to download a android app that generates new random 6 digit codes every 30 seconds. But for applications that don't support the extra code, google lets you create application-specific passwords. If I understand correctly, one one of these is used for one purpose they can't be resized for another.
A mobile phone has a SIM card inside; a SIM is a smart card, a tamper-proof device designed to store sensitive data.
If the password is stored on the SIM card, the phone could retrieve it from there, instead of storing it in its own memory. A SIM card can be PIN-protected, so effectively the PIN needs to be entered once - when powering up the phone.
This does not completely resolve the problem - if someone steals a phone and keeps it on, they can retrieve the password. However, a [smart] thief turns the phone off after stealing it; once they do that, they'll have to enter the PIN again when powering up the phone.
Now, the only problem is that many people have their SIM PINs disabled; but at least in this scenario you have some control and you can increase the level of security with little effort.
Note: the structure of the file system of a SIM card is defined in GSM 11.11 (for 2G) and there is a standard for 3G cards as well. There is no possibility to create new files on the SIM (it is not in the personalization phase anymore), so you'll have to keep the data in other files that are readable with PIN1, such as EF ADN or EF SMS (phonebook, SMS archive) - as modern phones don't use those files anyway. An alternative is to influence the ETSI, 3GPP and others involved in maintaining the specs and have this file for password storage added in the future versions of the spec.
The saddest poem
http://www.whispersys.com/whispercore.html
SHA/MD5 are not alternatives (already mentioned above) as they are one-way.
Real alternative is to have a standardized global keychain (like implemented by iOS), which doesn't offer extra security when there is no pincode set (other then obfuscation), but offers at least one additional layer with a password or pin-code actually set. (not to mention, with pin code enabled there is a free layer of hardware encryption enabled as well).
- Holy crap, I've got MOD points! Who thought that was a good idea.