What key are you going to encrypt these passwords with?
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.
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.
How do you handle password changes? Download the encrypted ECC private key, decrypt it with the old password, re-encrypt it with the new one, then upload it again? Is there an easier way?
I wonder what percentage of people use the email reset for every access attempt. I have several services where I went from crappy passwords to good ones I don't know - I just reset them each time.
Difficulty of implementation isn't the issue here. This is an important feature of Android and if moxie's approach would make things better for users I think Google could get it right.
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.
If you're going to dismiss an argument as "horseshit", you should perhaps offer a compelling alternative. Because your idea of what is going on is frankly ridiculous.
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?
Encrypt the data on the device. Backup encrypted version in the cloud. Download encrypted backup to new device. Unencrypt on new device. Merge versions on the device.
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.
You're providing innuendo and "exercises for the reader", not an argument. That's pretty weak.
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.
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?
Do you think Larry Page can be bought?
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.
My opinion about Larry Page's price is that it depends upon who is buying and what they are offering. An offer similar to one from the Kremlin which is easy to refuse might be one he cannot refuse from Fort Meade.
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.
> Setting up a password for an Android device only needs to be done once for each device->network pairing.
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.
>> So you want _yet another_ password between the user and his magical experience or whatever ?
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?
You missed the central part of my argument, so I'll reiterate it here: users don't care about this stuff, and passwords are user-hostile. Google chose to implement this a certain way that works for 99.99% of people.
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").
Ah, you're quite right, thanks for making me look this up.
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).
You could in theory salt the primary account password with a new salt, derive a key from it and use that to encrypt the password list (sending the salt alongside it). This of course implies that the plaintext password never hits Google's servers, which it probably does.
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.
Well I don't agree that there's far more valuable data than the ability to access my internal network. If my wifi network wasn't segregated from my wired network, by getting my wifi password you have bypassed my firewall, giving you access to my/my company's servers.
If someone has the resources to obtain your Wi-Fi password from Google and is determined enough to get within range of your network, you're being targeted by a very dedicated adversary. Things like physical security, TEMPEST and listening devices become valid concerns. This is a highly unlikely adversary for the majority of internet users.
Note that non-targeted attacks (the type that leak password lists) are not a serious threat here.
That's not necessarily true. I imagine the data would most likely be targeted by a third party that's disinterested in you, but very interested in your adversary's money. I wonder what the going rate rate for all the WiFi passwords on my block would be. Or neighborhood. Or zip code.
Decrypt encrypted backup on the new device how? What password / key would you use, and how would that be backed up / made known to the user, which it does not do now?
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.
Most people really have 10 different WiFi networks? I have two. Home and work. Who has 10?
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.
>Most people really have 10 different WiFi networks? I have two. Home and work. Who has 10?
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.
If you're in the habit of connecting wifi at cafes/bars etc. you can easily run past 10 (wow - just checked the list on my 18 month old laptop, it's currently 110 networks).
Crucially (at least on my device,) there's no granularity to this opt in - I cannot choose to backup my application data but not my WiFi passwords. Now my options are to either accept Google's storage of my network passwords or set up and maintain my own backup system.
That assumes your application data is less important than your WiFi passwords. I don't think a distinction at that level is useful. To be useful, it would have to be per application. I don't care if some game status is synced, but I surely care if my email credentials are (although caring may just means I'm aware, it doesn't necessarily mean I would change it).
I agree that trusting google with wifi passwords is about as benign as it gets (especially if you already trust them with everything else) but the reason we encourage password encryption isn't because we don't trust the service provider, it's because we don't trust hackers or unethical employees. There are a lot of people who would love to get their hands on that data.
Not benign at all. Read the story about how some Facebook administrator challenged Facebookers to hack into Facebook. The way they did it was to drive by his home and impersonate his home wireless router. My understanding is that once you do that, you can do man in the middle attacks.
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.
Fair enough; it's not really benign, only in comparison to all the other data google stores and aggregates regarding its customers (imagine a map of Google Now data)
> Because your idea of what is going on is frankly ridiculous.
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).
Do you have any idea what you're talking about?
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.
I'm not sure what you're talking about. Google collects information on wireless networks for a very specific purpose - determining location to speed up or replace GPS. Skyhook Wireless is another company that sells the information obtained from wardriving.
I was referring to the StreetView Skyhook-like program that did exist, and yes, it was shut down after it was discovered to be collecting more than just SSIDs:
Wardriving actually specifically refers to "the act of searching for Wi-Fi wireless networks by a person in a moving vehicle, using a portable computer, smartphone or personal digital assistant" per Wikipedia.
It looks like that blog post only states that they deleted the erroneously collected network data.
So the NSA knows that Google has access to this information. I bet they have ALREADY forced Google to give this information up even if only on a warrant basis (but perhaps not).
an act which can be in no way cast as user convenience.
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.
Yes. I just upgraded from one Android phone to another. Was resigned to the tedious nightmare of setting up multiple WiFi connections again. This feature is fantastic. Not that that negates privacy issues but it is a massive user convenience.
The hotspots I use "regularly" aren't actually the issue- I could certainly remember the passwords for them easily. But over time I've built up a huge network of hotspots that I wouldn't like to lose- that coffee shop I went to a few months ago? That hotel I stayed in last year? It's quite nice to have that just connect automatically.
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".
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?
The first time I traveled to my sister's house for Thanksgiving setting up the WiFi on our devices was a several hour ordeal that stressed out the whole family. They aren't used to keeping track of these things. I'm very glad I have never had to do that again through several device upgrades.
Do some windows versions still demand that your password fits a set format - length as character type as I recall? Trying to get a (?XP ?Vista) PC onto our until-then Mac only network just about caused its owner a stroke.
honestly, nope. I never had reception issues at a friend's place, but for coffee shops and hotels, even if reception is bad, i rather use 2G than go login in random networks.
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.
That's perhaps a 3rd standard deviation case for backing up WiFi passwords, but not plausibly for harvesting data on all Wifi networks including those in private dwellings.
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.
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.
You give large corporations way too much credit. There's no evidence beyond your conspiracy theories that this is a feature designed for anything other than convenience (one which I and many others in the thread have found to be quite convenient).
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.
>You give large corporations way too much credit. There's no evidence beyond your conspiracy theories that this is a feature designed for anything other than convenience
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"
>fact that Google was previously caught/accused of war-driving every wifi net they could see with their streetview cars
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.
Google gathered wifi data to improve their location services. The capturing of unencrypted payload data was an unintended consequence of that due to poor software design. The initial wifi data collection was intentional and was designed to improve their location product (which it did - the Google Maps location service can be very speedy if it's near a wifi access point that google cars picked up - another feature likely to encourage people to use their product). The additional capture of packet data was unintentional. Numerous third parties have been involved in auditing google in their actions after it all came out and there's been no hint that they ever intended to do anything with the packet data they collected.
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!
This, in addition to Google's demonstrated willingness to hand user data over to the US government means that the government (or a rogue Google employee, or a hacker that gets access to Google's database, or a rogue member of the US government, or ... you get the picture) can hit you with a LAN-based MotM attack pretty much whenever they wish. That means they can own your computer, because your Android phone connected to the same Wifi router. Uh, no thanks.
I realize you're just being a troll, but what you really mean by "Google's demonstrated willingness to hand user data" is "[...] comply with U.S. law and valid court orders while doing everything they can to push back on overly-broad fishing expeditions by the government."
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.
Are you suggesting that Google doesn't hand over data? Google has decided to do that because it's good for business (in the sense that going up against the US government is bad for business, and realistically would require Google to move overseas). That's fine, but it changes nothing of the fact that they will hand over data requested by the US government, which means that my comment was perfectly valid.
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?
Did you even read what I wrote? Yes, Google will hand over user data in response to a legal demand from the U.S. government (warrant, court order, NSL, etc.). So will every other company in the US, whether it's Yahoo, Rackspace, Amazon, or Joe's Linux Servers, Inc. It's called "obeying the law". Characterizing this as "Google's demonstrated willingness to hand user data over to the US government" is dishonest.
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.
Here's the thing - I don't give a rat's arse why Google hands over my data to the US government. All I care about is that they do. They apparently find it easier to hand over my data than to shut down operations or move overseas so that they don't have to. OK, they are free to make that decision (as I have already stated), but they are still bloody well handing over my data! And you, as a googler, are party to that. You really should have a long think about that.
If I buy a new Android phone, odds are it is not one which makes me a Google customer - i.e. Google gets none of the proceeds should I purchase a Samsung Galaxy.
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.
> The only means by which Google profits is by
monetizing data leaking from my device.
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.
>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.
>> Google has harvested the location, name and signal strength of many millions of wireless networks across the world
> 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.
to make this a bit clearer, android, apple, etc devices send back wifi BSSID+GPS coordinates to the mothership for AGPS purposes. Im really suprised there hasn't been more concern about this.
As an engineering project this is truly a resourceful and rather elegant solution to tune a Kahlman filter for positioning. But on the level of privacy ... big consequences. The BSSID allows tracking when someone moves to a different place. And since that's tied to GPS with multiple captures over time you get a pretty accurate location for the WiFi device.
Yep, we all know google needs extra bandwidth and/or has the capability or need to illegally snoop on your over the air http traffic at enormous legal risk.
For Chrome Sync data, you can specify a pass phrase that is not your Google Account password, nor is it tied to a specific device. It would be nice if you could specify a pass phrase to use when sending Android backup data.
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.
> 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")
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.
Thing is, this is actually not a one-time backup but an ongoing sync. And it's super convenient - I only have to enter the password on one of my devices and then all the others can connect.
Even with ongoing sync there could be an option to store the password on the device, either permanently or to enter it at boot time. Just like with SSH keys.
Why couldn't Google just have a shared key stored on each of the user's devices ?
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.
Encrypting anything with your Google Accounts password doesn't really make you invulnerable against Google. They can get your clear text Google Accounts password from you any time they want by just reading the password you enter on any of their clients.
Here's the problem with encrypting via the account password, directly or indirectly:
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.
Firefox does it by asking you to enter a code displayed on a device that already has the key. My guess is that the displayed key is used to decrypt the actual key on the device, and that the key is never seen in clear on the network.
What common use case is backing up wifi passwords or any passwords, for that matter? Yeah, there are difficulties here, but I don't want or need you to backup my wifi password. Its none of your business.
I've probably saved hours of phone support because my parents wifi passwords and email setups is saved in their iPhone backup (this is only done if the backups are password protected). When they get a new device it's just a matter of plugging it in, choose restore, and that's it. They do have to enter some payment info again for each new device on the App Store though.
Sorry, that doesn't make any sense. The specific use case here is unboxing a new phone, logging in, and having access to all of your standard networks without having to look up your wifi passwords. Clearly that has value to anyone who has ever used a new phone.
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.
Let the user create a private/public key on the device and allow them to store the file somewhere safe with only the public key remaining on the device. It can then easily do the backup (and even store the public key on Google’s servers, if required) whenever required, and if the user gets a new phone, he’ll be prompted to feed his private key into it again to decrypt the backup. This can be done over the network, from an SD card/usb key or maybe even with a QR code.
> 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
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...?
Yet another place where I feel a tinge of anger that VPNs utterly failed to deliver on the potential of private secure connectivity to personal data storage from anywhere. Several of us here at HN set up and manage home networks to which we connect over an encrypted channel. To us--well, to me at least--it seems plain as day that my device should allow me to backup its sensitive data to a file that I store on a file system of my choosing. I would store it on my encrypted disk array at home (which is then backed up to a data center disk array).
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.
Yes, but as far as backups and backup security is concerned -- a time capsule is fairly proprietary, and a Mac on your home network is susceptible to local catastrophe.
This reply "This report applies to a mobile Google application or service, and the issue tracker where you reported it specializes in issues within the Open Source source code of the Android platform." is a bit off, IMO.
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...
From what I can tell, JBQ is right and the maps folks are not understanding the issue you have. :)
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 submitted a bug stating that the OS' facilities for managing audio (i.e. AudioManager et al) weren't working according to the spec/docs, some classes would report an incorrect volume during a call. I only tested it on a Samsung phone, I didn't bother testing with other brands because breaking on Samsung would be bad enough for my/any Android app.
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"
1. Sure, but it's entirely that brand's drivers would also not have been in AOSP.
2. You must realize there are hundreds of devices, and manufacturers change their support links all the time :(
I too found the replies to be somewhat dismissive. You would think this sort of report would be dealt with much more urgency or, in the very least, some concern.
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.
Just to add to everyone's knowledge: this Street View wifi snooping was a) three years ago, b) accidental, and c) only known by the public because Google voluntarily revealed that it had been doing it (and immediately deleted all of the collected data).
The title is, I think, a bit misleading. That's because it is not Android per se that is sending your wifi passwords to the cloud, it's the use of the "backup my data" tool.
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.
And all for nothing - none of my Android devices have ever restored my wifi passwords, it is always a mission to find and input my password on a fresh phone.
I've always had great experiences upgrading Android devices. Once I log in for the first time they sync wifi and applications pretty seamlessly.
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.
No need to belabor the point given the many examples beyond this one. If you want security, you're not going with Android. If you want configurability, you're not going with iOS.
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.
> Android: slurping phone numbers, texting behind the scenes on your behalf, etc...
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.
Google could use this to bootstrap a FON like worldwide network. Have an additional option in the settings for "Make this network part of Google Free Wifi" and then any android phone anywhere can connect seamlessly to the network. If you change the security settings they are immediately updated because you also update them on your own phone.
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.
I guess it would be fairly difficult to make this truly secure without making it too difficult to use. Simply encrypting the data with your Google account password does not do much good, since you are going to provide that password to Google and they could obviously use that to decrypt the data (should the government request it).
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.
I know it doesn't really address the issue at hand, but as an alternative here Android features a little-documented local backup feature that can be done through adb, and can be encrypted.
How Chrome for Android handles this, which supports encrypted sync, is that after logging in it will prompt you for your real password so that it can decrypt the sync data.
Sounds handy, but at some point breaks the concept of not saving the main password on any platform. Still not that bad, since app specific passwords only are in use if you also have 2-factor-login.
At this point I feel you might as well assume that every device and every website stores your credentials in plaintext until explicitly proven otherwise, I guess. Or maybe unsalted md5 if they're a bank.
I would like to know how this works with 802.1X credentials. Does this "feature" save my company internal LDAP password that I use to authenticate to the network to the cloud? Unencrypted?
You can turn it off if you like:
Settings > Privacy > Backup my data, backup application data, Wi-fi passwords, and other settings to Google servers.
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.
Hmm. That path doesn't seem to work on my Nexus 4 running Android 4.2.2. The closest I could find is Settings > Backup & reset > Backup my data (Backup app data, Wi-Fi passwords, and other settings to Google services). Tapping this, it says "Stop backing up your Wi-Fi passwords, bookmarks, other settings, and app data, plus erase all copies on Google servers?". So, it sounds like it's all or nothing.
Phew! It appears that my instincts were correct when I first turned on this device.
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.
Thanks, that path you posted applies to my phone too. It looks like the Backup setting was already off for me. It might be one of those settings that you are prompted about while setting up the phone.
Convenience isn't an excuse to not encrypt security data, it does not matter if it is a limited to a few areas where it could be exploited. If Google (any companies, including Apple) can not be trusted to protect such information, they should not be offering it in the first place.
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.
It's a stupid way to get into a specific network, but it's a pretty convenient way to get access to everybody's networks. Sure, it would be hard to hack Google, but the prize for doing so would be pretty nice. And if the systems are impregnable, there are always ways in that relies on the human factor. Humans can be bribed and/or threatened.
Or if you're law enforcement, the knowledge of the existence of the resource is enough.
Really? Google has the knowledge of where the network is, who has access to it, and what the password is. Remember also that WiFi networks are a shared resource and often provide access to internal corporate data.
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.
It's also a diagnosis nightmare. The ISPs in my country used to use WEP with MAC filtering with their wifi-routers. The password was mildly complex (16 characters) and on a label on the box. Most users never changed the password. So Joe Blow connects his laptop using the password on the sticker, and it doesn't work. Imagine the same problem for a few million users.
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.
Wait until somebody else connects to have his MAC, then wait until he disconnects. Otherwise, you'll see a ton of RST flying, making your connection quite useless. That's a good enough deterrent for the typical "attacker", who just happens to need a connection here and now and saw a network using WEP.
Yeah but he doesn't have the password, unless somehow he hacked Google's servers for that specific one. It's the combination of both that makes it unlikely, there are far easier/better/more practical/likely ways of penetrating wifi networks.
But where is the problem that google encrypt them?
To restore, i have to use my account and my password.
And why can i not change the option, to backup the application data without WLAN passwords?
For a billion dollar company, this should not be so complicated, or ?
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.