I knew that iCloud backups were not encrypted with a key only known to the user, but this article reminded me that I wanted to disable iCloud backups and use local encrypted backups to my Mac. As a bonus, I can cancel my 50GB iCloud subscription.
I’ve had phones with more storage than my MacBook had, so backing up devices to MacOS locally is a nightmare for the average person unless they also have networked or external storage available.
I’m really disappointed here because I thought this was done a long time ago. I figured there was a key that was only available once you authenticated with your AppleID, but no – they just went silent on the project.
I was looking for information about Android’s approach, and found the following on Google’s support:
If your backups are uploaded to Google, they’re encrypted using your Google Account password. For some data, your phone’s screen lock PIN, pattern, or password is also used for encryption.
If you back up to Google Drive, here’s what’s backed up:
Contacts
Google Calendar events and settings
SMS text messages (not MMS)
Wi-Fi networks and passwords
Wallpapers
Gmail settings
Apps
Display settings (brightness and sleep)
Language and input settings
Date and time
Settings and data for apps not made by Google (varies by app)
Photos are another story, I guess.
As for contacts, they may be encrypted for backups, but they’re all fully available from other Google services like GMail, right? 🤔
If your backups are uploaded to Google, they’re encrypted using your Google Account password. For some data, your phone’s screen lock PIN, pattern, or password is also used for encryption.
OK, so, let’s be real here:
If the data is encrypted with your Google Account password, then either they’re storing your password in cleartext on the device and/or in the cloud, both of which options would be a rather bad idea given that you’re supposed to only use the password to get the authentication session token, or that you have to enter it all the time, which would be a rather poor UX. (I presume they must be storing it on the device, encrypting it with the lock PIN/pattern?)
Even if they themselves don’t have a password, I don’t see how they could possibly resist a request from a secret court to save such password the next time it is supplied by the user; this doesn’t compare favourably to what Apple was supposed to have been working on.
As for lock PIN or pattern, what sort of encryption are they using? These are usually just a few digits long, there aren’t that many combinations to try out all the inputs if you already have all the data for it locally.
If the data is encrypted with your Google Account password, then either they’re storing your password in cleartext on the device and/or in the cloud
Is this necessarily true? I feel like there could be some ways to “effectively” do this, without storing your password in cleartext. Here’s an example:
If you are asked for your pw when you encrypt, Google can sha512 your password and use that to decrypt in the same kind of way.
Of course, I don’t know that Google is making that ask at each encryption / decryption. Also, that would mean you would lose your data if you forgot your password, which is probably not the case. However, I just want to point out there could be some clever use of cryptography going on here.
Well, your reply started with “let’s be real” but you’re only presuming on what Google’s doing. I’m not sure they are as bad at encryption as you credit them for, but I can’t prove that either.
At any rate, Google is working with US gov law enforcement, to the extent that US-based companies are obliged to. That’s not great, but that’s expected.
I knew that iCloud backups were not encrypted with a key only known to the user, but this article reminded me that I wanted to disable iCloud backups and use local encrypted backups to my Mac. As a bonus, I can cancel my 50GB iCloud subscription.
I’ve had phones with more storage than my MacBook had, so backing up devices to MacOS locally is a nightmare for the average person unless they also have networked or external storage available.
I’m really disappointed here because I thought this was done a long time ago. I figured there was a key that was only available once you authenticated with your AppleID, but no – they just went silent on the project.
Pretty good article.
I went in thinking Apple was being hypocritical and now think that perhaps their move was pretty smart. Can’t push too much at once.
Also pretty surprised at Alphabet’s different approach also pretty smart.
I was looking for information about Android’s approach, and found the following on Google’s support:
Photos are another story, I guess.
As for contacts, they may be encrypted for backups, but they’re all fully available from other Google services like GMail, right? 🤔
https://support.google.com/android/answer/2819582?hl=en
OK, so, let’s be real here:
If the data is encrypted with your Google Account password, then either they’re storing your password in cleartext on the device and/or in the cloud, both of which options would be a rather bad idea given that you’re supposed to only use the password to get the authentication session token, or that you have to enter it all the time, which would be a rather poor UX. (I presume they must be storing it on the device, encrypting it with the lock PIN/pattern?)
Even if they themselves don’t have a password, I don’t see how they could possibly resist a request from a secret court to save such password the next time it is supplied by the user; this doesn’t compare favourably to what Apple was supposed to have been working on.
As for lock PIN or pattern, what sort of encryption are they using? These are usually just a few digits long, there aren’t that many combinations to try out all the inputs if you already have all the data for it locally.
Is this necessarily true? I feel like there could be some ways to “effectively” do this, without storing your password in cleartext. Here’s an example: If you are asked for your pw when you encrypt, Google can sha512 your password and use that to decrypt in the same kind of way.
Of course, I don’t know that Google is making that ask at each encryption / decryption. Also, that would mean you would lose your data if you forgot your password, which is probably not the case. However, I just want to point out there could be some clever use of cryptography going on here.
Well, your reply started with “let’s be real” but you’re only presuming on what Google’s doing. I’m not sure they are as bad at encryption as you credit them for, but I can’t prove that either.
At any rate, Google is working with US gov law enforcement, to the extent that US-based companies are obliged to. That’s not great, but that’s expected.
how it works: https://security.googleblog.com/2018/10/google-and-android-have-your-back-by.html
I don’t know what Google does, but we know what Firefox Sync does, and it doesn’t require them to store your password in plaintext or to enter it all the time. They run your password through a key derivation algorithm, with different parameters so that the server-side hash and the encryption key wind up different in spite of starting with the same password.
The two derived keys are what the client retains a plain text copy of.