Why there really is cause for alarm in the way the AOSP Android browser stores passwords
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.
