<story><title>Android saves wifi passwords in plaintext to the cloud</title><url>https://code.google.com/p/android/issues/detail?id=57560</url></story><parent_chain><item><author>enginous</author><text>What key are you going to encrypt these passwords with?&lt;p&gt;If you were to encrypt passwords in the cloud with a key that&amp;#x27;s stored on the device, you can&amp;#x27;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.&lt;p&gt;If you were to encrypt them with the user&amp;#x27;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 &amp;quot;situation&amp;quot;).  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.&lt;p&gt;If the GA password were to be used to authenticate in a way where Google doesn&amp;#x27;t get access to the clear text password (through digest-like authentication), a user wouldn&amp;#x27;t be able to access the backups after resetting her password.  However, this method is not reliable if you don&amp;#x27;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.&lt;p&gt;Like all things security, it&amp;#x27;s a trade-off between security and convenience.</text></item></parent_chain><comment><author>moxie</author><text>One way to do it would be:&lt;p&gt;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.&lt;p&gt;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&amp;#x27;ll need to prompt the user for their password until a restore.&lt;p&gt;3) Each time you wish to send updates to the backup server, you generate a symmetric encryption key, encrypt that using the user&amp;#x27;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.&lt;p&gt;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.</text></comment>
<story><title>Android saves wifi passwords in plaintext to the cloud</title><url>https://code.google.com/p/android/issues/detail?id=57560</url></story><parent_chain><item><author>enginous</author><text>What key are you going to encrypt these passwords with?&lt;p&gt;If you were to encrypt passwords in the cloud with a key that&amp;#x27;s stored on the device, you can&amp;#x27;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.&lt;p&gt;If you were to encrypt them with the user&amp;#x27;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 &amp;quot;situation&amp;quot;).  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.&lt;p&gt;If the GA password were to be used to authenticate in a way where Google doesn&amp;#x27;t get access to the clear text password (through digest-like authentication), a user wouldn&amp;#x27;t be able to access the backups after resetting her password.  However, this method is not reliable if you don&amp;#x27;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.&lt;p&gt;Like all things security, it&amp;#x27;s a trade-off between security and convenience.</text></item></parent_chain><comment><author>brudgers</author><text>Horseshit.&lt;p&gt;Setting up a password for an Android device only needs to be done once for each device-&amp;gt;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.&lt;p&gt;Google&amp;#x27;s scheme allows them to harvest the passwords to a vast number of wireless networks.&lt;p&gt;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.&lt;p&gt;The very best possible light for this nexus is that it only appears to be a very very bad thing.</text></comment>