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.
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.
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.
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.
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.
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.
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...
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.
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?
[+] [-] enginous|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] brudgers|12 years ago|reply
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.
[+] [-] enneff|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] Camillo|12 years ago|reply
[+] [-] threeseed|12 years ago|reply
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.
[+] [-] valisystem|12 years ago|reply
[+] [-] drzaiusapelord|12 years ago|reply
[+] [-] gcb0|12 years ago|reply
[+] [-] Nursie|12 years ago|reply
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|12 years ago|reply
[+] [-] MarkMc|12 years ago|reply
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...?
[+] [-] bhauer|12 years ago|reply
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.
[+] [-] js2|12 years ago|reply
[+] [-] jmngomes|12 years ago|reply
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...
[+] [-] spdy|12 years ago|reply
[+] [-] sil3ntmac|12 years ago|reply
(for others like myself who had not heard of this)
[+] [-] rsync|12 years ago|reply
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!"
[+] [-] DanBC|12 years ago|reply
[+] [-] nodata|12 years ago|reply
You can disable backups when you setup your phone.
[+] [-] TallGuyShort|12 years ago|reply
[+] [-] foley|12 years ago|reply
[+] [-] myko|12 years ago|reply
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.
[+] [-] jsnell|12 years ago|reply
[+] [-] babesh|12 years ago|reply
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.
[+] [-] nly|12 years ago|reply
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.
[+] [-] pedrocr|12 years ago|reply
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.
[+] [-] jpalomaki|12 years ago|reply
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.
[+] [-] keithnoizu|12 years ago|reply
[+] [-] brudgers|12 years ago|reply
If you don't write checks to Google for a service, you are not among Google's customers.
[+] [-] durkie|12 years ago|reply
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)
[+] [-] somesay|12 years ago|reply
"Encrypt synced passwords with your Google credentials" is impossible in times of app specific passwords, right?
[+] [-] Tomdarkness|12 years ago|reply
[+] [-] ksowocki|12 years ago|reply
Let [this](http://cl.ly/image/1X0o212T3B0Y) be your reminder to do so.
[+] [-] krapp|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] tazjin|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]