Android's 'Restore Credentials' Feature Will Automatically Log You In To Your Apps On a New Phone (theverge.com) 27
Google is introducing "Restore Credentials," a feature that simplifies transferring app credentials when switching Android devices to keep you logged into your apps. The Verge reports: While some apps already did this, Google is making it easier for developers to include this experience by implementing a "restore key" that automatically transfers to the new phone and logs you back into the app. [...] Restore Credentials requires less work than the previous approach on Android, and can automatically check if a restore key is available and log you back in at the first app launch. A restore key is a public key that uses existing passkey infrastructure to move about your credentials.
Restore keys can also be backed up to the cloud, although developers can opt out. For that reason, transferring directly from device to device will still likely be more thorough than restoring from the cloud, as is the case with Apple devices today. Notably, Google says restore keys do not transfer if you delete an app and reinstall it.
Restore keys can also be backed up to the cloud, although developers can opt out. For that reason, transferring directly from device to device will still likely be more thorough than restoring from the cloud, as is the case with Apple devices today. Notably, Google says restore keys do not transfer if you delete an app and reinstall it.
Is just me who thinks this is a really bad idea? (Score:5, Insightful)
Re: (Score:3)
Am I the only one who thinks it's a really, really bad idea to allow a new cell phone installation to automatically log in to all your applications?
Assuming it's controllable from the source side, you might be. Suppose that this transfer requires proximity of the two devices and only works with the same Google account on both devices. What's the threat vector that you are concerned with, and how is it enabled by this feature?
Re: (Score:2)
Re: (Score:2)
... if the banking app supports this optional feature.
Re: (Score:3)
... if the banking app supports this optional feature.
When. When the banking apps support it. Remember, this pushes more of the responsibility onto the customer.
Re: (Score:2)
If the bank wants to accept the liability that comes with this feature and spend developer time and money by adding this functionality to their app, that's their problem, providing you live in a country with sane banking regulations.
Re:Is just me who thinks this is a really bad idea (Score:4, Informative)
The scenario I'm thinking of is as follows. Imagine that you have a banking application on your cell phone, which normally has a completely separate login and password from your cell phone. If a criminal could then access your cell phone account, they wouldn't be able to access also your bank account. But with this Google scheme, if the criminal gained access to your cell phone account, then he would also be able to gain access to the bank account.
That is not how it works.
They are essentially restoring the application state from one device to the other. If it requires a separate login and password on the old-device, it will still require a separate login and password on the new-device. The vulnerability you describe would be limited to applications for which you are always logged in on your device.
Re: (Score:2)
Re: (Score:3)
Re:Is just me who thinks this is a really bad idea (Score:4, Interesting)
Even if both devices are "secure" and have the same user on them, there needs to be some form of solid authentication to show the user actually wants to transfer all this info from one device to another, just in case the other device happens to be something other than it purports to be and has some way of logging ephemeral from memory for decrypting the credential storage. This could be a PIN or other authentication used, but that isn't really something that can stand up to brute force, so maybe something like the Google account password.
Older Android devices that used dm-crypt instead of fscrypt allowed one to have an encryption key that could be long, and was typed in at boot time, then stored in RAM. Maybe a long base decryption key like that can be used, similar to how a DSRM password is used to protect the contents of AD local storage.
My question is how the credential transfer will take place. Hopefully the credentials are encrypted with a low level device key, then transmitted using some security protocol, so once on the new device, they are received encrypted, and only decrypted by a Secure Enclave.
Overall, the big issue is making sure the user who owns the credentials authorizes the transfer to a new phone, and some thought should be put into it, for example if the user is being coerced into transferring their stuff from an old device to a new device which belongs to a criminal, or criminals cloning the credentials from a device before it is remotely killed.
Theory vs Implementation (Score:2)
there needs to be some form of solid authentication to show the user actually wants to transfer all this info from one device to another,
In theory, I am sure that some CS PhD specializing in cryptography can come up with an extremely secure (tough a bit cumbersome) mechanism, that probably has a name referring to some paradoxical Generals who are both stingy and socialists or something.
But we all now that in practice, the implementation is going to be botched (in the name of simplicity and user convenience 1) and eminently exploitable and end up being abused 2.
---
1: Like: while holding each phone with at least 1 finger over the sensors, just
Re: (Score:2)
General Tso's KEM.
Re: (Score:2)
This could be a PIN or other authentication used, but that isn't really something that can stand up to brute force, so maybe something like the Google account password.
That's how it works, at least on Google Pixel phones. When you get a new one, you first log in to your Google account, with all the security that has. 2FA, multiple notifications that someone logged in etc. You can then use WiFi or a USB cable to transfer data from your old phone, including application data. I'm not entirely sure what the criteria is for this, because some protected data is not transferred, but some is.
It seems like this is a new API for handling stuff like WhatsApp and LINE where you can o
Re: (Score:2)
On iPhones, you hold one phone near the other while it is in OBE mode, then you do some authentication stuff and take a photo of one screen with the other phone, and after some more confirmations, it transfers over a direct wireless connection.
Cable isn't an option, USB-C iPhones have only just come out, and I don't think there are many people yet transferring from one USB-C iPhone to another. I guess it will come later.
The biggest pain for me was that Apple Pay cards didn't transfer across, and I had to go
Re: (Score:2)
That's basically how it is for Android, except obviously those have been USB forever and there is no mucking about taking photos of screens and the like.
Google Pay cards didn't transfer for me either, but re-authing them was just one automated SMS per card.
Re: (Score:2)
When you get a new one, you first log in to your Google account, with all the security that has.
This is yet another reason to never do that.
I've been using Android since 2013, but I never put a Google account on my device or use the Google apps.
Lately I've been installing custom ROMs with no Google apps at all.
Re: (Score:2)
storing in RAM is bad too, best to store ephemeral session keys, and permanent keys, in security modules. People can and so probe hardware looking for access, not just hunting for software failures.
Re: (Score:2)
It reminds me of single sign on. If feels like a really bad idea, a single point of failure, a wider attack vector, etc. And yet everyone is doing it. But you can say the same thing about the cloud, and many other common ideas. Right now it feels like I can get into a lot of stuff even if I have forgotten all of my passwords, I don't even need to go see IT, as long as I don't wait so long that it decides it wants to see a password again, or a fingerprint, etc.
Remember security and convenience are mortal
Ripe for abuse... (Score:1)
implement actual backups and phone data transfer (Score:4, Interesting)
android doesn't support transferring application _data_ when doing a phone to phone transfer. that means that if i transfer an app via cable, not only will i have to login, but the app will open with no saved data at all.
the only purpose of the file transfer seems to be to transfer your camera roll and some general settings
i wish google fixes this without requiring root and a third party app
Re: (Score:2)
THIS. That means no comprehensive transfers (including the credentials) and no app data transfer (note: that can be much more than some simple pictures or documents saved directly in the shared visible sdcard or whatever directory) AND NO BACKUPS.
They had some way of backing up some data bu
Re: (Score:3)
That isn't correct, I have transferred app data via USB and WiFi to new phones several times. App data is retained for most apps.
I think individual apps can opt out of it, like WhatsApp seems to, but other apps bring everything over. I was concerned about it because I have several apps that only store data locally, but it was moved over to the new device successfully, both user generated data and preferences.
Legally standardized vendor independant ... (Score:2)
... Ident/Auth/Auth is the foundation of a feasible digital culture.
Until that happens it will always be somewhat of a digital anarchy and the big mega-corps will do their own solutions that will always be compromizes and have some security downside vis-a-vis a universal standard.
Given, Google and Apple know how to do proper Ident/Auth/Auth and as experts do their best to implement it correctly, but it will always be tied to some sort of proprietary offering and security concerns that come with that trait.
Log you and LEOs in (Score:2)
Apppppp (Score:2)
I thought it already did this, because apps use your Google ID, used in the Google store that you downloaded them from.
This must be independent log in IDs with the app company itself, outside Google.
So, a feature that we had, that they removed... (Score:2)
I recall back in the old days (maybe 5 years ago, before everything became tokenized) when you could migrate or copy to a new system and everything was already logged in then as well. Unfortunately, caterwauling about MFA led to tokens that can't be transferred in the migration process, and you are stuck re-authenticating everything.
Meanwhile, the world keeps a movin', and new breaches are made every day. But hey, at least we tried, right? Screw the fact that it makes life more miserable. So, here, we have