Yesterday, I reported on a story that I thought was huge at the time: a security hole was discovered (or some might say rediscovered) in the AOSP Android browser, in which remembered passwords are stored in plain text in a database that any app can access, as long as you’ve granted root access to it.
Many people have since downplayed the significance of this find. One Pocketables reader commented:
Are you serious? When a browser (or any other program, for that matter) “remembers” a password, it has to store it somewhere. Plain text or scrambled – doesn’t matter, because the password retrieval has to be reversible. Other than implemeting a master password, there is no way to fix this, and I don’t think many people would like to be constantly prompted for master password.
The official Google bug report was also recently closed and given “working as intended” status. There is also some interesting discussion over there as to whether or not this is really as serious as some people are making it out to be. One contributor to the bug thread stated:
What’s the proposed solution? I mean, this is visible only with root, and if you have root, you can extract any info you need to re-create the password the same way a browser would, especially since Android is open source – this would be trivial to dig up.
The key issue is that Android needs to be able to decrypt these, so they can’t be one-way hashes, and at that point any feeling of added safety due to possible two-way encryption would be false.
Personally, I think there’s still reason to be alarmed here. I am by no means an Android security expert, but it seems to me to simply be poor practice to store any sensitive information in plain text, period.
Yes, I already understand that if the data was encrypted locally, and someone obtained the rooted device and was able to decipher the encryption key, then the passwords would still be visible – but there still needs to be that extra layer of protection. Otherwise, that’s tantamount to saying, “I’m not going to lock my front door, because if someone really wanted to invade my house, they’d just break through my front window.” People still take those extra steps to be safe, even if they are not foolproof.
Others argue that since this only affects rooted devices, and people who root their phones already know they are taking a risk, that this concern is moot. Furthermore, as a security measure, stock Android devices are programmed to factory reset when rooting, precisely in order to avoid this issue – therefore, if someone attempted to root your phone to view your passwords, the information would theoretically be wiped in the process.
Again, this isn’t necessarily the case: many, many Android devices have vulnerabilities that allow hackers to unlock bootloaders and gain root access, without wiping the device. Yes, these aren’t “officially supported” methods of rooting, but these vulnerabilities exist. And if someone is smart enough to know how to read your passwords, they are probably smart enough to know about these vulnerabilities, too. Therefore, even unrooted users aren’t totally safe
Simply put, some other browsers just handle this better. Chrome, for instance, handles remembered passwords remotely through the cloud. Your device is authenticated through an oAuth token, rather than a plain text password, which is sent over an encrypted connection. In other words, Google’s secure cloud storage is much more secure than storing your passwords locally in a plain text database. Furthermore, since Chrome is already experimenting with remote servers to handle data compression, it’s possible that your passwords will be even more cloud-based, bypassing the need for any local syncing completely.
A Google project manager wrote in that bug thread, “As others have pointed out, any obfuscation we do here could be defeated by an attacker with root access. We often decline to add ‘security’ enhancements when we know they could be defeated, instead preferring that users understand their risks.” That’s very disappointing, especially from a company that’s usually so concerned about security.
You can either leave the front door unlocked, because the windows can be broken anyway, or you can do your best to put every single reasonable security measure in place that you can, without compromising the user experience too much. But since it seems an official fix will not come, we’ll just have to wait for the team behind AOKP to finish its work.
Good article. I agree that having lax security because “why bother when it can be defeated” is pretty lame. I do agree that with Google that people who root their devices should know and understand the potential, albeit unlikely, risks involved. That doesn’t mitigate the fact that any additional layer of security is a good idea, even if it is defeated, it can slow a would be data thief down, perhaps.
I don’t claim to be a security expert either, so I say the above with an idea of common sense. The vast majority of the time, if people who are rooted (or even non-rooted folks) just practice common sense with apps and permissions, and don’t side load from untrusted websites, they will be golden. I know there’s the scenario where you lose your device or it’s stolen. Despite the most valiant attempts at security, someone may still be able to root your device or gain access via recovery or the bootloader. Nothing is foolproof. The best we can do it be vigilant and proactive on good security practices and that includes the software developers (Google too!).
But firefox and chrome browsers on a home computer do the same thing don’t they? On chrome go to settings/passwords and forms/manage saved passwords. What’s the difference?
never-mind… now i get it lol
The problem isn’t analogous to locking the front door so that they have to use a window – it’s more like locking the front door, but leaving the key in the outside lock. Any application with root would be able to decrypt anything stored without a master password, because the key would have to be either hardcoded or generated. Yes, you add the additional step of having to get the key, but if you’re reading from the browser database anyway it would quite literally be only a few more lines of code. I happen to agree with Google on this one – I would rather have someone go “maybe I won’t store my passwords because they’re in clear text” over “oh, it’s OK because they’re encrypted” given that the encryption is by definition trivial to override with root access – and without root access you can’t read the database anyway!
To preemptively answer a point that may be brought up: yes, obfuscation (I’m not even going to call it encryption without a real key) would make generic “scan the entire device looking for passwords” attacks harder – they’d have to actually target the browser. However, weighing that against the risk of someone storing a password *thinking* it’s secure, I’d still rather leave off the facade of security and make it obvious that the passwords could be compromised.
The problem with that is most people have no idea that this is all going on in the background, so it’s not obvious. When they store their password, they assume it’s safe, and I’m not saying it’s the smartest thing to assume that (it’s definitely not), but I’d bet you that most people do just assume Google has them covered and their passwords are locked down.
I do agree with Google in that I’d rather know how my passwords are being handled, than not know. I just think that this “let them fend for themselves” attitude isn’t really going to work well with most of the folks who use their phones and just expect them to work and be secure. I guess the best thing to do, would be to educate people on it, but if Google is giving out caveats on its security practices and coding, that looks bad. It’s quite the dilemma, actually.
Completely agree with Patrick. The assumption that obfuscation would slow an attacker down is simply incorrect. We forget that attackers rarely invent things; most of the time they just use a program/script (usually written by somebody else). From this standpoint it doesn’t really matter whether passwords are clear, obfuscated, encrypted with a well known key… The program gets the data anyway, and the slowdown is really in terms of milliseconds.
I agree with him in that obfuscation only slows someone down so much. However, just trusting that people will understand why their passwords are in the clear doesn’t sit well with me. Your average casual smartphone or tablet user isn’t going to understand why their passwords aren’t more securely stored, and in turn, it will look like shoddy coding or a lack of care on Google’s (or any developer who has an app that stores passwords) part. I totally understand the reasoning WHY it’s not done, though, because it won’t do a lick of good unless you use some kind of master encryption key you input yourself every time you want to have access to a site’s stored password, otherwise the encryption can be reversed and figured out.
Perhaps Google should just disable password storage on the device completely from the stock browser, unless a user creates a custom master encryption key to use with their stored passwords. It’s more tedious, but it’s more secure.
Having your browser remember your password is the insecure part here.
… in the same way that having your Android device remember your google account password
Lol big brother is watching you, see windows 8!
heck even pidgin the open source im client for windows stores passwords as plane text as frankly if you have physical access the point is moot even if the app uses some for of crpyto you could relatively easily decrypt it as it has to be readily assessable when ever the user request it. in short no issue if you dont root and if you are that worried use keepass to store your passwords and never use a browsers built in password manager.