Android saves wifi passwords in plaintext to the cloud
code.google.com
code.google.com
If you were to encrypt passwords in the cloud with a key that's stored on the device, you can't unlock the passwords on a different device (or the same device after flashing), which is the whole point of backing it up in the cloud.
If you were to encrypt them with the user's Google Accounts password, the device would need to ask for that password on every startup or store the GA password on the device at all times (the latter option is a far greater evil than the current "situation"). As long as Google is ever given the clear text password (i.e., before hashing), this would be open to interception by Google -- or infiltrators thereof.
If the GA password were to be used to authenticate in a way where Google doesn't get access to the clear text password (through digest-like authentication), a user wouldn't be able to access the backups after resetting her password. However, this method is not reliable if you don't trust Google (or its infiltrators), because Google provides the clients that would do the hashing before sending the password, so they could obtain the clear text password (by skipping the hash step, or by sending it through side channel) on any client they control such as HTTP login pages or mobile apps provided by Google.
Like all things security, it's a trade-off between security and convenience.
Of course, many people would set the pass phrase when they set up their phone and promptly forget it, making their backup useless. (I've done forgotten enough crypto keys myself to know...)
Like you say, it's a tradeoff, but the Chrome team has been able to make it work with Chrome Sync. Of course, you only need to set up Sync once, and if you forget your Sync pass phrase you're not losing much. Perhaps the Android team decided that pass-phrase-encrypting the backups would cause more problems than it might solve.
nb: I am a Google employee, but I have no inside knowledge of any of these products nor the decision making processes of their teams.
The shared key could be backed up to Google's servers and encrypted using the user's password so in the event of a new device/flashing the shared key could be re-downloaded.
Then you only ask the user once for their password.
Google gets subpoena'd for your data. At next logon they capture your password and grab the key. There goes your data, including your wifi password or whatever else.
Of course I don't think that this would ever happen, and even OP's complaint is a bit unnecessarily paranoid in my opinion. But there's your answer.
EDIT: However this might be plausible if the stored key was also encrypted with some sort of passphrase or PIN that was not known to Google, which I believe is how Chrome does it currently.
https://support.mozilla.org/en-US/kb/firefox-sync-data-secur...
Setting up a password for an Android device only needs to be done once for each device->network pairing. The reuse of Wifi passwords across devices is an edge case given the predominate ownership pattern of Android devices - i.e. most people have a phone that runs Android and no other Android device.
Google's scheme allows them to harvest the passwords to a vast number of wireless networks.
Google has harvested the location, name and signal strength of many millions of wireless networks across the world - an act which can be in no way cast as user convenience.
The very best possible light for this nexus is that it only appears to be a very very bad thing.
The only means by which Google profits is by monetizing data leaking from my device. And my WiFi password is something potentially monetizable. When choosing between ignorance and malice as motivations, it is perhaps proper to choose ignorance even with Google. When choosing between my privacy interests and Google's monetary interests, it seems naive to place my privacy interests above those of Google's actual customers.
An American corporation is determined to be part of the military-industrial complex; film at 11.
You have no idea what you're talking about. It directly profits from sales on the Play Store(apps, movies, TV shows, magazines, music) and advertisement clicks. They also benefit from building better user profiles, so they can better target advertisements.
It's very convenient to me. I have both an Android phone and tablet. I've also switched Android phones multiple times- it's been quite gratifying to return to a city I visited three years ago and have it automatically connect to the WiFi hotspots I used back then.
How many APs do you even have to use regularly?
And slightly related, do you have two factor enabled on your email or is that the end of modern life convenience as well?
Let's see, I've got a private side and a guest side wifi at home, no less than three at work depending on location, the motel I usually end up booked in for trips, local bars and restaurants.
So i'd say.. probably 10ish in a given month? Sometimes more?
And you're presenting a false dilemma here. Of course I'd prefer this information be encrypted. I was simply replying to the OP that stated WiFi saving could be in "no way cast as user convenience".
i'm already exposed to the phone operator issues, don't want to have to worry about coffee shops and hotels.
...as using those networks is the very reason passwords in plain text is an issue! you guys are just making your situation 10x worse with this convenience.
And collecting data on every network was what I said could not be cast as user convenience, so it appears that my statement has been taken out of context and then strawmanned.
In no event, however, is it a case for storing those passwords as plaintext.
Don't forget that that dataset of wireless locations is updated continuously through crowdsourcing.
Along with Apple, Skyhook, Nokia and a number of other location providers.
I wasn't too worried until I read this from you.
It's not as if the government could compel our friends at goooogle to give up said passwords.
Besides, you don't have anything to hide. Do you?
It's easy to see the user-experience story for this. Upgrade your phone, buy a tablet, etc, and as by magic all 10 wifi networks you use work without any configuration. No need to type that 32-character nuisance of a WPA2 password again, etc. How lovely!
Your conspiracy theory hinges on the idea that Google wants your precious wifi password for themselves, not for your convenience. That seems unlikely. Google doesn't care about your network. They might care about your web usage patterns insofar it makes it easier to provide better search results and improve ad targeting. Your network is worthless for that. Using the passwords to actually access these wifi networks would also be a massive legal and PR nightmare.
So on one side you have delighting users. On the other side you have a malicious attempt to gather useless data at massive risk. How can there even be a question of which explanation makes more sense?
Apple solved this by supporting local backups. My phone backs up to my computer. When I restore to a new device, the backup goes with it.
When I set up a completely new device -- which happens only once every couple of years -- I set up WiFi again. I've never, ever, ever thought "oh wow, setting up WiFi is just So Hard! I wish Apple would store my private WiFI password on their servers by default without telling me first!".
iCloud backup does store your data on Apple's servers, but it's opt-in, and it makes it quite clear what will be stored.
Home, work, the office where I do side work, my in-law's house at the beach, my parent's house in another state, multiple friend's houses that I frequent, my doctor's office, local restaurants, etc. Some of these places are cell signal dead zones and the only way to get a signal is to connect to WiFi. Plus WiFi is faster, more stable and doesn't cut into my limited cell data plan.
And these are just the ones that I remember.
No need for plaintext on Google servers. No way for monetization by Google.
Or to put my alternative another way, how much is a data set mapping WiFi passwords to networks for the city of Bejing worth to a foreign intelligence agency or other state-level actor? An answer in terms of dollars or 1000 clicks is equally acceptable.
As an alternative, how much is such a data set for Redmond worth to Google?
For extra credit, determine the value of each data set if includes historic data on password changes, changes to the individual password repositories of each user, and changes to the densities of WiFi networks at specific locations.
In the end, it comes down to money in Google's bank account, not delighting users (see Reader). Since Google does not directly profit from the sale of nearly all Android devices, the burden for the thesis of delight is to show an alternative mechanism by which Google directly profits from the plain text storage of passwords.
So you want _yet another_ password between the user and his magical experience or whatever ?
I see myself as a "privacy enthusiast", and even I recognize that wanting to encrypt wifi passwords in this way would only appeal to ~0.01% of android users.
You could argue that google could make this an option hidden under the three dots / context menu / whatever that thing is called, but there's probably much lower-hanging fruit than this.
I find this a pretty weak objection. Do you really want to trade all your stored passwords for the convenience of not having to enter 1 additional password ('my Android backup password') once every one or two years when you activate a new or additional device?? I wonder how this objection rhymes with having logins on 20+ different websites?
While I don't believe that Google wants to harvest your WiFi passwords (but also don't rule it out), I also don't think it's all that paranoid to assume that Google deliberately chose to not encrypt backups by default, so they can extract useful information from Android device backups. Or do you still believe Android is 'free' because Google is a charity?
Now, in the 0.01% case, your counter argument still doesn't hold, in my opinion:
> Do you really want to trade all your stored passwords for the convenience of not having to enter 1 additional password ('my Android backup password')
Yes.
Even strong wifi passwords can be brute-forced within minutes from the curb by anybody with an unmarked van and a measly few GPUs. At this point in the technology race, wifi passwords are really just keeping the honest people out. If you want something stronger, you're going to have to go to machine certificates on each laptop / mobile device.
> once every one or two years when you activate a new or additional device??
Even worse, passwords that aren't used often exit my fingers' memory and are thus lost to time (unless I write them down and store them in my safe deposit box or keepassdroid or whatever, but "hardly anybody" does this, so Google would get phone calls from users every year or two saying "can you give me the password that I'm supposed to be using to keep from giving you my passwords? kthx").
I found some Toms Hardware article that goes into "a few GPUs in a desktop" all the way through "renting 20 machines with GPUs from EC2 for a while for <$20 USD", and it seems like a password that is long (>=12 characters for now), doesn't have dictionary words, and uses more than just [a-zA-Z0-9] will be safe from undedicated adversaries for a number of years (probably the life of whatever router you're using).
In general, I'm not sure this is a valid threat model. If you're not trusting Bob with your Wi-Fi passwords, why are you trusting him with everything else? If anyone compromises Google, there's far more valuable data on your account than the Wi-Fi list. Even if that's all they gain access to, it's pretty hard to exploit remotely. If someone is targeting you at this scale, you have bigger problems to worry about.
Note that non-targeted attacks (the type that leak password lists) are not a serious threat here.
What would such a data set of Redmond be worth to Google? Nothing. Because accessing those networks for industrial espionage (if I read your innuendo right) would be illegal and immoral. It would drag Google's name in the mud, lose them customers, credibility, and most likely a decent chunk of talented employees. The liabilities would be massive. And what's the gain? I don't know what you think it would be, but it'd have to be pretty damn valuable to outweigh the potential costs.
As for monetization... Android is a moat. The way things are going, whoever controls the client operating system controls the default web browser and the default web search. This is an existential threat to Google. Microsoft winning the mobile OS war would soon make Bing the leading search engine. Apple conclusively winning would allow them to charge monopoly rents on access to the users.
It's like Google Toolbar back in the day. It's possible it provided some information about user behavior. But the real value came in that it added a visible Google search box into IE.
Google made $10 billion last year.
In a cyber-war, how much would the Kremlin pay to disrupt every Chinese WiFi network to which an Android device has a current password?
In a shooting war, how much would the US pay? Keep in mind that the modern battlefield increasingly uses ordinary data devices particularly in counter-insurgency operations.
Jim McDonnell, Donald Douglas, Jack Northrup and Leroy Grumman did not start out as defense contractors. They diversified their corporations when voluntarily seizing the opportunity was a good alternative to the threat of compulsion during the Second World War.
This may in fact be the one time that the rules are different. But there's very little historical precedent upon which to premise such a belief. GM produces military vehicles. Westinghouse and GE produce powerplants for ballistic missile submarines.
[edit] The question of how plaintext leads directly to Google profits remains unaddressed. It is not as if Android users can recover their passwords by calling up Google customer service. On the other hand, storing passwords in plain text is usually a decision made to facilitate requests from a company's customers. Asking who constitutes Google's customers is a reasonable place to start when inferring motives.[/edit]
I look at the money.
In a cyber-war, how much would the Kremlin pay to
disrupt every Chinese WiFi network to which an Android
device has a current password?
I'm serious: You need to consider the way Google is run before deciding if any of these theories are plausible.
This is a company which has a history of spurning money-making opportunities in favor of some higher ideal (often times to the chagrin of business-minded types within the company). To give a few examples: Licensing Android, complying with China, accepting paid placements, etc.
You can argue each of those decisions was actually more profitable for Google in the end. And that's the point: Google would not make $10B next year if they sold out their users to the Kremlin this year.
But lest my meaning is misunderstood, an offer from Fort Meade might be one Mr. Page gladly accepts as a US national - I certainly have no more reason to question his patriotism than to believe it to be partisan in the extreme.
Even removing patriotism from the equation, developing and maintaining good relations with governments and their agencies involved across national borders probably makes sound business sense for a company of Google's size. And I have little doubt that Mr. Page places substantial value on international business opportunities.
Absolutely. His price is letting him remain a billionaire. I'm of the opinion that most billionaires would sell their own mothers to organ harvesters if failure to do so would result in them becoming poor.
If it's a device password, enjoy re-encrypting if they change it. Or handling two device passwords.
If it's a user password, then how do you change encryption everywhere when they change their password? Only option there is to have Google decrypt and re-encrypt it and push it to every device, since otherwise you losing connection means corrupting your backup, at which point they have it in plaintext, no difference.
Example: Oh you thought you were accessing Facebook, bank, stock, tax... oh you are... but first you are passing along your password to a third party.
Also, once you gain access to the network, what percentage of networks allow administrator access over wi-fi? I would bet a good percentage. What percentage of these have the default password? Again, a good percentage. So basically, you can hijack quite a few networks this way. Do you know what most routers keep a log of? Your entire browsing history. Do you know what else you can do to the network? Open up inbound ports.
Note: The impersonation attack may work even without passwords. Figure out what his/her network name is. Give your network the same name. Scramble the signal coming from the other router. Have him/her enter in a password to your network. Voila.
Really?
> It's easy to see the user-experience story for this.
It's even easier to see how handy millions of wifi passwords might come in handy if you already have the information about the wifi networks you got from war-driving (street view).
You now have access to millions of (private) networks all over the world which you previously had not.
It's even easier to see how handy millions of wifi
passwords might come in handy if you already have the
information about the wifi networks you got from
war-driving (street view).
Talk to a real live Googler (they exist!). Any one of them will tell you that:
(a) the war driving thing was one engineer's massive fuckup that was never wanted for any product, and the data was quickly quarantined (and only kept alive due to legal proceedings), and
(b) anything remotely close to nefarious conspiracy theories being posed for this .. sync protocol .. would never, ever pass peer review internally (let alone the flames of eng-misc).
User data confidentiality is one of (if not the most) serious topics within Google. Again, don't take my word for it, ask someone else.
To suggest that Google is collecting customer passwords for the express purpose of future network intrusion, or to share with spy agencies, is just ignorant.
https://support.google.com/maps/answer/1725632?hl=en
Are you saying this service was shut down despite all indications to the contrary, or are you disputing the method used to collect this data?
http://googleblog.blogspot.com/2010/05/wifi-data-collection-...
In addition, given the concerns raised, we have
decided that it’s best to stop our Street View
cars collecting WiFi network data entirely.
It looks like that blog post only states that they deleted the erroneously collected network data.
Not every feature in Android is designed to be monetised. Google develop Android with the intent that users will use their app store/click on Google provided ads. They can only do that if they are seen to be offering a competitive, feature full product. The cloud-based syncing of your phone configuration is one of those features.
Having worked in various large organisations (including ones which are definitely part of the military-industrial complex) I can say wholeheartedly that there is no grand conspiracy. Most people, wherever they work, want to produce the best product they can.
Yeah, excepting the whole NSA issue, the fact that Google was previously caught/accused of war-driving every wifi net they could see with their streetview cars etc.
While the feature may be convenient, that does not preclude the worst case from also being true.
Facebook is convenient, but its pretty well proven now that the data conveniently stored within is harvested and mined by "infiltrators thereof"
I am a bit amused when folks trot this out and forget to mention that Google itself discovered this, voluntarily came forward, owned up to the mistake, provided the information to the prosecutors and paid the fines related.
You would think if they were so determined to continue with this nefarious activity they might have been a bit more mum about it.
Facebook (and google) do "harvest" your data. They also mine it for relevent information from which they can show you adverts. There's no debate about that. It's not a conspiracy though - they state in their privacy policies that they'll use your data for targeted adverts. It's their revenue model!
Google's pretty clear on their motivations here. It's the same reason that they back up what you have set as your background. It's not about multiple devices, it's about fungible devices.
The result is that you log in to any fresh android device and in a few minutes it's automatically configured itself. If you wipe your device, or lose it, or whatever, replacement cost is the biggest issue.
As for the harvesting of signal strength and name of wireless networks, the user convenience is that Google Maps will work even when you don't have clear line-of-sight to GPS satellites in most places. That's pretty darn convenient.
I think it's bad that they have this data, because the potential for abuse is large, but please don't suggest that there aren't clear and benevolent reasons for these decisions. It's extremely rare that people do things with obviously dubious motives. This is clearly not one of those cases.
Yes, I'm a Googler, and yes I'm tired of hearing this horseshit. Every single U.S. company complies with warrants, court orders, NSLs, and FISA demands. Every. Single. One. If you don't like that, work to change the bloody laws.
You seem uncomfortable with the consequences of that. Maybe you should re-evaluate your own relationship with Google - do you really want to be party to these shenanigans?
Google is one of the industry leaders in being transparent and open about government requests for data (http://www.google.com/transparencyreport/) and in fighting the government on improper or overly-broad data requests, or those that don't exactly follow the legal procedures. I'm perfectly happy with my relationship with them. I'm quite unhappy with the U.S. legal environment that allows things like secret FISA orders, but that's hardly Google's fault.
Improved location data on wifi is one way.
But to get to your core point: unless you have an amazing memory (unlikely) or reuse passwords (not unlikely, but, to borrow a term, "idiotic") you have to be storing those passwords somewhere. Password escrow certainly counts as "backup" by any normal definition of the term, although it has some extra requirements.
I didn't even know this happened until a friend bought a new device and it suddenly knew everything. Didn't bother him, did bother me.
If we are just talking about encrypting for backup, then that is not correct. The device would only need to ask for the password before the first backup that includes a wifi password, on the first backup after any wifi password change, and before a restore. Wifi password storage on the device itself can continue to use whatever mechanism it currently uses.
This can actually be cut down to just needing to ask before the first backup and before a restore. Generate a public/private key pair. Ask for the GA password and verify it, and use that to deterministically derive a key to encrypt the private key. Store the public and private keys in the cloud. Cloud data can then be encrypted with the public key before being sent to the cloud.
They only need to ask for the GA password again when they need the private key, such as for restoring the data.
1) Your plaintext password is used to generate two derivative tokens. One for user authentication with Google, and one for encrypting data stored with Google. The authentication password token is PBKDF2(N, password) and the encryption token is PBKDF2(N-1, password). You give Google the authentication token on signup. They are not capable of deriving the encryption token from it, but the user is capable of generating both from the original password.
2) For backup initialization, you prompt the user for their password, calculate the encryption token, generate an ECC keypair, encrypt the private ECC key with the encryption token, and send the encrypted private key to the backup server. This is the last time you'll need to prompt the user for their password until a restore.
3) Each time you wish to send updates to the backup server, you generate a symmetric encryption key, encrypt that using the user's public key, encrypt the data to backup with the symmetric key, and send the encrypted symmetric key and data together to the backup server. This does not require prompting the user for their password, or storing it locally.
4) On restore, you prompt the user for their password, use it to decrypt the private key that you pull down from the backup server, which you can then use to decrypt any encrypted blocks you retrieve as well.
Chances of me implementing a boolean on/off switch for the plaintext passwords correctly: 99%
How is it usually done?
That is strictly true, but isn't it significantly more difficult for an infiltrator to (a) obtain Google's private code-signing key and push a compromised client build to devices; than (b) hack into a Google database and read the 'users' table...?
But to a layperson, the lack of a secure private channel to personal data storage remains an infeasibility. So laypeople embrace third-party "cloud" storage offerings, this one included. These services offer omnipresence of data. They don't offer personal control, but many people are willing to concede control because omnipresence is such a convenience.
Putting all of that aside, however, and accepting the world as it is, with VPNs the tragedy of user experience that they are... An open question remains: why not ask the user to create a passphrase for use in encrypting the device's data before storing it at the GoogleCloud + NSACloud?
The seemingly obvious answer to the rhetorical question is a worry about user experience pain ("woe is me, I need to remember another passphrase now"). So perhaps the user would be instructed to provide a passphrase if and only if they are concerned about their backup being stored on the NSACloud. If they are not concerned, they can leave the field empty.
The developer reported a bug found on Android to the Android forum. The reply he gets sounds like a dismissal, which is quite strange given that the problem is not only related to Android but also with a Google product.
A few days ago I submitted an Android bug verified on a Samsung phone. The reply was something in the line of "that's Samsung's problem, talk to them".
I'd say this isn't the right way for Google to handle a severe issue such as this, i.e. simply rejecting accountability. It's like having a team say "go talk to some other team" when they're actually all aboard the same ship. Is big company bureaucracy / turf wars getting to Google? Hope not...
I recently found the same irksome behaviour by Goog on another important issue: https://code.google.com/p/android/issues/detail?id=56803
The Location Services API is not part of AOSP (or at least, this implementation isn't) IIRC
You should rephrase the bug report to make clear you are talking about the google play services location API.
As for the complaint on that bug report that google should file and track these issues for folks, AOSP is an open source project, and like most open source projects, prefers folks file upstream/downstream issues directly.
The thing about AOSP is exactly what JBQ said: It's meant for reports about open source parts of Android, not reports about Samsung's skin on top of it, etc.
Most of the bugs submitted are not AOSP bugs (I know it's hard to believe, but i've done triage on it). They are bugs in some vendor's patches or changes to AOSP, which, for the most part, Google can do nothing about.
It would be worse if these bugs were left open, giving people the false hope that Google can solve their problem, or that the bug got to the right place.
If this bug/feature is somewhere in the AOSP code, great, reopen the bug and point it out.
I understand what you say, but if it was the other way around my reply would have been something in the lines of "1) please confirm it by testing on another phone brand; 2) if it's specific to Samsung, here's the link to file the bug"
It's an important problem, and the feeling I get from that thread is that they are more concerned where the bug should be filled. I appreciate organization as much as anyone, but the proper response should be frantic running around and hair pulling.
(for others like myself who had not heard of this)
If you're interested in robust, secure storage of your data, the candy-flavored OS built-in-cloud-tool may not be your best bet. It's only there to check a feature box on a sales card.
"Oooh but I get 5 gigs for free!"
You can disable backups when you setup your phone.
My wife recently picked up an S4 and none of her things synchronized. I was pretty surprised at the time but thinking about it later I realized the AT&T clerk skipped the initial sign-in process. It looks like the option to sync old apps/passwords is only available upon launching a fresh device (which being a Nexus user no clerk ever bypasses setup on my devices).
Anyway, this might be why your phone isn't syncing? I'd be interested in seeing some option to force sync Android devices with backed up data at any time.
Android: slurping phone numbers, texting behind the scenes on your behalf, etc...
iOS: no access to apps that Apple doesn't approve, no replacement of built-in apps with third-party apps, etc...
These systems were not built exactly with your benefit in mind. Android was built to prevent Apple domination of mobile and thus continue selling ads by providing services. Apple has several services that would be much more useful cross platform but are not: Facetime, iMessage, etc... and that reinforce platform lock-in.
Debatable. If you install something like Permissions Explorer you can see which apps access your contacts and/or texts. It's generally a small list. And the Google sync features can be disabled.
At least for networks that are already designed to be public (e.g., coffeeshop wifi) this would be awesome. For my home network I'd have to first setup a second SSID myself that I firewall from the rest so that I don't expose all my wifi devices to any passer by. That bit isn't very user friendly.
One option would be to use separate password for protecting the data, but that would not be very convenient for the user. Very easy to forget such password since you are not going to need it very often.
If you don't write checks to Google for a service, you are not among Google's customers.
Even google's official adb page has no mention of it, but I've done it and it works fine: http://tutznet.com/1283-perform-full-backup-android-phone-ad... (not my blog -- just the least spammy site i could find)
"Encrypt synced passwords with your Google credentials" is impossible in times of app specific passwords, right?
Let [this](http://cl.ly/image/1X0o212T3B0Y) be your reminder to do so.
Every few months someone rediscovers that Google also syncs Wifi credentials between devices (perhaps when logging into a new device and finding it tethers itself nicely to the network on its own).
It's a matter of convenience, Wifi passwords are only applicable at a certain range, and other restrictions could be applied even then (like hardware whitelisting etc) it's not your bank credentials.
Here's a reddit discussion (from 2 years ago!) http://www.reddit.com/r/Android/comments/g6ctt/just_upgraded...
I wouldn't recommend that in any circumstance, it's completely false security really.
MAC filtering is incredibly easy to bypass, all Malory has to do is wait for another device to connect and clone their hardware's address.
It's false security because (especially for wifi) MAC filtering is like a verbal password that's been written down on a billboard. Everyone can read it so its not a secret.
If it can be exploited, it should be protected as much as it can be.
We all saw what happened with Google's StreetView cars capturing the local Wi-Fi traffic. The same thing could be used by somebody hacking into Google's servers, downloading the Wi-Fi passwords and any possible maps data if possible and workaround getting into people's Wi-Fi networks. If it is not likely but it is not impossible.
From a governmental law enforcement perspective, that's an incredibly valuable trove of data. Instant network backdoors, likely with no physical entry required.
Even if you're not using the data to sniff networks, you can use it to build detailed relationship graphs between people and places.
Or if you're law enforcement, the knowledge of the existence of the resource is enough.
I keep wifi passphrases in a location that is just as secure as the ethernet network to which the wifi is tied: on a piece of tape on the bottom of the WAP. Looking at this again, in the unlikely event I forget the passphrase, seems not to be a burden.