[enginous]

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.

[moxie]

One way to do it would be:

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.

[jlgreco]

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?

[Afforess]

Chances of me implementing this correctly: 0%.

Chances of me implementing a boolean on/off switch for the plaintext passwords correctly: 99%

[anigbrowl]

How are you going to check in with the backup server if you don't have a working wi-fi connection?

[brudgers]

Horseshit.

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.

[jsnell]

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?

[untog]

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.

[chrisrhoden]

Yeah, I mean, this simply isn't true.

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.

[leoedin]

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.

[antimagic]

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.

[Symmetry]

I'd imagine people getting new phones is the common use case.

[jimmaswell]

>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.

Improved location data on wifi is one way.

[shameless_1]

> 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.

[nodata]

I appreciate not re-entering ten cryptic wifi passphrases when I replace a phone.

[swamp40]

> Google's scheme allows them to harvest the passwords to a vast number of wireless networks.

I wasn't too worried until I read this from you.

[enneff]

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.

[tzs]

> 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.

[jordanthoms]

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.

[Camillo]

Not backing up wifi passwords would be a better tradeoff, especially as the default.

[eli]

I seem to recall that not backing up anything is the default. Am I wrong?

[threeseed]

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.

[enginous]

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.

[shawnz]

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.

[valisystem]

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.

[eslaught]

Correct, and not only is it never in the clear over the network, the key is stored such that Mozilla cannot decrypt your content.

https://support.mozilla.org/en-US/kb/firefox-sync-data-secur...

[drzaiusapelord]

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.

[snom380]

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.

[gcb0]

Why do you even have to backup a password? It's idiotic from every way you look at it

[ajross]

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.

[Nursie]

Perhaps it's a trade-off that shouldn't be on by default.

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.

[claudius]

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.

[MarkMc]

> 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...?