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.
Re: (Score:2)
If the app-server combo has a decent session protocol, the app can get a session token from the server and discard the password.
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
Was just about to post the same thing. The OP seems to have no clue how password security works.
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: (Score:2)
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:
It might be nice to offer a choice, but I suspect most would end up choosing the current situation with
Re: (Score:2)
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
Re: (Score:2)
Usually passwords on mobile devices use the PIN as the encryption key (+ some large salt)
This is a possible approach; it has a potential drawback though. The phone cannot get e-mail in the background before the user types in their PIN, then. Also, PINs on a phone are likely to be simple, often numeric codes. If the user keeps their phone locked, they will want to have something they can key in very quickly to make a phone call in a hurry, which means that the PIN is likely to be brute forceabl
Re: (Score:2)
This is a possible approach; it has a potential drawback though. The phone cannot get e-mail in the background before the user types in their PIN, then.
Sure it can - store the PIN (or whatever key the PIN is transformed into) in memory after its first entered. The file is still stored encrypted, but the device can decrypt the relevant information once authentication has taken place the first time after booting. This is only relevant for polling-based solutions anyway; I believe most of the Exchange-based push services do some sort of long-running connection over a secure socket (I have done no research on that and could be completely wrong; and regardless
Re: (Score:2)
Re: (Score:2)
Oh yeah, people are known for having long PINs with a good mix of upper/lower case and symbols.
Not.
Salt? The whole point of salt is that it's known by the attacker. It's there to make sure that two identical files don't encrypt to the same cyphertext. It simply doesn't apply here.
There's not much you can do in this situation apart from asking the user to type in his email password 100 times a day. That would get old really quickly, I can't imagine many people would do it.
Re: (Score:2)
And, as a result, installing custom software requires jailbreaking the iDevice. I'm pretty sure thats the main reason (probably the only one, in fact) why Apple does this encryption. It also increases security, precisely because Apple can review every app that can be installed on the iDevice. The Android model is a bit less secure: but its far more open. Upping the security might be a good idea... but if it comes at the cost of this freedom and openness: then no. And yes, I realize not all Android phones ar
Re: (Score:2)
up front disclaimer, I hate Apple, and will not buy any of their devices for the forseeable future. But I have good reasons for this hatred, not all of which I have time or room to fit here. Now, lets try actually citing some sources here, shall we?
The release of the iPhone 3GS (and later iPod Touch 3rd Generation) brought hardware-based full disk encryption (FDE) to the iPhone. This was designed to accomplish one thing: instantaneous remote wipe....Jonathan Zdziarski found that the iPhone OS automatically decrypts data when a request for data is made, effectively making the encryption worthless for protecting data.
source [anthonyvance.com] . Some of what Zdziarski says here [zdziarski.com]. After a little more research, I discovered that apparently iOS 4 devices do use your passcode to encrypt the hardware keys, so they can't be read when you are logged out. source [wordpress.com] That is actually a reasonable system: th
The Thread on protection, a link (Score:2)
The link to the thread on Android SD protection [google.com] did not work before so here it is for completeness.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
And no data was. The database was local, and used to speed up location services on the phone.
In the ToS it says they may collect non-personal data for their own use, but no one has been able to demonstrate that they were actually doing that.
Regardless of what Apple were or were not doing, a major criticism from the Android fanboy camp was that this was all plaintext, making "tracking your every move" suspicious, and a massive privacy violation issue since anyone could get the data and work out where you wer
Re: (Score:3)
That is a troll. The big problem with the iPhones wasn't that it was storing data in plain text. It was that Apple was collecting the data without the users knowledge. Apple then used doublespeak to make their fanboys believe that no data was being sent back to the mothership.
Absolute rubbish.
1. It was in the EULA. Not hidden or obscured, but out in the open.
2. The data found was a cache of Apple's location database. It never contained your actual location.
3. One of the issues *was* that it was in plaintext. Go to the slashdot article about it and control-f for "stalker" or "police".
4. Apple never claimed (or implied) that data wasn't being sent to them. In fact, they specifically stated that this is exactly what happens.
Re: (Score:2)
processes are blocked from reading files outside of their sandbox.
This is partially true on Android as well. Processes can read the shared /sdcard (whether or not it is mounted to a real SD card - this depends on the phone), and their own isolated storage, but they don't get access to each other's storage or to the system. The password in question is stored in an SQlite database which is not accessible by any Android app (unless it requires root).
Encrypting such password is rather pointless, since the decryption key would necessarily have to be on the phone, as well - if
Re: (Score:2)
>The difference between this and iOS is that location data on the latter was accessible from iTunes when you sync the phone. Thus your location data would end up on your PC, which is presumably much less secure (at least for a casual user).
Sorry, but right now I am more concerned about my bank and email accounts being stolen, than my location being on my PC. I bet you $100 USD that if we made a Poll in slashdot pools, my "worry" would outvote yours.
Re: (Score:2)
Your bank/email accounts are exactly as likely to be stolen on iOS. There's no way around the requirement to store your email password on the device, unless you want to enter it every time you check email (and then bye-bye push notifications!). Encrypting it doesn't help because the key would still be on the device as well - in the end, you have to have the password available in its original form on the client at the moment authentication happens.
Yes, the Apple location story was vastly overblown. This one,
Re: (Score:2)
The big problem wasn't the plain text, although that concerned some people, but the fact that the amount of data retained was all out of proportion to what is necessary.
Re: (Score:3, Insightful)
Re: (Score:2)
and processes are blocked from reading files outside of their sandbox.
which is the case here, applications cannot access that password db.
Re: (Score:2)
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!!!
People (including many iPhone owners) were upset because Apple was storing location data at all, not because it wasn't encrypted.
Somehow, the OS X and iOS keychain manages to use encryption to protect passwords
Keychain stored passwords are encrypted using a key derived from data on the device. Encrypting data and storing the encrypted data on the phone along with the decryption key provides no security benefits - apparently it's trivial to extract Keychain passwords once you have software running as root on the device, link [pcworld.com]: "The attack works because the cryptographic key on current iO
Re: (Score:2)
And where does the iPhone store the encryption key protecting those passwords? On the device? Makes it a little bit useless then [msn.com].
Um, the encryption key has to be on the phone at some point for it to work. Do you even understand encryption?
And the only way to keep it from being stored on the phone is to require some method for acquiring the key, either from the user, or from some external source (online, dongle, etc.).
You have severely misunderstood the article you linked to.
Go look at a blackberry to see disk encryption done properly - the key is not stored on the device, it's the derived from the user passphrase.
First off, I don't think you've described how it works on BlackBerry correctly. Second, the way it works on the iPhone is a key is generated, then it is encrypted
Re: (Score:3)
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.
Re: (Score:2, Informative)
Rooting an Android phone doesn't break the security model either. It's not like apps suddenly run as root by default.
Re: (Score:2, Troll)
They can't - it's stored in /data which is off limits to any app, unless you've rooted the phone.
Which as many Android enthusiasts point out is terribly easy to do. While it does not affect every user it affects huge subset of users.
On the iPhone, even if you've jailbroken it there's no such weakness thanks to the Keychain. Jailbreaking allows side loading, it does not break the entire security model and expose things as basic as email passwords.
No such weakness? What weakness are you talking about? GPP did not imply that rooting the phone causes /data to cease being off-limits to apps.
Re: (Score:3)
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.
Re: (Score:2)
If that's inaccurate start by correcting the person I responded to, not me.
That is accurate though because if you haven't rooted the phone you cannot run an app with elevated privileges and just because you've rooted the phone doesn't mean everything runs with elevated privileges, it just gives you the ability to do that.
Re: (Score:3)
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.
Re: (Score:2)
Which as many Android enthusiasts point out is terribly easy to do. While it does not affect every user it affects huge subset of users.
In Linux a process will only run as root if you run it as root. A random process will not suddenly start running with root priviledges just because you enabled root logins (which is all that "rooting" does).
On the iPhone, even if you've jailbroken it there's no such weakness thanks to the Keychain. Jailbreaking allows side loading, it does not break the entire security model and expose things as basic as email passwords.
Apparently that is not true. According to this [pcworld.com], you can access Keychain passwords if you have a jailbroken phone: "The attack works because the cryptographic key on current iOS devices is based on material available within the device and is independent of the passcode." Well, that is pretty much the same
Re: (Score:3)
Re: (Score:2)
Oh look, another dumb person thinking that Slashdot is a single mind.
Where did you get such a foolish notion?
Re: (Score:2)
Hint: the location database cache was not "secretly mining location"
Hint: Apple did tell their users.
Hint: Lack of encryption was one of the complaints against Apple.
Re: (Score:2)
1. Lack of encryption was a complaint due to the fact that backups to the laptop happen automatically and is not encrypted by default
2. Most complaints are worthless because they either overlooked that apple's EULA stated they were allowed to gather location, or they overlooked that this data was not sent back to apple, at least not in a way that could identify (and thus track) anyone.
3. This iOS vs Android comparison is pointless IMHO.
4. The article itself is pointless: There is no way around password-base
Where then is it? (Score:2)
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?
Re: (Score:2)
You don't. Everything relevant is in the cloud. In Android no such scenario even exists.
While there are ways of syncing stuff, no user usually connects their Android phone to their computer, especially not for doing full system backups (thats only possible for rooted users, if I'm not mistaken, so go figure)
But anyways, thats comparing iOS and Android again... even if Android did, that would still be something people could be criticizing of iOS (and Android, but thats not the case).
Re: (Score:2)
I didn't study engineering and I don't program and have no security focus, yet....
>The article itself is pointless.
It's not. it made me aware how losing my device can be very dangerous, even if I am using a password. So I will take some precautions in case I lose it. This is just my personal "why". There may be a 100 others very valid reasons.
>There is no way around password-based authentication systems' passwords being recoverable from the device;
There is. If things are more complicated, you reduce t
Re: (Score:2)
I take it that you don't fly very often.
Maybe you should get a phone with an 'aircraft' mode...
Re: (Score:2)
That's because they want to have your full attention during takeoff and landing, not because of radio interference. You know, using fear as the default instead of a perfectly valid explanation that people will probably be happy to comply with.
That also varies by airline. I fly Virgin America all the time and they're quite happy with airplane mode; Continental and United have given me similar experiences. Policy != science.
Although to back the point you're trying to make - airplane mode is a software-based
Re: (Score:2)
I've never, ever, seen a phone that requires you reboot it to enter flight mode. On my IDEOS running Android, it's a long push of the power button until the menu appears, then select "Flight Mode" and off go the radios. On my iPhone, it's Settings, Airplane Mode, On, and off go the radios. On my LG running Windows Phone 7, it's Start, Settings, Flight Mode, On, and off go the radios.
Re: (Score:3)
I take it that you don't fly very often.
Maybe you should get a phone with an 'aircraft' mode...
Maybe you should trying buying me a phone that does not require being powered off in order to be restarted in flight mode. (Which requires entering your PIN, if you' ve not disabled it). Every mobile phone I've ever owned has worked this way. Including my 2-months-old Samsung Galaxy.
You... are not making any sense. My Droid Incredible has a widget
with an airplane on it. Click it, all radios are killed, unclick it, all radios
are back on.
-AI
Re: (Score:2)
yep, and you can't turn it off and then pull the battery. You have to pull the battery while the phone is on.
Re: (Score:2)
Well submitter is clueless... (Score:3)
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.
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.
Trusted Platform Module (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Doesn't really help for PLAIN or LOGIN methods though, does it?
Or even DIGEST, really. That stuffs simple to break.
Re: (Score:2)
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
Re: (Score:2)
Encrypt The Phone (Score:4, Insightful)
Re: (Score:3)
Long passphrase: Feature, not a bug (Score:2)
Re: (Score:2)
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:Old News (Score:4, Interesting)
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.
It matters (Score:2)
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.
Re: (Score:2)
Exactly. If Apple does it wrong it's the end of the world. Android does it then the fandroids come up with some technical excuse as to why doesn't matter to them.
SSL is supported on my mail accounts these days to stop accounts being harvested and used for spamming.
Re: (Score:3)
Sounds like you're a bit of a sore Apple user...
To somebody that is more objective on the topic, he sounds like somebody who thinks noisy Slashdotters should at least be consistent. The whole 'competition is good' principle falls on its face if one company is held to a different standard than another's.
Re: (Score:3)
I think he made a very good point--that if this wasn't about Android, it would be treated as a big security issue. When it's Android, or more correctly, Linux, there are justifications and excuses made.
Calling him names isn't going to change the validity of the point he made.
Re: (Score:2)
So the thrust of your argument is "bias is expected, and it doesn't matter if we're inconsistent, and you're a "sore loser" if you call us on being biased and hypocritical".
Gotcha.
MD5 is not encryption (Score:3)
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.
Re: (Score:2)
Correcting myself, SHA is a hash function too. I got it confused with the public key encryption.
Re: (Score:2)
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
Public key cryptography (Score:2)
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
Re: (Score:2)
If you want a device-specific password, Google already support that for their services through their two-factor authentication with applicatio [google.com]
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
How many Googles are there?
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
I believe you're also free to set your Gmail password to be 100 characters, making it effectively 'unguessable'.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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)
Re: (Score:2)
Yep, I agree with you completely. That's what I'm trying to defend against.
Cant get too worked up over this. (Score:2)
Password system's fault (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
No SSL - that's the real problem (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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)
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.
This is how all the hacks occur... (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Is obvious that someone complaining about <strike>software</strike> Android storing passwords in plain text doesn't know how things work.
FTFY
Everyone knows storing passwords in plain text is the worst possible way to store a password, and there exist ways (such as the OS X and iOS keychain) to store passwords that aren't so abysmally trivial to access.
But since this is Android, well, it's *stupid* to point something like this out! If it were iOS, though, the tone here would be very different. In fact, back when iOS stored the location database cache (*not* a list of where you were, but the cache of Apple's much larger location database, whic
Re: (Score:3)
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 onl
Re: (Score:2)
Absolutely incorrect, and a perfect example of the Android fanboyism I was talking about.
There's absolutely no way to argue against the idea that plaintext password storage is the *worst* way to store passwords. Period. There is no further discussion.
Storing them in a place that is normally restricted is better than just storing them in the user's home directory, or in a globally accessible location. But to say there's no reason to encrypt the password is absurd. Somehow Apple does a great job with the keyc
Re: (Score:2)
Further, the "hypocrisy" here is that when Apple stored a location database cache in plaintext, you lot were up in arms.
Yeah, don't think that was about it being in plaintext - it was about it being recorded at all, in secret, and then it being transferred to your PC, also in plaintext, and very easily available. The passwords in plaintext on the Android device are stored in a folder that cannot even be seen unless you root the phone, let alone access - and even then you're still subject to the usual sudo-style admin permissions to give apps access to it.
That is absolutely incorrect. See the iOS/OS X keychain for more details.
What, this iOS keychain? iOS keychain system crack can expose passwords [appletell.com]
Re: (Score:2)
You should not generalize because many of those that are saying that this is a non-issue were not necessarily criticizing that same thing about iOS. See this other reply next to me, you are just accusing people of being hypocrites without any "evidence" and its making you look like a fanboy.
Also, AFAIK Android *does* store those passwords in a restricted place where no other app has access to; certainly not a globally accessible location like the users' home directory like you suggested. The fact that this