Android's 'Restore Credentials' Feature Will Automatically Log You In To Your Apps On a New Phone (theverge.com) 18
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:2)
... 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: (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)
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
Ripe for abuse... (Score:1)
implement actual backups and phone data transfer (Score:3)
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)