Hacker News new | ask | show | jobs
by moxie 4723 days 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.

3 comments

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?
This is not the normal Google Account password, this is specifically for a backup/restore process.
People have enough trouble remembering one password. Add another that is used only in very unusual circumstances and nearly no one will remember it.
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.
Chances of me implementing this correctly: 0%.

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

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.
It shouldn't be insurmountably difficult and it's easily abstractable to more or less backup(uid,pass,data) restore (uid,pass,data).
How are you going to check in with the backup server if you don't have a working wi-fi connection?
Using a 3G connection, perhaps? In any case such a problem doesn't excuse Google from storing plaintext rather than encrypted passwords on the server.
Android is used on more than just smartphones. There are many tablets that don't have cell radios in them.
Flash the device with the password (this time encrypted) before shipping it to the user?

How is it usually done?