As a user I still don't understand this.
What happens if there's a house fire or something and all my devices where I'm logged in with Google break? How do I log into my account again?
What happens if there's a house fire or something and all my devices where I'm logged in with Google break? How do I log into my account again?
Eventually I set up my own VPN server so that the services still thought I was using my home IP.
How does this look in implementation. When I Implemented this in multipasskey (YC demo). It would ask you to select contacts you trusted. Then it would send the sharded parts of the key in the background to them. If you need to recover, you make a request to them. It would reconstruct your device key when you got enough pieces. Once you have your device key, it would download your encrypted backup of keys from the remove server and you are back as new.
I called my project multipasskey in 2017/2018 and applied to YC with a working demo and they said nope. I'm going to assume that I sucked at selling it. ;-)
- What if access is time critical but your backup people are distributed across timezones? Or they aren't available for some reason? Could be hours to days before you could recover your account
- Adding/removing people as they enter/exit your life could make it a challenge to maintain (PGP + trust vibes)
Very very cool.
But also completely unrealistic for the average person to use.
If it is a safe at your home, you need to have a fixed home address in the first place, and the usual advice about off-site backups also applies.
If it is at friends or family, you’re back at the same problem.
If it is a rented deposit box, you need to trust the company you rent it from (banks don’t usually offer such services anymore, and there are risks like in [1])
[1] https://www.nytimes.com/2019/07/19/business/safe-deposit-box... (archive: https://archive.is/7qbkR)
You have to have at least 3 peers, though (IIRC, 2/3 is the minimum split possible that would provide fault tolerance).
I assume as a technical person, the answer is I should have a backup device with a friend and/or store my passkeys somehow on my Apple or Microsoft or password manager account as well.
But it needs more explanation in detail from Google!
Also, never lose your phone number. I can't get back into my Google account even though I have the username, password and recovery email because I can never get the SMS code.
This is an excellent point. Google seems to be uninterested in addressing this transparently, but despite their push for phishing-resistant MFA and first factor sign-in options, they still consider a phone number to be golden evidence.
My father changed his phone number last year and never updated his Google account. Despite having a recovery email address he could access, TOTP, and printed backup codes, it was not enough. Google wanted to “verify it really was him” after a move (and IP address change) and it doesn’t even allow a password reset to be authenticated with any other recovery option. Phone number or bust.
Given the importance of these digital services I expect that refusing to provide support to users in this situation, as Google is well known to do, won't be legally tolerated at some point in the future. Unfortunately this won't be changing anytime soon, so the best we can do is inform others about the risks of relying solely on Google for anything important and hope people backup what they can.
With Google Workspace an admin can reset / disable your 2FA, so that part is out of your hands anyway.
Finally, I don't see anything in Google Workspace that requires a phone number. Someone can correct me if I'm wrong there.
Discord does the same.
I'm not the only one to have encountered this
That's asking a user to verify themselves with a provided number.
Likely because the user doesn't have anything else set up for 2FA.
What is not true?
> if you've never provided one
I started this thread off with don't provide a number.
Again, set up a alternate 2FA with them and you won't have to deal with a phone number at all.
> and treat that as the provided number for future reference
Even if they did add it in, you could remove it later.
The claim that google will never insist you set up 2FA by providing them a phone number if their ML algorithms decide your log in is suspicious.
Based on my own experiences with a little used google account and finding the messages of other users who have encountered the same error.
What is your basis for claiming that my position is untrue?
1) that's not what I said.
2) that flow you describe isn't asking you to set up SMS 2FA. It is asking you to verify an account with SMS. Likely because there is no other way for them to verify your account.
> Based on my own experiences with a little used google account and finding the messages of other users who have encountered the same error.
The number of people who've reported that error is super small. Even the link you provided is 10 months old. This must be related to an edge case of not having another 2FA set up.
> What is your basis for claiming that my position is untrue?
You said that it insists you add a number. I don't believe that is true. The example you provided does not show that is true.
The forced SMS 2FA that banks and credit card companies have started implementing infuriates me for exactly this reason.
https://news.ycombinator.com/item?id=28251107
I use "SMS Gate", an open source app available on F-Droid:
That said, you are bringing up the right questions on the general topic of account recovery that everyone should be asking even without passkeys: "How would I login if I forget my password / lose access to my password manager / lose my second factor devices" and have a plan. Introduction and adoption of passkeys do not completely eliminate the need for thinking about your account recovery situation.
However, there is one special case where using passkeys is actually better for account recovery. If you create passkeys for your Google account on an Apple device with iCloud keychain, the passkeys are synched to your iCloud, so now even if you lose all your devices because your house burned down, as long as you have access to your iCloud account, you can just get all the passkeys for your Google accounts(and other websites).
Now, you may ask: 'what if I lose access to my Apple iCloud account" -> that's a fair question! Which is why I said Account Recovery concerns do not completely go away - but they can be significantly reduced with passkeys in many cases.
This whole scheme depends on either users being savvy enough to do vault backups or depending on service providers being functional.
Both are quite doomed.
Users have a path for passwords - they can write them down on paper and keep them with their important things. This tends to work for most folks.
The backup story for passkeys is horrible. There is no path for my elderly relatives who don't use cloud services.
Until that is fixed, passkeys will never replace passwords.
Don't forget password sharing! That is a whole screwed up story with passkeys too.
The industry does not put users first. It puts it's own risk reduction first.
Your Netflix passkey is not the same as your passkey to other services. It's generated as soon as you enroll the passkey with Netflix (by calling "navigator.credentials.create()") and is identified by an opaque handle and also the public key (this is important, because you never get the public key again so you must keep both of these: the ID, and the Public Key, otherwise you can't verify a challenge-response, since you're only given an ID and a Digital Signature at that point).
For a site to use a passkey it calls "navigator.credentials.get({ publicKey: { challenge: ..., rpId: "<same_id_as_used_when_creating_like_netflix.com>" }, mediation: "silent" })"
Which returns the key ID and a signed version of the challenge, or an error.
Everywhere you authenticate you have one or more keys, identified by these opaque handles which are stored in the User Agent and associated with some mechanism for performing digital signatures with that unique key. The User Agent, generally, has to store and distribute this information if you want to use the same passkey across multiple devices -- even if you're using a Yubikey (because, again, it's not storing the key being used for the digital signature, it's storing a private key which is used in the process of generating the digital signature, but not the passkey's actual private key -- i.e., the secret part of the public key generated earlier)
Your grandmom probably isn't gonna be airdropping a Netflix password.
That is true _if_ you do not highly weigh all the concerns that have been brought up in this thread today. I do not trust Google to help if things go wrong so why would I ever consider such a system wise? Frankly, you seem to be ignoring concerns if they contradict your belief that this system is better. I'm reminded of Upton Sinclair.
This is a privilege I currently enjoy right now, and one I am not really eager to give up.
Ecosystem lockin is not how we make a new technology like this successful. And all players in the game understand that.
Watching https://github.com/keepassxreboot/keepassxc/issues/1870 with baited breath... :)
Firefox on Desktop tells me to "touch my security key". Not sure how that works. Firefox Android gives me a few hardware options to store my passkey to. Chrome Desktop asks me to enable Bluetooth. Chrome Android asks which Google Account to use.
For every account I have a hardware key for, there are 3 hardware keys associated with that account - 2 on-site, 1 off-site.
By count of sites, most sites don't appear to take security that seriously so anything more than a password is off the cards, but the big ones - the ones that actually matter; email, cloud, etc. should all be able to be secured.
I suppose every time one makes an account one can register the two on-site keys, and then rotate one of your on-site key to off-site and take the off-site key home with you, and then finally register it.
Maybe I should get a third key...
Sounds paranoid / crazy - but I have 0 anxiety about being locked out of an account that matters.
They strongly want to lock you in to their own authentication platforms (iCloud Keychain, Windows Hello, 1Password*), that's why they don't want to address this.
It's impossible they're not aware about those issues. Anyone with a brain and some technical expertise would come up with those questions in an evening or two, and Passkeys were worked on for months. To best of my awareness, there is no official acknowledgement (support replies "no, you can't do this" doesn't count, that's just restating facts, not acknowledging an issue).
*) Ok, 1Password says they're all about user freedoms and that it's up to user to decide where they store their passkeys - but that's what they say, not what they do. What they do is indistinguishable from Apple and Microsoft.
See the section titled "Recovery security" in this article:
https://support.apple.com/en-us/102195
Relevant excerpt for those too lazy to click through:
"However, it's also important that passkeys be recoverable even in the event that all associated devices are lost. Passkeys can be recovered through iCloud keychain escrow, which is also protected against brute-force attacks, even by Apple."
Also, I'm pretty sure if Apple decides to block your iCloud account, you're most likely SOL.
Passkeys make it more likely that you’ll have to resort to account recovery, because it’s explicitly easier to lose passkey access than a password access (assuming that all platforms that implement passkeys implement password management as well, and that every password manager allows “export” by showing password to a naked eye).
One can write a copy of their password in a notebook and use it from anything with a keyboard and network connection. This mechanism is built in.
Passkeys are explicitly worse in this regard, as they don’t address export at all. Some implementations may be at par, but the overall spec is strictly worse, as it fails to address number of obvious issues.
Talk about victim blaming. Google and other companies introduce policies that make total identity lockout both easier and more problematic. Instead of investing in customer service to deal with this issue, the customer needs to "have a plan". What a crazy coincidence that this policy increases Google's profitability by decreasing support.
> You can always fall back to legacy authentication options such as passwords and traditional 2-step-verification. In a case where you can no longer remember your password, you can also go through Google’s Account recovery flow. We encourage you to add your email and phone number to ensure you can always access your account.
https://news.ycombinator.com/item?id=37833390
Scenarios dealing with the loss of Passkeys:
The scenarios for dealing with the loss of Passkeys are effectively the same as dealing with the loss of your Password Manager (if you use one) or otherwise stored passwords.
Dealing with the loss of all your devices that use Passkeys If you manage to lose access to all your devices that are used to authenticate via Passkeys (e.g., a house fire), then there are two main outcomes: either you have your Passkeys synchronized to a cloud provider or other external entity that still has a copy of all your Passkeys, or you do not. If you do not have a backup of all your Passkeys, they are gone, and you will need to fall back to account recovery for each affected account. If you have a backup of your Passkeys, you would need to regain access to it on a new device and then synchronize the Passkeys to it and use them as normal.
Dealing with the loss of your accounts that synchronize and store Passkeys If you use a synchronization service attached to an account, it is possible that the account can be deleted or access to it otherwise lost. In this event, you would most likely still have a working copy of your Passkeys on your devices, and depending on whether or not you can export them or reconfigure synchronization with a new account, you would be able to add them to a new account, effectively creating a new account to store and synchronize your Passkeys.
Dealing with the loss of all your Passkeys
If your Passkey account is not only deleted but also tells all your devices to delete the Passkeys, or you lose all your devices and the accounts are deleted due to inactivity then you are basically in the same situation as having lost all your devices and not having a backup. You will need to fall back to account recovery for each affected account.
That said, what you describe is easily doable in other forms. For hardware tokens, you can have a spare Yubikey that's authorized on your accounts and keep that in a fire safe with its unlock PIN. For something like 1Password, you can print out a recovery kit [1] with the secret key and unlock password.
Agreed, I'm just not willing to endorse their use until there are robust recovery and remediation processes.
> For something like 1Password, you can print out a recovery kit [1] with the secret key and unlock password.
Yeah, this is what I want Google/Appleto provide as it is robust to both user incapacity and provider refusal-of-service.
They seem ripe for corporate use where ransomware and phishing are common threats and IT can manage account resets by walking over to their desk.
The idea that printing a backup is easy and an option for many people is often not the case.
Fair enough, but that is an argument for multiple durable recovery and remediation solutions, which few of the current providers have.
For all of its many weaknesses, a password has that one major advantage over all the other authentication methods, and unless a new method provides a similar advantage, most people will keep using a password, just like they did even with the appearance of private keys, biometrics, USB tokens, SMS or TOTP.
I go out on a limb and say one smartphone usually - that is at heightened risk of getting stolen. With passwords, the person would probably just pick something they can remember in case the phone gets stolen. With passkeys, what should they do?
Disclaimer: although I worked for Google many years ago in a role entirely unrelated to Google account authentication, I have no inside info on this announcement, could be wrong about what I say in the first sentence of this comment, and am not speaking for Google here.
Easy: you will never log in to google again. Since google has zero reachable support, that's the end of your account.
This works better with something like a credit union where as a last resort just can just walk in there in person with IDs and restore access.
But with these internet giant companies which take pride in not having any reachable support ever? Nope, nope and no.
I've heard "I'll call them" far too often, and am perpetually forced to share the bad news.
You can try to recover by revoking all your passkeys and starting over with hardware tokens, but that's likely what a sophisticated attacker is going to try as well, and they're probably faster than you.
Still way way better than passwords.
Always take the security of your password manager / sync accounts seriously. Use hardwre security keys if needed on the "root accounts".
If you shoulder-surf somebody's phone unlock PIN and grab their phone, you have everything you need to take over their iCloud account, including their passkeys and the capability of locking out all of the victim's other trusted Apple devices and changing their iCloud password.
This was very surprising for me to witness first hand – fortunately not in the identity theft scenario, but only when observing a relative regaining access to their iCloud account using only their iPad they were logged in on.
Let met ask you: has that discovery made you stop using your iPhone, or storing passwords or other critical data in your iCloud? If the answer is "No", then you're strictly better off moving to passkeys stored on iCloud as well.
Yes, it has (the latter). I was a big fan of (non-synchronized) on-device passkeys, but this has significantly changed the threat model for me.
I use a third-party password manager exclusively now, and I'll probably be using its synchronized Passkey implementation too if it turns out to be any good.
As soon as Apple starts offering a different set of security trade-offs (e.g. make usage of the recovery key mandatory when resetting my iCloud password, or at least implement a timed lockout), I'd gladly start using iCloud Passkeys and maybe also its password manager.
If someone breaks into the cloud provider and downloads my passphrase document, nothing happens.
Even if it's passwordless by default doesn't mean there is no passwords for recovery.
Like if you lose your password today?
Passkeys solves for digital identity compromise (credential theft or stuffing/spraying), but you must rely on other mechanisms (such as a I mention above) if you want to elevate identity assurance higher in the event of credential loss.
(consumer IAM is a component of my work at a fintech; auth/creds security, passkey rollout, high identity confidence when an account is recovered, etc)
But it seems in this case the account recovery is just using the password so the passkey is mostly convenience and maybe Google trying to move things away from passwords more than a complete change.
Google wants to be a gateway to everything else you do.
The next step is to get other platforms to accept Google passwordless auth.
Photo ID is (relatively) secure in exactly one use case: Verifying that a person standing in front of you is who they claim to be. Everything else is inane pseudo-security.
Then I'm told Google has a very strict security policy, and accounts cannot be changed in any way by support. So going through the recovery process is the ONLY way back into my account. So the call ends with them saying "I'm so sorry I can't help you." [1]
[1]: https://www.linkedin.com/pulse/when-you-get-locked-out-your-...
Many more people have a copy of my passport than have access to my Yubikey or recovery phone number.
That other factor might still be available for account recoveries (together with a password or recovery email etc.), but if either are not regularly exercised, users might forget them or lose access to them and not notice until they also lose access to their passkey(s).
That said, Google's and Apple's passkey solutions themselves are cloud-synced (with no way to opt out), so as long as users of either can still access their Google or Apple account, they would not be totally locked out.
What apps support this?
>Note: To use passkeys, iOS 16, iPadOS 16, macOS 13, or tvOS 16 (or later) is required. iCloud Keychain and two-factor authentication must also be turned on.
https://support.apple.com/guide/iphone/use-passkeys-to-sign-...
https://developers.google.com/identity/passkeys/supported-en...
IMO if you're reading hacker news, you're fully capable of setting one up and leaving it in a safe locale for recovery.
At the end of the day, it's the individual's responsibility to determine how much they value their digital security and take what they deem to be the necessary steps, expenses and precautions to protect it. The only other alternative would be for Big Tech to have some kind of integration with the state, so that your digital accounts are tied to something like your passport or social security number, so that there are procedures available for regaining your digital identities in the event of catastrophe, just like you can do with your physical identity.
I personally think that the latter is where we are heading, not necessarily because of scenarios like you've mentioned, but because it's only a matter of time until AI advances to the point where it's going to cause a dangerous breakdown in trust and the only way it's going to be fixable is with some kind of system that is tied to physical reality. The internet will end up splitting into two, with the majority spending their time on the "verified" web, which will be websites using OAuth that will require you to use an account with one of the big providers who will have verified with the government or third party agency who you actually are. And then any websites that don't require this will form a sort of new, more accessible "dark web". I honestly think the majority of people are feeling that wary and weary of the internet at this point that they will happily choose the verified web, regardless of the surveillance implications.