The default web browser from AOSP exposes your password in plain text!
The package com.android.browser uses the default webview which is fine until you click remember after entering your password. The browser caches the password for you so you don't have to enter the same password every time you visit the same page. Sounds good right? Well it usually is good... except the password is then stored in plain text in an SQL database at '/data/data/com.android.browser/databases/webview.db' in a table with the brilliant table name 'password'.
This is crazy and puts all android enthusiasts with rooted devices at risk. I beg of Google to fix it!
Its noteworthy that in Chrome this issue DOES NOT exist. This default behavior is however in lots of other applications that use the default webview to prompt for passwords. One such example was Trello. Once this oversight was pointed out they fixed and pushed an update within 7 hours, bravo! If an app asks you to login through a webview you should check that the app is not storing your password in plain text, use the directions below and sub out the package/app names.
Interested to see what is stored about you? (using the default browser enter your password in any website; click 'Remember'; done your password is now in plain text in a table called password... Epic fail!)
You can pull the database using adb (adb pull /data/data/com.android.browser/databases/webview.db .) then explore like you would any sql database.
or if you would like to view from your phone use SQLite Editor; in the apps tab click 'Browser' then 'webview.db' and check out the table named 'password'
All accounts are saved in this manor... including your gmail password
A screen shot of the plain text passwords :-/
**PS** AOKP is already hard at work implementing a fix for our fork of the AOSP Browser package!
Precisely why I wouldn't expect Google to fix this anytime soon.
In short, because you (the end-user) have futzed with your phone, and broken the security restraints placed on the Android filesystem, you have opened yourself up to vulnerabilities. It's your responsibility to manage what you do, and don't, grant root access, and if you pick poorly, you reap the benefits, much like installing some "Super Happy Funtime!" app from a Chinese warez site that has every permission possible. You can't be too surprised if next month you have a $10,000 bill due to the app calling and texting international premium numbers, and sending all of your personal information to every website the creator could think of.
So to summarize:
Not on a rooted device? Then Google probably won't care because the filesystem permissions will block any other app that doesn't have root access to your device from accessing that database file, and ADB isn't enabled by default.
On a rooted device? Then Google and your carrier/manufacturer won't care because you made that decision, and broke your warranty. You changed a critical function of how the system works.
correct me if im wrong, but i thought this was how most browsers (desktop) store saved passwords although some have a setting to encrypt passwords, but its usually off by default.
edit - which is why usually lastpass and keypass recommend turning that feature off and using their service solely (you know, besides self promotion)
This stuff here cracks me up. You have a device that is locked up for protection. You root said device. Then you are surprised by the fact that there is a security hole for a device that wouldn't have this unless you purposely removed security by rooting the device????? You should know what apps you are installing and what apps can access said personal information. Stop putting so much faith in a metal box that is nothing but small electric impulses.
Example: You buy a house with a lock on the door, you go ahead and remove said lock. You place an add on craigslist saying you may or may not have removed the locks. You come home and all your things are gone. Do you go after the company that sold you said house and ask for a refund?
Get you head out of your @$$ and be smart, "sometimes you need to be smarter than the device you are using".
This stuff here cracks me up. You have a device that is locked up for protection. You root said device. Then you are surprised by the fact that there is a security hole for a device that wouldn't have this unless you purposely removed security by rooting the device????? You should know what apps you are installing and what apps can access said personal information. Stop putting so much faith in a metal box that is nothing but small electric impulses.
Specious reasoning. An exploit can access it with or without root. Hashing a password takes barely any time from my development experience and no excuse for not doing it. One also has root all the time on PC, so I suppose we should just chuck out security on PC, because one has root there.
I don't expect Google to patch it soon, but I look at this as more of a call for all of the major ROM developers to do so as it concerns them more.
Easiest way to fix it is generated a private/public key and then encrypt the private key with a master password. if the password needs changed (or a site password does), one would have the user enter the password to decrypt. This is how browsers do it that give you a master password option.
You can't one way hash passwords that must be retrieved.
You can do two way encryption but that is only wasting cpu cycles when it a malicious user has root. They will just extract the decryption key and decrypt. Archon (good/smart guy/, myself and even a google employee (Nick, again super smart, nice guy) replied with nearly identical responses on this. There is nothing to patch, this is standard behavior in this case.
To prove my point, I eagerly await the release of it with encryption, expect a decryption tool release from me shortly after (ETA depending on if it is released during my trip or not)
If someone has access to [background=rgb(245, 245, 245)]/data/data/com.android.browser/ [/background]then you have a lot more problems than plain text passwords.
My argument is, it is better not to store passwords at all, but even more so when a device is compromised by default.
No expertise is needed to decrypt local, two way encryption. Hell, I am far far far from a crypto expert, but when the encryption routine is opensource (or easily reversed) anyone with basic java knowledge walk right through it.
It would remove no risks, you are missing the concept here. Security by obscurity is NOT the solution, but it is what you are proposing. Even someone from Google's own security team spoke up on this.
You can not secure locally stored passwords with two way encryption if the key is stored locally, hell even if the user has to enter another password we just listen to keyboard input, hell we are root, so lets just MITM the connection and grab the passwords as they are sent, SSL? hell were root we can add our own cert too. That is just as weak as storing them in plaintext.
Why would the attacker have to take it to a remote server to "crack" it, we don't have to crack it, we can just decrypt it on the local device, the phone it self.
EDIT
I'm done ranting and won't comment on this (here, I will continue on the bug report if it isn't dead yet) again, by all means go ahead and do this, but do not fool your users nor yourself into thinking it is more secure, it is just an alternative storage system.
This crap happens all the time, why aren't passwords and account info hashed? Rememeber when gizmodo called 4chan a bunch of script kiddies and then their entire clear text database got dumped?
Ok I lied I am commenting here. Jbird no offense, but I can't help it when you cant understand basic security concepts. I hope the code reviewers understand the subject more than you do at this point, I have a strong feeling this won't be merged into AOKP or any mainline rom. If it is, great! More fodder for my talk on rom security this Aug. I keep seeing people speak out about how "vulnerable" this is, when people who are paid to know (lets not count me, even tho I am) are straight up pointing out why it is wrong, along with citation.
Also, please learn the definition of malware.
droided again, two different things, you can't do salted one way hashs in this instance, then the browser could not retrieve the password for reuse. Again, local two way encryption is the only option, and it is just as weak as plaintext in this particular case
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Related Threads
?
?
?
?
?
Android OS Forum
1.2M posts
135K members
Since 2011
A forum community dedicated to Android phone owners and enthusiasts. Come join the discussion about applications, recovery, developments, styles, reviews, accessories, classifieds, and more for Unbuntu, Google Nexus, HTC, Motorola, Samsung or other Android models!