Android's 'Restore Credentials' Feature Will Automatically Log You In To Your Apps On a New Phone (theverge.com)
(Thursday November 21, 2024 @10:30PM (BeauHD)
from the that-was-easy dept.)
- Reference: 0175518935
- News link: https://mobile.slashdot.org/story/24/11/21/2323246/androids-restore-credentials-feature-will-automatically-log-you-in-to-your-apps-on-a-new-phone
- Source link: https://www.theverge.com/2024/11/21/24302562/android-restore-credentials-transfer-restore-key
Google is introducing "Restore Credentials," a feature that [1]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 [2]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 [3]delete an app and reinstall it .
[1] https://www.theverge.com/2024/11/21/24302562/android-restore-credentials-transfer-restore-key
[2] https://developers.google.com/identity/blockstore/android
[3] https://developer.android.com/identity/sign-in/restore-credentials#:~:text=Note%3A%20Restore%20Credentials%20does%20not%20handle%20the%20scenario%20where%20an%20app%20is%20reinstalled%20on%20the%20same%20device.%20Uninstalling%20an%20app%20is%20interpreted%20as%20an%20intent%20to%20delete%20the%20corresponding%20restore%20key%20from%20that%20device.
> 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 [2]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 [3]delete an app and reinstall it .
[1] https://www.theverge.com/2024/11/21/24302562/android-restore-credentials-transfer-restore-key
[2] https://developers.google.com/identity/blockstore/android
[3] https://developer.android.com/identity/sign-in/restore-credentials#:~:text=Note%3A%20Restore%20Credentials%20does%20not%20handle%20the%20scenario%20where%20an%20app%20is%20reinstalled%20on%20the%20same%20device.%20Uninstalling%20an%20app%20is%20interpreted%20as%20an%20intent%20to%20delete%20the%20corresponding%20restore%20key%20from%20that%20device.
Ripe for abuse... (Score:1)
by zurkeyon ( 1546501 )
This thing better have the greatest security known to nerds, or its gonna have issues ;-)
implement actual backups and phone data transfer (Score:2)
by Espectr0 ( 577637 )
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
Is just me who thinks this is a really bad idea? (Score:4, Insightful)
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? When you don't really have a way of being sure that the phone is in the hands of the genuine user of these accounts?
Re: (Score:2)
> 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)
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.
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)
Convenience always wins over security. You just poke here and computaz do beep boop beep, magic happen, wow I like it! Plenty of places this can go wrong. And it will, just you wait. I would bet on eating my hat if I had one.
Re: (Score:2)
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