10 ms·

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

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.

enneff 13y ago
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.
threeseed 13y ago
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.
- shawnz 13y ago
  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.
- enginous 13y ago
  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.
valisystem 13y ago
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 13y ago
  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-secure-find-out-more https://support.mozilla.org/en-US/kb/firefox-sync-data-secur...
Camillo 13y ago
Not backing up wifi passwords would be a better tradeoff, especially as the default.
- eli 13y ago
  I seem to recall that not backing up anything is the default. Am I wrong?
  - damian2000 13y ago
    I believe cyanogenmod has backup turned off. But I had used previous (earlier version) of Android and it was turned on.
    - eli 13y ago
      I only use the Android that comes with my phone and I recall having to check the box myself on my T-Mobile Galaxy S3.
  - mtgx 13y ago
    Most such Android settings are on by default, including all the location tracking ones.
brudgers 13y ago
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.
- shameless_1 13y ago
  > 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.
  - throwaway2048 13y ago
    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.
    - shameless_1 13y ago
      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.
  - amalter 13y ago
    >> 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.
drzaiusapelord 13y ago
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 13y ago
  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.
claudius 13y ago
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.
gcb0 13y ago
Why do you even have to backup a password? It's idiotic from every way you look at it
- ajross 13y ago
  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.
  - sixbrx 13y ago
    Or use a password manager, which does proper encryption.
Nursie 13y ago
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.
tzs 13y ago
> 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 13y ago
  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.
  - snom380 13y ago
    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.
moxie 13y ago
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 13y ago
  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?
  - sneak 13y ago
    This is not the normal Google Account password, this is specifically for a backup/restore process.
    - cbr 13y ago
      People have enough trouble remembering one password. Add another that is used only in very unusual circumstances and nearly no one will remember it.
MarkMc 13y ago
> 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...?

enneff 13y ago

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.

threeseed 13y ago

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.

shawnz 13y ago
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.
enginous 13y ago
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.

valisystem 13y ago

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 13y ago
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-secure-find-out-more https://support.mozilla.org/en-US/kb/firefox-sync-data-secur...

Camillo 13y ago

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

eli 13y ago
I seem to recall that not backing up anything is the default. Am I wrong?
- damian2000 13y ago
  I believe cyanogenmod has backup turned off. But I had used previous (earlier version) of Android and it was turned on.
  - eli 13y ago
    I only use the Android that comes with my phone and I recall having to check the box myself on my T-Mobile Galaxy S3.
- mtgx 13y ago
  Most such Android settings are on by default, including all the location tracking ones.

brudgers 13y ago

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.

shameless_1 13y ago
> 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.
- throwaway2048 13y ago
  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.
  - shameless_1 13y ago
    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.
- amalter 13y ago
  >> 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.

drzaiusapelord 13y ago

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 13y ago
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.

claudius 13y ago

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.

gcb0 13y ago

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

ajross 13y ago
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.
- sixbrx 13y ago
  Or use a password manager, which does proper encryption.

Nursie 13y ago

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.

tzs 13y ago

> 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 13y ago
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.
- snom380 13y ago
  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.

moxie 13y ago

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 13y ago
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?
- sneak 13y ago
  This is not the normal Google Account password, this is specifically for a backup/restore process.
  - cbr 13y ago
    People have enough trouble remembering one password. Add another that is used only in very unusual circumstances and nearly no one will remember it.

MarkMc 13y ago

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