One of my companies switched to Yubi pass keys. They were super cool -- until I tried to log in on a computer with only USB-A ports. My key is USB-C. I suppose I need to get an adapter now.
They can be, but most people will use what is built into their mobile ecosystem of choice, with built in sync/backup. Physical secure authenticators in general use will likely remain rare, but are still useful for use cases where passkeys that can be synced or migrated are not secure enough (and you want access governed with a simple physical device).
The title triggers me by itself. The article is actually much less problematic.
Anyway, I guess the way people are reacting on the comments is overwhelmingly due to the language. And the fact that it doesn't even try to explain anything.
IMO, the author didn't really know the things the article is about and is writing about some 3rd party information.
Except that Google and everyone else pushing passkeys have been publishing massive volumes of highly technical details about all of this for years.
You're looking at a non-technical blog post targeted towards the general public, and non technical journalists. Any technical details you want are just a search away.
How is that different from a password? PIN stands for Personal Identification Number. Words change meaning all the time, of course, but in this case there’s no reason to call it a PIN when there’s already another word for it.
The important difference is that it is stored on the local device, not the remote server.
Since the things stored on the remote server have been called “passwords” for decades, it seems helpful to call the local thing a “PIN” to help more easily distinguish it.
IMO it’s not more silly than calling a hand-held computer a “phone.”
The standards group that was behind Fido/U2F has been taken over by people who want to push a new product. That new product is "Log in with your phone" and phone lock screens allow biometrics and pins.
Password managers are not relevant, as you don't use a password manager to unlock your phone.
The people behind the takeover don't really give a shit about Yubikey-style tokens (which haven't achieved much market penetration anyway) but they've left them in to make the takeover less blatent.
More like the other way around -- the existing FIDO/U2F crowd was a bunch of businesses that made money selling keys. And that's why adoption was a rounding error, it was infinitely more expensive than a free password, so few implemented it. This is the obvious solution -- we're already carrying devices with a secure enclave, just use that, it's free.
You can have that by storing passkeys in your password manager, if it has support for that. Currently 1Password does, and BitWarden either does or is suppose to soon. I haven't looked at any others.
You should be able to use your password manager to handle passkeys. Enter your master password in 1Password, use passkey. And Bitwarden support is coming.
The PIN (or biometric) is not used to replace your Google account password. The PIN (or biometric) is used to authenticate to your device that holds your Passkeys, which in turn will authenticate you to your Google account (or any account that supports Passkey-based sign-in).
The PIN is checked by the local device. It never goes over the network, and the device can limit the number of PIN attempts to a very small number, because the only way to try PINs is to have access to the device.
Ugh, is this why my FIDO key started making me enter a redundant pin on the company login page (so: enter password, press FIDO key, enter PIN, press FIDO key)?
In my case i was already on passkeys and google decided to just... forget them all on my other computers. I can't use them to get in anymore. Why? Who the heck knows.
This whole passkey shit is going to be a nightmare for UX.
In general, the levels of security that people will increasingly need going forward, and the increasing requirement by companies to use that level of security, will be a usability pain for many people and a nightmare for at least a subset.
Is there any evidence that Google needs to mess with authentication flows? My mental model of the median Google account holder is that they have a bunch of photos/emails/docs/etc that are extremely valuable to them and their family, but of little value to criminals. With a dynamic like that, the security only has to be so high to deter random hackers and making it too difficult or confusing will ruin a lot of valid accounts and do much more harm than the criminals would have.
There are reasons to be skeptical of Google's motives here given their history of wanting to create user lock-in in various ways, and caring more about shiny new tech than general user experience.
There is incentive to gain access to personal emails. Not enough for spear phishing but enough for generic phishing. Access to email allows you to pivot to every online service in a person’s life.
Isn't it obvious that logging in with your face or your fingerprint is less secure? Sure, it's convenient, but any thug can just forcefully unlock your device.
Thieves can steal a car using tech magic. That is also true about access to accounts. That contradicts your comment. Biometrics, if stolen, can be used to access any of accounts if one obtains knowledge about how to use it for hacking.
Your comment violates HN guidelines, but as guideline says I assume good faith therefore I have provided details about how you're incorrect on that one.
A passkey does not contain and is not derived from biometric data, so one cannot login to an account using biometric data alone.
If one wanted to use biometric data to access a Google Account secured with a passkey, one would:
1. Need to find a device with that passkey on it (or an account like iCloud Keychain or 1Password that contains the synced passkey). Biometric data could be used to unlock the iPhone, in theory. I'm not aware of this being done in practice.
2. Then unlock that passkey. On iOS, biometric data could be used to perform this step, just as accessing the iPhone in step 1.
If you hold the power/volume buttons or do a Find My lock, it disables biometric auth on an iPhone. I assume there are equivalent tools on Android.
So, if I lose my iPhone and someone also scanned my face, they could login to my Google account by generating a face accurate enough to fool Face ID, and only if they did it before I marked the phone as lost.
It does not have to be a thug who makes your picture.
Titanic has crashed. Microsoft has been hacked. There are no solutions that do not contain bugs. There are no drivers for sensors that cannot be hacked.
Sure hacking a device is difficult, sure. Maybe nearly impossible, but I doubt it. All software has bugs. Some even backdoors. Some data are centralized and kept on big tech cloud storage which is a honey pot for hackers. Once hacker has biometrics data on your phone captured, it could be used. Not only to obtain your passkeys, but outside of your phone.
A simple google search confirms that. There was a biometric data breach. Sure this might not be the best result, but I spend 2 seconds searching for it. Quite generic article, but I think it is sufficient.
Most "thugs" interested in data sit in windowless offices in Manila or Delhi and effortlessly spam phishing and other attacks on weak credentials; they do not roam the streets looking for face-unlockable devices to exfiltrate. That is to say, almost all attacks are remote. And just because someone walking next to you on the street might have a black belt in martial arts, does not mean they're going to turn you into a pretzel on sight.
The reality is people are not good at creating, managing and using credentials well - and this is an existential risk for most users not realized until it's possibly too late. Any efforts to assist, support and otherwise absolve users of credential responsibility is a net win for infosec (though likely a loss for privacy).
The trend from Google continues to be towards "if you lose your phone with your credentials, you will be unable to log in". And Google refuses to create a scalable system that allows you access to your account by verifying your identity in person.
This is a recipe for disaster. And, possibly, a warning to move off GMail before it gets worse.
Fastmail rocks. I decided years ago to be the customer not the product, so I don't mind paying for services I use.
An added benefit of Fastmail is somehow its calendar is able to sync between my Outlook work calendar and some shared Google calendars I have, while Google is completely unable to reliably sync a shared Outlook calendar for me.
Not parent but the more important thing in "de-googling" is to move your logins to your own domain. That way you are not tied to a single provider and can always switch if your current one starts degrading.
After over a decade of @gmail being my primary personal email it is pretty painstaking to move all of my logins over, and some services do not allow you to change your email at all so your mileage may vary.
Several months ago I moved my family's email hosting to Zoho. Its been pretty solid. The web client is really nice, its got pretty good mobile apps, it provides IMAP/Exchange Sync on their cheapest paid tier so you don't need their apps. Zoho has a 5 user free tier of just email, but you're then limited to their apps. I'm using the Mail Lite tier with the larger 10GB storage which is $1.25/mo/user billed annually.
They have some tools to migrate email. I was migrating from an IMAP source, the migration was pretty quick and painless.
I would recommend Protonmail because you can also have a plan that allows you to use your own domain. The interface is much better than Google IMHO and the spam filtering is up there as well.
> And Google refuses to create a scalable system that allows you access to your account by verifying your identity in person.
People complain about government services, but this is something that government is good at. The DMV serves everybody, regardless of personal views, criminal records, etc. Companies can refuse service to anyone for any reason. What happens when you put all your eggs in Google's basket, and then they decide to close your account with no recourse.
To add, it is pretty poor there is no FAQ linked to from that post to answer basic non-technical questions as to how this is intended to be used.
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!
You have a valid concern, but I'm curious how many sufficiently non-technical users would be reading Google's blog. Practically speaking, it could be a moot point.
You can try this: https://support.google.com/accounts/answer/13548313?hl=en, this help center page is linked to from various parts of the product experience for regular users to get a better idea about passkeys if they are interseted.
So now that "friend" has access to your account? How is that more secure than my 32 random character password I store in an encrypted Keepass database that I back up offline?
Depends on the recovery mechanism. Providing a government credential with a live selfie is the gold standard. If a company doesn't support that, they're being cheap at the cost of security (you can perform such an identity proof for ~$1-2/per successful proof through a vendor like Stripe Identity or ID.me).
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)
How do I actually give them my real government document with it's physical security features through the internet? Just take a grainy photo of it? Really secure!
It at least avoids the user being phished or being compromised by reusing passwords.
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.
Despite what many companies seem to believe, looking at a copy of somebody's identification presented remotely documents does not constitute identity verification.
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.
What’s the standard then? Should it be possible to recover your account without possessing any evidence whatsoever that you are the person you say you are?
I've been locked permanently out of a (thankfully tertiary) Gmail account because their ML didn't like that I logged in from my new house. The option was to accept a push notification to a long dead and wiped phone.
Their state handling for the push notification based MFA factors is _atrocious_. I have had to “re-delete” a long wiped phone (or two) multiple times from more than one account. It seems to have finally stuck in the past year, but I’m suspicious that one day it could bite me in the ass.
Other businesses have humans on staff which will verify your identity documents. Google simply chooses not to do this, because it is expensive, and their "users" are not their customers.
I get a call from Google One Support. I explain the situation. They tell me to go to g.co/recover to recover my account (I already did this on my own). Same thing happens as before - same two options are given.
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]
They have offered this since 2017, in response to the Podesta email hack. It's free, but it's not the default, because traveling to a Google site is prohibitively expensive for the vast majority of their users.
Is there something there that explains how the recovery process is different? The only thing I see in the FAQ is somewhere that they link to the normal account recovery page, and say that you'd have to order another hardware token.
Yes, remotely accepting a copy of an identity document from the other end of a wire is not a good authentication method. That's because they're not intended for remote digital authentication. Photo IDs are intended to be validated in-person, using the original document, and the photo visually compared to the person holding it.
If you travel in an other country and loose your phone or the phone gets stolen. How can you log into Gmail from anything else if you need access to travel or anything else ? Like receiving a confirmation of identity by email from the bank or another service ?
Given your response you should read up on the reality of Google Account recovery, because the usual horror story is not that you have "no evidence whatsoever" but more like "I have all the evidence in the world including recovery codes, TOTP backups and a valid password and somehow I'm still locked out".
>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.
If you are on Apple ecosystem, iCloud can sync. Other password managers like 1Password can also be used to store your passkeys. If none of the above, you can always set up a physical security key and leave it at home.
IMO if you're reading hacker news, you're fully capable of setting one up and leaving it in a safe locale for recovery.
I think you’ll still need a password on your account for cases where no passkey is available, and possibly for other scenarios of heightened fraud risk. That’s why the setting they’re describing in the blog post is named “Skip password when possible”.
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.
I agree that recovery is an important question. Maybe they will make sure to prompt for a password at least every N months? I have no idea what their answer for this may be, but they probably have one.
> What is the account recovery process if I’m locked out and don’t have my phone, say it’s lost or broken and I can’t verify my identity?
> 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.
Then what's the point of it all if a hacker can still get into my account using the traditional methods? This seems to be just opening up another avenue of attack.
My Google account is set up such that account recovery requires me to actually travel to Mountain View and present several forms of ID, and that's just how I want it to be.
If I understand it correctly it will avoid phishing, assuming people notice there's something up when they see a page asking for a traditional login for no good reason when they have passkeys. And it may be a transitionary step towards no passwords or something.
When you get a duplicate of your SIM card you can then verify it is you with a SMS code.
There are also security questions and alternate email you can configure just in case.
If they're in your Google/iCloud, you're already in a game over scenario. The point of all this is to prevent that from happening.
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.
If they break into my iCloud then they’re in my iCloud. They’re not in all my other accounts, because I use an encrypted password manager that isn’t iCloud.
Think of it as using iCloud as your password manager and storing your OTPs - someone breaks into your iCloud, they get access to all the passwords and OTPs to login to any service in iCloud.
Always take the security of your password manager / sync accounts seriously. Use hardwre security keys if needed on the "root accounts".
iCloud is unfortunately impossible to adequately secure for that use case.
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.
It is a fair observation. And I can see why users tend to be alarmed about this. Although in my experience users tend to significantly underestimate the real risks of online attacks relative to these more visceral threats.
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.
> Let met ask you: has that discovery made you stop using your iPhone, or storing passwords or other critical data in your iCloud?
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.
How is that better than passwords? I backup my encrypted passphrase database to a cloud provider. When my house burns down and all my devices are lost, I get a new device, download my own passphrase manager app, download the passphrase document, and continue as before.
If someone breaks into the cloud provider and downloads my passphrase document, nothing happens.
And if I loose for some reason access to my phone number, termination of current number to create a new line with a new phone, I loose access to Gmail forever ?
Possibly. Security has made internet enabled accounts outright user hostile. Try helping a 70 year old guy get into his Gmail again. I despair over the disrespect Google and the other major internet corps show their tech-naive users.
I've heard "I'll call them" far too often, and am perpetually forced to share the bad news.
I had a fire. I lost every single thing I own, except my landlord grabbed my phone, bless him. Otherwise I would have been totally stuck as all my TOTP apps are on there.
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.
Have had to recover from 0 pretty similarly. My backup approach basically started with the fact that I knew the password to a cloud storage account that I had uploaded a keepass vault to, and that keepass vault had the password to my primary backup provider. In a full no passwords world, I would have had no chance to do so.
In my country my phone number is linked to my government issued ID so I don't need any physical properties to recover it (this might take some time though but for me it's still the best option).
> 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.
I have heard and read about a number of similar cases where people can get completely locked out of their account despite being able to authenticate correctly, because they lost access to some other required resource that Google decided is essential. I'm very skeptical about the utility of these types of security policies. I'm sure they prevent hacking in some cases, but they also greatly increase the chance of a legit user permanently losing their account which is a pretty freaking bad outcome for someone who has all of their email, messages, photos, documents and more stored in their Google account.
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.
If google thinks your login is suspicious, it will look for 2FA. If you don't have a phone number tied to that account at that time, it will insist you add one.
This is not true. It will ask for a provided number if you've already provided one, but if you've never provided one, it'll ask for any number and treat that as the provided number for future reference.
> 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.
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.
Getting locked out of a Google account because I didn't have the number anymore happened to me too. Even though I had everything else even backup email verification, password, etc. Was a massive hassle.
Especially when they migrate previously password-only accounts to requiring what they think your phone number might be, and especially given that it costs under $15 to borrow somebody's phone number for the day without their knowledge.
I need to find one of these services so I can borrow my old phone number for a few minutes to get back into my Google account before it is erased at the end of the year in Google's oncoming purge.
The solution would be to have a separate phone and phone number used solely for authenticating. It will never leave home, and never be used except to authenticate. Still vulnerable to home fire, however.
And what do you do when you go abroad and a web site says "Oh, looks like you are logging in from a new location - please check your SMS for a PIN now" :(
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.
This is accurate, but by putting your passkey backup with that external entity, you are putting all your keys in that basket. Passwords have an obvious, backup option with zero dependencies on third-parties: A printed list in a fire safe. I would not advise users go heavily with any passkey provider that does not provide a physical backup of a similar form that can be secured through non-technical means, and that can be used by an heir or attorney to act as you when you are unable to do so.
Passkeys aren't inherently un-backup-able. I do agree though that the most common forms of it (e.g., Android/iOS/Windows secure enclave passkeys) need better ways of recovery and remediation.
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.
The problem with that is people don't have fire safes. Or homes in some cases (e.g. many unhoused people have smartphones now). Also people need to travel and do recovery without having to fly home to their safe.
The idea that printing a backup is easy and an option for many people is often not the case.
And that is why most people use a single, easy to remember password for everything: even if their house burns, their devices are gone and they no longer have their phone number, they can still remember their password.
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.
And it's a hassle to keep it in sync. If you decide to update your password you need to remember to print out a copy and store it in the safe, oh and throw out the old one.
> (e.g. many unhoused people have smartphones now)
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?
I don't know how Google solved this, but it's an old solution. Shamir secret sharing. You break apart your keys into M pieces, where you need N pieces to reconstruct the key, so let's say 3/8. Then you need 3 pieces out of the 8 pieces it's broken into to recover your key. You take each of those 8 pieces and give to trusted sources. When you need to reconstruct your key, you have at least 3 of those give you the key and you recover.
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. ;-)
I had the same idea about a decade ago but never bothered to try to implement it. I felt like it would have suffered from the same problem all other technologies have in security: overly complex user interactions. The concept makes sense, but getting N other people to commit is overhead the average user probably doesn't want to deal with.
So I preferred the idea of regular folks for backup, for security reasons. I thought of the idea of professional users like say your bank or 3rd party. The issue is that it's far easier for the govt to subpoena those pro 3rd parties and recover your key. Whereas, they would have to know which of your friends you used for key recovery to be able to do that. The idea was to make it tough for a bad/powerful actor to steal your key. Of course, the challenge is that a non social person would need friends or to depend on ISPs, banks (pro 3rd party providers). My goal besides security when building this project was to break the chain of 3rd party auths (Google, MS, Github, etc) :-(. They use their auth as a way to lock folks into their ecosystem and if you offend them in anyway, you could lose access to everything. Offend Google on adsense and lose your personal photos/email. Offend Amazon on sales and lose your prime streaming/AWS access. Hopefully as the idea picks up, the monopolistic corps can be tackled again to remove such power.
I wholeheartedly agree with where you were aiming your goals. Other thoughts I've had:
- 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)
How? The usage was very easy. You select a contact and add them as your recovery contact (by selecting contact from your contact list) The system adds the key in the background. If they don't have the app, the app asks you to tell them to install the app (viral growth?). The users didn't need to know any thing technical. But install app, and click yes/no like they do with a 2FA app.
I think the challenge is more coordinating the 8 people who will be a trusted part of your life long-term. Also they’d have to be sure to keep their fragments of the key intact through replacing devices, etc, no? Seems like just keeping a Yubikey in a safe deposit box would be simpler.
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])
I’m not in the crypto world to know why this is the way it is, but if you only need 3 pieces out of the 8 to reconstruct the key, why split it into 8? Is it to have a larger pool should you need it/higher odds of being able to gather 3 should some pieces be lost?
Passkeys are a new technology and everyone - including users, service providers, and organizations - will take time to learn and adapt. In this interim period the recommended approach is to provide passkeys as an alternative to whatever is already offered. This is the approach that Google and many other service providers are taking.
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.
Passkeys represent the cumulative wisdom and experience (and compromises!) of the whole industry on how to keep users safe online. Appreciate your opinions that these efforts are doomed. It is safe to say, "We'll surely find out!"
No... A passkey is specific to a context (RP), which is why they're not stored on things like Yubikeys (which I think a lot of people in this thread are confused about -- the keying material on the Yubikey isn't enough to create the passkey).
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)
> Passkeys represent the cumulative wisdom and experience (and compromises!) of the whole industry on how to keep users safe online.
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.
Password managers like Dashlane and 1Password have announced support for storing and synching passkeys. As passkeys becomes more popular I expect more providers to step up as well.
Ecosystem lockin is not how we make a new technology like this successful. And all players in the game understand that.
Appreciate the response. And I wish this message was front and center. The Attestation feature is what worries me, when, say, the bank turns it on for a few 'blessed' providers, or mandate a hardware implementation.
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.
I use passkeys everywhere I find them. I do not take control or ownership of backing up - instead I have alternative 2fa or hardware key authentication with all those accounts.
For every account I have a hardware key for, there are 3 hardware keys associated with that account - 2 on-site, 1 off-site.
Yubikey keys - zero difficulty adding multiple - if a site doesn't allow multiple I wouldn't lock my account down to a single point of failure. All the big players seem to offer it, and I can not recall any that didn't. Google in the "advanced protection" days forced you to have more than 2 keys for this reason.
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.
How do you register your off-site hardware key. Did you have to go retrieve it each time you wanted to make an account?
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.
I think you answered your own question! The three key is optimum for ease of rotating (or so you can carry one on person) - but if your house burns down with your phone in it - you will lose anything set up since your last offsite rotation.
Sounds paranoid / crazy - but I have 0 anxiety about being locked out of an account that matters.
All those issues were obvious from the day zero, and raised multiple times by many people. They're deliberately ignored by the stakeholders.
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.
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."
On account recovery, the user is strictly no worse off with passkeys relative to passwords and arguably actually better off in many cases. This is not what I'd call deliberately ignoring concerns.
Yes, but if you had to resort to recovery you’re already past Passkeys or passwords. Recovery is not exactly in either’s spec, it’s a separate matter. Saying “but recovery is the same” is pointless - sure it is, by definition, because it’s out of scope.
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.
> 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.
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.
But you can set family members/significant others/etc as possible recovery mechanisms! This seems like a really workable solution that I don’t see people discussing in this thread?
Just happened to my in-law. She dropped her phone on the stairs, screen cracked, and became unresponsive. I gave her an older phone I had and swapped the sim fine. But she couldn't figure out how to log in to Google account because it was so adamant telling her to use her phone. Her laptop was logged out of her email, etc. Fortunately I have backup tokens for her from a previous incident heh. I have no idea what other folks will do.
A few months ago Google wouldn't even accept backup tokens for me. I was on vacation, and that tripped enough fraud detectors to cause problems. I couldn't log back in till I got on my home network and changed my password.
Back in the old days with no 2FA and only username/password access geolocation lockouts happened every time I went travelling. You could regain access by getting a code from a recovery email, but that often got locked out as well!
Eventually I set up my own VPN server so that the services still thought I was using my home IP.
Passkeys are instead of the password. You can still login using your password. This way, you don't have to keep entering your password if you have access to a device with a passkey and can access that device.
Passkeys don't (only) replace passwords – they usually also replace another authentication factor as well.
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.
Sure, but is that adequate? Not having people practice their passwords seems to be an anti-pattern for selling premium support in password managers, while many other apps ask with planned frequency.
A lot of services, but not all, will let you add passkeys which are tied to a password manager (e.g 1password) and not a physical device. If you've got one of those set up, you can download it on a new device and then gain access that way. In the case of 1password, this means you either have to remember your master password and your access key, or you have to have this stored somewhere safe. Perhaps choose a memorable password[1] and then encrypt an sd card and use one of these[2] in your wallet or a keyring usb drive or a yubikey so in the event of a fire all you have to do is grab your wallet or keys and you're good to go. Alternatively you could store this information in a safety deposit box, or with a trusted relative, or even your lawyer if they offer such a service.
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.
This is an interesting direction. It's worth noting that biometrics, like fingerprints or facial recognition, aren't really 'secrets'. They can be observed or leveraged without a users knowledge or consent, and in many ways function more like a username than a password.
Passkeys really aren't biometric authentication per se. If you use TouchID, for instance, Google isn't authenticating you based on your fingerprint. Rather, the fingerprint merely unlocks the cryptographic key pair that's then used to authenticate you.
I use Yubico Security Keys myself as passkeys. They're protected by a 6-digit PIN. But that PIN is strictly local to the device, meant to prevent snoops from logging in just by having physical access to the device (the keys get blown away after 10 consecutive unsuccessful PIN attempts). When I enter the PIN, the keys unlock, and it's those keys that get me into my Google account.
"To use passkeys, you just use a fingerprint, face scan or pin to unlock your device, and they are 40% faster than passwords — and rely on a type of cryptography that makes them more secure. "
Brute forcing offline kinda only works if you have a stolen hash or artifact like that. For a service like Google, they definitely have rate limits on password attempts.
I'm not saying I prefer either one here, just that password authentication doesn't automatically mean you can brute force offline.
The point is more so that the pin unlocks a key on your local device and that key is much stronger than the password the typical user would select. Plus it is site specific in a way that your typical user does not do with passwords.
So it's making a system weaker against offline attacks if someone steals your hardware in exchange for making it stronger against phishing. This is probably the correct tradeoff for most people.
A PIN associated with a specific device that been cryptographically linked to your account. So while a seven digit PIN is easier to guess than a password, the physical device is much harder to steal over the internet. It’s defacto 2FA authentication.
Someday, we will have brain reading technology to extract information from a newly dead brain, like we have to extract it from a RAM that was just turned off https://en.wikipedia.org/wiki/Cold_boot_attack
Entirely this. I do not trust devices to always be working or on my person. I will only use this if I can generate an offline, perfect fidelity backup of my codes.
“But it’s safe in the Google/Apple/Microsoft cloud” is not an acceptable answer.
As usual, the multi-device/multi-OS and recovery scenarios are simply just glossed over. I'll stick with a password vault I can sync to multiple OSes, thanks.
You can associate multiple passkeys with your account. Your account can have a passkey that is synced across Android/Chrome, and another passkey that is synced across Apple devices and browsers.
Seems that the recovery if you lose the devices with stored passkeys is still using a password.
And will it be possible to use software keys and backup them to wherever I want and use them with Google or is it going to demand TPMs or that I keep the key in a secure vault in my phone or something or the sort?
There still isn't a way to use this on desktop Linux right?
There's nothing about the PKI aspects of passkeys that requires you to buy into a vendor ecosystem and have them on device, right? They're just key pairs, but I guess it's a good as chance as ever to ram through device attestation.
In one of my groups leaders decided to reuse google suite accounts. It was really difficult for me to accept the account from a other person. Google sent multiple notification to other person phone, had to unlogin, configure two factor authentication, the other person had to ignore warnings about Linux access. It was nightmare.
On average, this might increase security (the vast majority of users are terrible at using passwords).
For proficient users who use passwords securely, this is an acute drop in security (if forced to use).
Forced phone number 2FA has the same effect; in Big G's case forcing phone number 2FA is anti-anonymity disguised as security. In this case, it's a bid for biometrics.
> Forced phone number 2FA has the same effect; in Big G's case forcing phone number 2FA is anti-anonymity disguised as security.
It can actually be both; in fact it very likely needs to be:
1. Phone numbers are the best long-term identity most people have
2. Google has billions of users and needs to support account recovery at unbelievable scale
3. Many people lose passwords and devices, but very few lose phone numbers
It logically follows google uses phone numbers to assign and delegate identity on their platform. Is this bad for privacy? Yes, but it's also very good for security because it allows users to control their data using a third-party authenticated "credential" they don't have to manage.
Sign up for Google's Advanced Protection Program. It's been around since 2017, and last I checked, it's the only way to fully disable the use of your phone number for authentication.
> For proficient users who use passwords securely, this is an acute drop in security (if forced to use).
Why? Because the user can have their device stolen and the PIN guessed? Can't you use a long password instead of a PIN if you want to?
And this part I'm not sure of, please correct me if you know. If I understand it correctly there's one security advantage even assuming a sophisticated user who is immune to weak passwords, password reuse or phishing. If there's ever a leak of Google passkeys, the leak would only get public keys, which can't be used for login, making the leak mostly useless.
I live in a country where my phone is forcibly tied to my identity. I will not use it to authenticate anywhere. For business purposes with my business phone perhaps, but certainly not for my private life. That would be a huge decrease in security.
Biometrics are used to unlock an local, on-device key storage mechanism which contains a private key, and from that you can derive a public key, and that's what Passkeys fundamentally are, is a public/private keypair you use to validate you are logging into a website. If Google were harvesting your biometrics they were just doing it already and it has nothing to do with this.
This is an extremely basic detail of the security model that has been true since long before these were introduced, back when the iPhone started using e.g. the secure enclave; I don't know why people on this website talk so adamantly about things they clearly do not understand at all. It's honestly kind of astounding.
> For proficient users who use passwords securely, this is an acute drop in security (if forced to use).
No, it isn't, it's the moral equivalent of an SSH key to login to a server instead of using SSH password to login to a server, but now apply that to a website. And beyond that, it's objectively wrong; for instance passkeys are literally phishing resistant, and no amount of thinking you can "use passwords securely" can change that simple fact.
Is it hard to remember the one password you use for all Google services everyone's already been doing forever and will still have to do for every other site? When's the last time anyone even had to log into Google on any device? I'm signed in everywhere all the time and it almost never seems to expire...
My desktop doesn't have a camera, fingerprint reader or touch screen...
Passkeys aren't "finger prints and face scans." They're dolled-up versions of SSH key authentication.
Just as SSH private keys can have passphrases to unlock them, passkeys can have passwords, passphrases, PINs, or biometrics to unlock them too. Servers don't authenticate you on those PINs or biometrics; those merely unlock the associated private key.
Always remember that passwords are protected by Fifth Amendment and similiar laws in other countries, but there is no law prohibiting officer to put your phone in front of your face to unlock it.
Why make claims for other locations when you don't know about them, and it could lead to serious consequences? In particular the UK has no such compunction.
One, the one to my password manager, where the rest of my passwords are stored--but without the additional part I add after I paste the password that is stored in my head.
The post mentions eBay as a site using passkeys. eBay's implementation on PC accepts Touch ID, while Google's implementation did not the last time I tried it.
Thank you. I am embarrassed to say that using the site reminded me that, actually, I had already created Touch ID passkeys for my Google accounts. I think what confused me is that passkeys were not available for Google Workspace yet, so my account there couldn't use passkeys. That has now changed.
For context, Gibson developed, and completed, an entirely secure and working solution to the problem Passkeys aims to solve, called SQRL (which I argue is better than Passkeys in a few ways). He is familiar with this problem space, and explains Passkeys in a straightforward way.
There are a lot of interesting points being made in the conversation here.
What I haven't seen yet is a reminder that a Google Account is effectively Google's private property that they're letting you access in exchange for vacuuming up your personal data.
683 comments
[ 1.4 ms ] story [ 368 ms ] threadhttps://passkeys.directory/
https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
https://support.apple.com/en-us/102195
Anyway, I guess the way people are reacting on the comments is overwhelmingly due to the language. And the fact that it doesn't even try to explain anything.
IMO, the author didn't really know the things the article is about and is writing about some 3rd party information.
You're looking at a non-technical blog post targeted towards the general public, and non technical journalists. Any technical details you want are just a search away.
Passkeys also requires the device. Using a pin with this is 2-factor. Pin + hardware token.
Since the things stored on the remote server have been called “passwords” for decades, it seems helpful to call the local thing a “PIN” to help more easily distinguish it.
IMO it’s not more silly than calling a hand-held computer a “phone.”
Password managers are not relevant, as you don't use a password manager to unlock your phone.
The people behind the takeover don't really give a shit about Yubikey-style tokens (which haven't achieved much market penetration anyway) but they've left them in to make the takeover less blatent.
In my case i was already on passkeys and google decided to just... forget them all on my other computers. I can't use them to get in anymore. Why? Who the heck knows.
This whole passkey shit is going to be a nightmare for UX.
There are reasons to be skeptical of Google's motives here given their history of wanting to create user lock-in in various ways, and caring more about shiny new tech than general user experience.
Everybody has a limit. I spent some time in interrogation... once.
They make it hard on you ? - They don't make it easy.
Yeah, it was unpleasant. I held out as long as I could.
All the stuff they tried. You just can't hold out for ever.
How'd they finally get to you?
They gave me a grasshopper. - What's a grasshopper?
That's two part gin, two part brandy, one part crème de menthe...
Please don’t insert commentary when it’s clear you don’t know what you’re talking about
Your comment violates HN guidelines, but as guideline says I assume good faith therefore I have provided details about how you're incorrect on that one.
If one wanted to use biometric data to access a Google Account secured with a passkey, one would:
1. Need to find a device with that passkey on it (or an account like iCloud Keychain or 1Password that contains the synced passkey). Biometric data could be used to unlock the iPhone, in theory. I'm not aware of this being done in practice.
2. Then unlock that passkey. On iOS, biometric data could be used to perform this step, just as accessing the iPhone in step 1.
If you hold the power/volume buttons or do a Find My lock, it disables biometric auth on an iPhone. I assume there are equivalent tools on Android.
So, if I lose my iPhone and someone also scanned my face, they could login to my Google account by generating a face accurate enough to fool Face ID, and only if they did it before I marked the phone as lost.
Titanic has crashed. Microsoft has been hacked. There are no solutions that do not contain bugs. There are no drivers for sensors that cannot be hacked.
Sure hacking a device is difficult, sure. Maybe nearly impossible, but I doubt it. All software has bugs. Some even backdoors. Some data are centralized and kept on big tech cloud storage which is a honey pot for hackers. Once hacker has biometrics data on your phone captured, it could be used. Not only to obtain your passkeys, but outside of your phone.
A simple google search confirms that. There was a biometric data breach. Sure this might not be the best result, but I spend 2 seconds searching for it. Quite generic article, but I think it is sufficient.
https://www.secureworld.io/industry-news/biometric-data-brea...
Quotes
"Facial recognition and fingerprint information cannot be changed. Once they are stolen, it can't be undone."
"Putting all the data found in the leak together, criminals of all kinds could use this information for varied illegal and dangerous activities."
Keychain, iCloud, 1Password... These are just details.
You still need the device/account that the passkey is stored on.
The reality is people are not good at creating, managing and using credentials well - and this is an existential risk for most users not realized until it's possibly too late. Any efforts to assist, support and otherwise absolve users of credential responsibility is a net win for infosec (though likely a loss for privacy).
The trend from Google continues to be towards "if you lose your phone with your credentials, you will be unable to log in". And Google refuses to create a scalable system that allows you access to your account by verifying your identity in person.
This is a recipe for disaster. And, possibly, a warning to move off GMail before it gets worse.
An added benefit of Fastmail is somehow its calendar is able to sync between my Outlook work calendar and some shared Google calendars I have, while Google is completely unable to reliably sync a shared Outlook calendar for me.
After over a decade of @gmail being my primary personal email it is pretty painstaking to move all of my logins over, and some services do not allow you to change your email at all so your mileage may vary.
They have some tools to migrate email. I was migrating from an IMAP source, the migration was pretty quick and painless.
Other alternatives:
https://www.hey.com
https://www.skiff.com
https://www.fastmail.com
https://www.icloud.com with advanced protection turned on
Is it possible to control the credentials in your phone and copy them somewhere else?
People complain about government services, but this is something that government is good at. The DMV serves everybody, regardless of personal views, criminal records, etc. Companies can refuse service to anyone for any reason. What happens when you put all your eggs in Google's basket, and then they decide to close your account with no recourse.
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?
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!
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-...
https://landing.google.com/advancedprotection
Many more people have a copy of my passport than have access to my Yubikey or recovery phone number.
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://www.corbado.com/blog/apple-passkeys-integration
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.
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.
> 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://safety.google/authentication/passkey/
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.
I've heard "I'll call them" far too often, and am perpetually forced to share the bad news.
Even if it's passwordless by default doesn't mean there is no passwords for recovery.
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:
https://f-droid.org/en/packages/com.github.axet.smsgate/
https://kozubik.com/items/2famule/
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.
[1] https://support.1password.com/emergency-kit/
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?
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).
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.
[1] https://news.ycombinator.com/item?id=37833206
This is a privilege I currently enjoy right now, and one I am not really eager to give up.
[0]: https://support.1password.com/save-use-passkeys/
[1] https://news.ycombinator.com/item?id=37836783
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... :)
[1] https://news.ycombinator.com/item?id=37836783
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.
Eventually I set up my own VPN server so that the services still thought I was using my home IP.
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.
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.
[1] https://xkcd.com/936/
[2] https://amzn.eu/d/ia3kFeJ
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 use Yubico Security Keys myself as passkeys. They're protected by a 6-digit PIN. But that PIN is strictly local to the device, meant to prevent snoops from logging in just by having physical access to the device (the keys get blown away after 10 consecutive unsuccessful PIN attempts). When I enter the PIN, the keys unlock, and it's those keys that get me into my Google account.
Who wrote this sentence? It's just a mess.
I'm not saying I prefer either one here, just that password authentication doesn't automatically mean you can brute force offline.
These types of chips tend to have many layers of physical security to protect the real key.
So it's making a system weaker against offline attacks if someone steals your hardware in exchange for making it stronger against phishing. This is probably the correct tradeoff for most people.
It's basically like a chip & pin bank card.
If your platform uses face scanning, you can read how it protects you from that.
For FaceID on iOS, it uses additional sensors beyond just a camera.
“But it’s safe in the Google/Apple/Microsoft cloud” is not an acceptable answer.
like biometric + one time passcode?
Seems that the recovery if you lose the devices with stored passkeys is still using a password.
And will it be possible to use software keys and backup them to wherever I want and use them with Google or is it going to demand TPMs or that I keep the key in a secure vault in my phone or something or the sort?
There still isn't a way to use this on desktop Linux right?
On average, this might increase security (the vast majority of users are terrible at using passwords).
For proficient users who use passwords securely, this is an acute drop in security (if forced to use).
Forced phone number 2FA has the same effect; in Big G's case forcing phone number 2FA is anti-anonymity disguised as security. In this case, it's a bid for biometrics.
It can actually be both; in fact it very likely needs to be:
1. Phone numbers are the best long-term identity most people have
2. Google has billions of users and needs to support account recovery at unbelievable scale
3. Many people lose passwords and devices, but very few lose phone numbers
It logically follows google uses phone numbers to assign and delegate identity on their platform. Is this bad for privacy? Yes, but it's also very good for security because it allows users to control their data using a third-party authenticated "credential" they don't have to manage.
But it would be even more secure if there was an opt-in "I don't want to use my phone as 2FA".
Phone number authentication creates a weakness for anyone who is in a targeted attack.
A motivated attacker can easily bribe/trick a telecom employee, or if physically accessible, swipe the phone itself to read 2FA texts.
https://landing.google.com/advancedprotection/
Why? Because the user can have their device stolen and the PIN guessed? Can't you use a long password instead of a PIN if you want to?
And this part I'm not sure of, please correct me if you know. If I understand it correctly there's one security advantage even assuming a sophisticated user who is immune to weak passwords, password reuse or phishing. If there's ever a leak of Google passkeys, the leak would only get public keys, which can't be used for login, making the leak mostly useless.
Biometrics are used to unlock an local, on-device key storage mechanism which contains a private key, and from that you can derive a public key, and that's what Passkeys fundamentally are, is a public/private keypair you use to validate you are logging into a website. If Google were harvesting your biometrics they were just doing it already and it has nothing to do with this.
This is an extremely basic detail of the security model that has been true since long before these were introduced, back when the iPhone started using e.g. the secure enclave; I don't know why people on this website talk so adamantly about things they clearly do not understand at all. It's honestly kind of astounding.
> For proficient users who use passwords securely, this is an acute drop in security (if forced to use).
No, it isn't, it's the moral equivalent of an SSH key to login to a server instead of using SSH password to login to a server, but now apply that to a website. And beyond that, it's objectively wrong; for instance passkeys are literally phishing resistant, and no amount of thinking you can "use passwords securely" can change that simple fact.
My desktop doesn't have a camera, fingerprint reader or touch screen...
I had read some good things about YubiKey, but I don't think I could get it to work on my corporate computerr.
Just as SSH private keys can have passphrases to unlock them, passkeys can have passwords, passphrases, PINs, or biometrics to unlock them too. Servers don't authenticate you on those PINs or biometrics; those merely unlock the associated private key.
I highly recommend reading Steve Gibson's notes on Passkeys from his Security Now! podcast episode #870: https://www.grc.com/sn/sn-870-notes.pdf (p. 10-13)
For context, Gibson developed, and completed, an entirely secure and working solution to the problem Passkeys aims to solve, called SQRL (which I argue is better than Passkeys in a few ways). He is familiar with this problem space, and explains Passkeys in a straightforward way.
You can find this full podcast episode on Twit.tv: https://twit.tv/shows/security-now/episodes/870
You can also find a full text transcript of the episode, transcribed by a human - by hand, here: https://www.grc.com/sn/sn-870.htm
What I haven't seen yet is a reminder that a Google Account is effectively Google's private property that they're letting you access in exchange for vacuuming up your personal data.
The only winning move is not to play.