5 ms·
when i read the title, i though "really?! how?" then i read the article and realized any time i have restored my android phone, then entered my Google account,
by tiernano 13y ago
when i read the title, i though "really?! how?" then i read the article and realized any time i have restored my android phone, then entered my Google account, it automagically connects to all access points i usually use (home, work, other office, etc)...
- rcthompson 13y agoBut they didn't have to design it in such a way as to share the passwords with google. All your data could be encrypted with your google account's password (or some other secret derived from it) on the device and backed up encrypted. When you enter your account password on a new device, it then downloads the encrypted data and decrypts and restores it. Same user experience without exposing private data.
- codeka 13y agoDo we know that's not happening? The article says "they can decrypt them, given only a Gmail address and password" which implies that it would be encrypted with your password.
- acqq 13y agoIt's shared with Google as long as Google stores your Google account password as the actual sequence of characters and not as the result of bcrypt processing and as long as the data copied to Google aren't encrypted locally. Local encryption has the effect that as soon as you forget your password, the data stored as the backup are unusable, even you can make Google reset your Google account password. Security is always a trade-off.
- deong 13y ago> Same user experience without exposing private data. Google also knows your Google account password. If you can decrypt the data using any deterministic function of your Google password, then so can Google, so there's no additional security gained. They probably already store your wifi password encrypted -- it's just when the device asks for it, Google decrypts it and sends it back to you. So in all likelihood, they're already doing what you want. They could have done it by asking the user to provide a new unique password that would have to be entered on each new device. That would provide additional security as only the device could decrypt the password. However, (a) because such a password would only be used once or twice a year at most, no one would remember it and the whole feature would be useless, and (b) you still have to trust Google to not send the password after the device decrypts it, and if you trust the OS vendor to not backdoor the OS, you might as well trust them to not backdoor their own servers to access the same data.
- DougWebb 13y agoGoogle also knows your Google account password. If you can decrypt the data using any deterministic function of your Google password, then so can Google, so there's no additional security gained. Probably, but not necessarily. All they need to know is the hash of your password. When you set up a new device, it can call out to Google to authenticate without sending a cleartext password (similar to HTTP's Digest auth). Once you've authenticated and retrieved your encrypted settings, the password can be used locally to decrypt the settings. The password never has to leave the device. If they haven't done it this way (and unless the article's author knows something, I don't think you can tell if they're doing it this way or not from observed behavior) they're either (a) lazy or (b) nefarious. I'm guessing lazy, since that's the reason for most developers who implement poor security... they just don't spend enough time thinking about security of the features they're working on.
- CJefferson 13y agoWith your design, a user with a lost password also loses all their data. While that might be better from a security perspective, I can't remember the last time I used a system that did not keep all my data when I set a new password, without having the old one. Such a thing would annoy many users.