Passkeys are now enabled by default for Google users
blog.google
blog.google
Just last month my missus cracked the glass of her iPhone. Apple repaired it under AppleCare, which is great… except… that they didn’t tell her that the “glass repair” entails them replacing the guts of the phone and wiping it in the process.
Apple iPhone backups don’t contain cryptographic secrets like eSIMs!
She got stuck in a loop where she couldn’t activate her eSIM because that needed her email, but her email needed MS Authenticator, which she couldn’t activate without an SMS.
She had to drive to the Telco with a pile of photo ID to reissue her eSIM. Her bank account got locked in the process despite the password being correct because of some sort of phone hardware lock.
This took days to fix and multiple in-person visits to various organisations. If this had happened while overseas on holiday, she would have been screwed.
Times have changed.
Your entire digital identity is now a smart card in your phones
That Smart Card is either a SIM card or an onboard TPM chip, but in any event if you lose it, you may as well be dead as far as anyone else is concerned.
Passkeys make this much worse. At least if you still have a physical SIM you can transfer it from any phone to any other phone.
Passkeys are not cross-vendor transferable!
Run away screaming. Don’t believe the hype. Wait until the vendors get their act together and come up with a solution for transfer and recovery.
This might feel true, but it's factually not true.
Both passwords and TOTP can be phished. In addition, passwords can be weak, reused, and password hashes can (and are frequently) stolen and cracked in server breaches.
Passkeys are guaranteed to be strong, unique (can't be reused), strongly phishing-resistant, and there's nothing worth stealing from servers (just public keys).
Passwords and TOTP are not fine, they're both fundamentally broken when you look at them in the context of the modern internet attack landscape.
years ago i was robbed in dc of my phone at night on the way to a concert. i use google voice and was able to login at cvs to contact a friend to meet me there. in 2023 i would have been locked out by not having a 2fa or phone
If Neil deGrasse Tyson gets locked out of his Instagram, you can be damn well sure someone answers his support request.
If you or I, in two to four digit follower counts, have an issue? We can get fucked.
Damn near most companies do this with the social media PR teams, too. Any tags/mentions, messages, etc are filtered through software that decides how much cloud you have and thus how worthy of attention you are. Delta loses your guitar and you've got 100 followers? Nobody in the social media team is likely to even see it. Someone with 5000 followers, and a post about it gets a couple hundred likes/retweets? American is going to fall over themselves to make it right.
That's the great lie about social media - that you can use it to draw attention to a problem you're having. Unless you've cultivated a large enough following, you'll be completely ignored.
In any case, you should have multiple methods. It could be passkeys on multiple devices. It could be TOTP, plus recovery codes in a safe. Passkeys are just one more method.
For the longest time, the gold standard for authenticating people has been tamperproof hardware with keys that cannot be copied. Except iPhones actually have credible biometrics on top of that. Much better than Yubikeys, for example. Of course you always need to have at least one backup device or other method in case your primary device is lost. Now that this is finally making it's way to the “normal people”, it's suddenly a “run away screaming” scenario? Come on.
I predict this will not be true always.
IMO, this also means the problems with Passkeys will get fixed pretty quickly. And given I can already store my Passkey in 1Password and then use it on every device I currently use (including Firefox on mac/windows and iOS Safari), it's honestly not a huge problem.
I think passwords are a much bigger problem for people. Simple/re-used passwords are still incredibly common-place, and too many people don't realize how big of a problem that is. Once you incorporate a password manager so that you don't need to remember passwords... Passkeys via a password manager should be even easier to use, given you don't have to rely on browser extensions auto-detecting input fields.
Or a password? Wait, didn't we want to get rid of passwords? How is that any better?
The kinds of people with reused passwords all over the place won't use 1Password. And if you do use 1password to actually generate strong passwords you don't need passkeys and it works on all kinds of services without those having to support passkeys.
Cloud-based backup storage – contained configuration data, API secrets, third-party integration secrets, customer metadata, and backups of all customer vault data. All sensitive customer vault data, other than URLs, file paths to installed LastPass Windows or macOS software, and certain use cases involving email addresses, were encrypted using our Zero knowledge model and can only be decrypted with a unique encryption key derived from each user’s master password. As a reminder, end user master passwords are never known to LastPass and are not stored or maintained by LastPass – therefore, they were not included in the exfiltrated data.
In other words, the thieves went to the bank vault a d stole your safety deposit box but can't access it because they need your key, which only you posses.
If I can store my passkeys in 1password (or lastpass etc) then nobody needs access to my physical phone. They just need access to my password manager's password.
I agree that for many many people password managers are way better than alternatives. But they don't magically make everything safe.
It's like MFA. "it is all safe now because we will send you a code via SMS" and the people fall for social engineering attacks that make them disclose the code the attacker just had the bank send to them.
I doubt such people will be a le to safely use a password manager or passkey for that matter. Passkey are just new enough that we have not had widespread news about how crooks were able to find the weak link(s). Probably on the human side again like in many cases.
So even if there is some sort of hardware tie in that only ever works with real hardware an attacker just needs hardware. Or virtual hardware I guess ;)
Totally out of context parallel: Pokémon Go. A game that gets you out into the world to find and capture Pokémons and talk to other people. Or spoof your GPS coordinates with a simple SDR setup. No anti-cheating software on the phone will ever know.
Apple and Google do not quickly fix things when users have no alternative in my experience.
> And given I can already store my Passkey in 1Password and then use it on every device I currently use (including Firefox on mac/windows and iOS Safari), it's honestly not a huge problem.
For you. You believe the criticisms are dishonest?
Still being the operative word. Consider situation with running banking apps without hardware attestation, etc
I believe all of the issues you've described, but you can usually add multiple passkeys to each service. There is nothing stopping you from adding your iPhone and a cheap android phone and having redundancy, or using 1Password and storing your passkey in there.
iPhone backups do store backups of the media stored in iCloud Keychain, if you have another apple device or if you have the recovery key, you can get back in. You just need the device passcode or recovery key and you can re-bootstrap everything. eSIMs are unique because they're carrier things and those things have and always will be a pain and tied to stores and phone calls.
So no, writing down the SSH private key is not the solution. The solution is to trust multiple private keys, each stored within tamperproof hardware.
This is also why, as a service provider, I'd like to see some device attestation. I want to know that the keys being used here are not written on a fucking piece of paper.
This is precisely why user should run away. Service provider is moving liability to end user and washing their hand away, while user gets screwed if anything happens during vacation.
With a bank, if I lose paperwork, they will have a process in place for me to prove my identity. BigTech will shrug if my phone-locked passkey becomes inaccessible.
The effort and hassle for Google et al to invest in robust support mechanisms (backend and people) for passkeys makes it highly unlikely.
No doubt you'll get the standard boilerplate email responses, if you are even that lucky, that just point you to an FAQ or something similarly unhelpful.
Imagine leaving identity to a corporate who simply shrugs off all but legal threats. It's terrifying and I reckon we are in our way there
If you want to avoid that, just set up multiple devices.
I have had a (Google) phone suddenly die in my hands without any prompting. With a password I was able to transition to a new device without incident. If my passkey was locked to that device, I might have found myself locked out of my digital identity.
But you can use multiple devices... How is "a password written down and stored somewhere" better than a separate device used for backup purposes? Hell, get three devices, go nuts.
Let’s not forget the providers who do not offer the ability to enroll multiple devices. Last I heard, AWS would only let you put a single authenticator on your account.
Anyway, to be clear, I'm not advocating for "get rid of passwords forever", I'm saying that for a lot of people passkeys are superior and the whole "how do I recover" is just not that big of a deal.
The main issue is the cost of devices like yubikeys. They should lower those. Companies should start providing them. Schools should hand them out. etc.
With passkeys you have to buy multiple phones, sign each of them into every one of your accounts, then keep them physically distributed (no cloud storage for phones). And to make sure they still work you have to periodically manually go and interact with the phones physically, even the one you stored in a bank vault. You also have to do this if you sign up for a new service.
Not to mention the inevitable services that don't allow multiple passkeys.
As a user I hope you don't get it. Having an easy way for services to require that everyone using them is doing so via the official app on an iPhone or OEM Android phone sounds like a nightmare.
This seems incorrect. “ Like passwords, passkeys are encrypted and stored in your iCloud Keychain”
I also just recently set up some passkeys via 1Password and they are also not hardware bound.
If I can't access my pk, I cannot be phished. As soon as you allow me to copy my key (instead of creating many, which should be acceptable) I can be phished again.
That is, passkeys cannot be phished. The only way to get into my passkey protected account is to physically gain access to my passkey device, which requires both physical access to the device, and a second factor like a face/fingperprint or PIN/password.
Additionally, the TOTP secret can be copied, while today passkeys don't allow that either.
Any web service that locks accounts to devices is going to be shedding customers as they lose or replace phones.
But as a user, this is not a realistic solution. If I have to keep multiple pieces of hardware enrolled, that means that I have to keep all the multiple pieces of hardware at hand when I create an account somewhere, and go through multiple enrollment cycles.
That means that I have to keep all the various pieces of hardware in the same physical location and relatively easy to access, which removes a great deal of the safety of redundancy.
It's just not realistically workable for me.
> I want to know that the keys being used here are not written on a fucking piece of paper.
Why do you care?
Except shorter for convenience. Something you could even memorize.
How does this work? Do I have to visit the website of each service from my secondary device for it to get the alternate passkey?
But not all setups support this. Some only allow one. Obvious issues abound.
I'd go as far as to say "most setups don't support this. Most only allow one".
The services I've seen so far that support multiple passkeys are in the minority.
All of the things I've used passkeys on support both web and mobile auth, which necessitates two keys.
you can do it on your own with twilio, then create a phone number and have a program forward you stuff to your real phone.
the twilio phone is hard to lose as it has an api and you can toss it when you want to start over.
except now, you need an entire phone virtualized as your proxy instead of just a twilio phone number.
they keep raising the barrier
The problem here is that you are assuming one passkey. Just like you don't get just one key for your door its risky to get only one passkey, if you are planning to use it exclusively.
Passkeys are like normal keys but for your digital life. They have many benefits over normal keys like being impossible to copy/pick while still being easy to replace (as long as you have one that works) and if used properly (with a short pin-code) someone who finds or steal your key cant log in to your virtual doors anyway. They compare even better to passwords.
Just get one for your keychain and one to put at your stationary computer at home. The only thing to remember is to add both to your account(s), which still is faster than fiddling with your password manager and/or second factors.
Passkeys are really amazing, the only thing(s) remaining is to stop confusing people with terminology, explain that you should have a pair and for services to start properly using the keys as a combined first+second factor with a pin (which you can have safely the same on all your passkeys, in contrast to passwords).
What do you mean not cross-vendor transferable? You can use any brand key that properly implements the protocol (fido2/webaunth), and replace them with any brand key. If you mean copy them, well yea that's kinda the point..
There are plenty of ways for recovery on reasonable services, sometimes they ask to set up way to many (and with multiple passkeys, recovery is only relevant if you loose ALL of your keys).
Just want to point out that if your missus had a pair of passkeys there would not have been any issue!
The solution is to set up multiple pieces of secure hardware, not writing down the keys to the castle on a piece of paper.
It is true that you do need to be rich enough to own a phone and ~100 USD of something else (laptop or USB), which does put redundancy out of the reach of a large portion of the world. But then they can just use regular 2fa at the expense of not being phishing-proof.
Things being this complicated makes them a non-starter. A nerd vanity project.
And this isn’t a knock on the “intelligence” of the general population. They quite rightfully won’t want to spend their limited time on God’s earth learning about all this.
But information sovereignty is crucial when it comes to this stuff; losing that is a regression that will cause problems
Seriously, just tried passkey on an Android phone of mine with a burner account. I would not recommend this to anyone. Passkey as a tech might not be the issue, but the lacking option of just removing devices and passkeys freely from your account is just not acceptable. The vendor simply has different ideas about security than I have and it is not just restricted to serving me "safer" ads.
Very much this. Having authentication tied to hardware you don't control is a near-certain denial of service in the future.
People love to hate on passwords but the reality is that for many circumstances (threat models) they are the best compromise. You can make them more than strong enough (take 32+ bytes out of /dev/random and encode however you like, nobody will ever brute force that in this universe) and various passwords managers solve the problem of re-use (never reuse a password).
And it comes with the benefit that you control how it is stored and can apply as much redundancy as you want to feel comfortable.
They are going to be the gatekeepers if you and the web services let them. Oh yeah — also they’ll run all the web, email and other services anyway. Trap you in their metaverse and AI most likely, since that’s where your coworkers and friends will be you’ll have to be there too.
Resist by opting out :)
But in many other countries, gmail isn't that successful. Still, email is still under attack by big mail servers getting more and more restrictive.
Then you can tie it to hardware you do control, or to software.
Obligatory "Passkeys misconceptions" article: https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
- "I can’t recover the keys if I lose the hardware"
- "That is a risk you’ll need to take if you’re using hardware authenticators"
Fantasizing that with this proposed simplification of the authentication process people will introduce complexities such as a password manager or a backup hardware device is naive to say the least.
Passkeys are WebAuthn credentials that are synced between devices, so they aren't hardware keys, they're software keys.
"more secure" is a completely meaningless statement, I wish this usage would die already (in general).
You need to talk about security in the face of a very specific threat, then you can say solution A is better than solution B against threat T1, worse for T2 and about a wash for T3 and so on.
Security is not a linear scale from 0-100 where you can say "more secure". There are many different criteria and any given solution will be better in some, worse in others. You must do a threat model for your specific use case to say if something is better or worse for those specific threats, and keep in mind other people will have very different threat models for the same solution.
Since this is the greatest security problem, I would hope all the vendors trying to improve security would focus on that.
Exactly. Unrecoverable secrets tied to closed hardware solve for the scenario where your most important criteria is that no attacker be able to ever access your account, even at the expense of yourself possibly losing access to it forever.
Does this solve a problem anyone actually has for consumer accounts? No.
That threat model makes sense for highly classified information where it is preferable to lose the information forever than have an attacker get it. Other than that, it's not a reasonable threat model to optimize for.
Threat #2: User creates a weak credential
Threat #3: User reuses a credential (uses same credential across multiple services)
Threat #4: Phishing
Attackers use huge password dumps compiled from multiple server breaches, and then try them against other services. Relying on a combination of the fruits of their labor from all four threats, attackers successfully compromise millions of accounts on the internet every year.
If you want to see the data, check out the Verizon Data Breach Investigation Report that comes out every year.*
These threats affect a majority of both consumers and enterprises.
Passkeys address all four of these major real-world threats. Passwords address none of them.
Threat #1 mitigation: with passkeys, only a public key is stored on the server. Attackers can steal all the public keys they want; it will not help them compromise any user's account.
Threat #2 mitigation: passkeys (which are WebAuthn credentials) are guaranteed to be cryptographically strong. It is not possible for a user to generate an insecure passkey. This is because the browser the the Operating System APIs take care of generating the credential.
Threat #3 mitigation: passkeys (which are WebAuthn credentials) are guaranteed to be unique. It is not possible for a user to reuse the same passkey across multiple apps/websites. This is because the browser the the Operating System APIs take care of ensuring that a new, unique credential (passkey) is generated for every new app/website the user sign's into.
Threat #4 mitigation: passkeys (and all WebAuthn credentials) are bound to the server FQDN at the time they are created. The browser and Operating System APIs take care of ensuring the credential is only ever sent to the app/website server it was created for. Users cannot be tricked (via phishing) into using their passkey on a malicious app/website controlled by an attacker.
* https://www.verizon.com/business/resources/T249/reports/2023...
But personally, as a technically able user, my risk of randomly losing access to my Google (or MS, Apple, Meta, etc) account is far greater than from all those threats combined.
If we had a trustworthy and accountable authority operating this stuff then it would be great. But we don't, we have a bunch of companies who are neither of those things.
It's like mandating that everyone must use self-driving cars that are on average safer than human motorists but occasionally randomly drive off a cliff.
That aside, what happens if you lose your current password? Every major platform out there has a method for recovery. Why can’t that be used for passkeys as well? I don’t see how there’s any incentive for companies to lock us out of accounts, when the platform is pointless without people consuming it.
We may have very little power, as users, but if enough people have trouble getting into their own accounts, that’s going to directly impact the bottom line of the company locking them out. From a purely capitalist standpoint, that’s a really good reason to make sure that that doesn’t happen.
Lastly, at least Bitwarden is planning on having passkey support in their password manager very soon, so there’s real competition that will allow users to be in full control of their own passkeys.
Password managers don't solve #4. But you left out the huge one, losing access to the account. Which for most people is a larger risk than all the others put together.
For just about every person and account, the near-zero chance of getting personally spearphished is much less relevant than the risk of complete loss of access.
Losing access to your passkey/password manager is a separate concern from the strength of the credential itself. Passkeys and passwords are just credentials. What you use to manage them is a separate concern. The concern about losing access to your passkey manager is super valid, but that same concern applies to all password managers that exist today. It's not a new concern that's specific or unique to passkeys. Yes, if you lose access to your password/passkey manager, then whatever solution you're using better have a great recovery story.
I know that at least both 1Password and iCloud Keychain have pretty great recovery flows. I am not sure about Google or the other password/passkey managers (I haven't looked into it deeply).
>of getting personally spearphished
100% agreed that most people don't need to worry about spear-phishing attacks. But that's (sadly) not super relevant, because many users fall for run-of-the-mill basic phishing attacks that any reader of HN would never fall for in a million years.
Additionally, part of the security concern is also accessibility by yourself.
edit: Just tried the Google passkeys on one of my Android phones. It is a complete usability hell and it seems I cannot opt out again without logging in from my browser and deleting my "device". If there is another way to just do it from my device without an additional browser, please tell.
Here is 1Password discussing how passkeys are simpler to use than passwords: https://1password.com/product/passkeys
Here is Ars Technica declaring that passkeys are easier to use than passwords: https://arstechnica.com/information-technology/2023/05/passw...
Etc etc. If this is the first time you are seeing businesses and media refer to passkeys as being simpler to use than passwords you haven't been paying attention.
I can definitely believe passkeys are easier, in light of that.
Saying that, I am struggling to understand what is the expectation for ordinary user behavior in terms of hardware-tied credentials. Eg so many people upgrade their iPhone every 1-2 years. If passkeys are not transferred to the new phone, what is the industry suggesting people do?
I have frequently heard and read claims that passkeys are easier to use than passwords. The claim always seemed incorrect to me for so many reasons. What passkeys do is make things more complicated, but move where the complication is.
“That is a risk you’ll need to take if you’re using hardware authenticators. The fact that the key isn’t copiable means you only have one of it, so you should probably be enrolling multiple hardware authenticators on each account, or just switching to a software authenticator if you don’t care about the decreased security.”
Software authentication with backup and synchronization is how passkeys are being shown to end users on two of the biggest platforms. For Apple, this is iCloud. For Android, it’s Google Play services. Add to that the fact that 2FA tokens are very often tied to a particular phone, and there’s very little difference between a passkey and the current system of passwords + 2FA, except that passkeys are currently far more resistant to phishing.You can try this out on webauthn.io and changing the attachment setting.
Also, what's stopping us from falling into the passkey version of the world we got with OpenID, where many services force you to log in with your BigTech account?
Facebook is still going to want me on their websites even if I’m running Firefox. Most websites people visit will not do any chrome WEI attestation. Likely exceptions are sites which handle any legal, financial, or health-related data. Not credit cards. I doubt most Google properties will use WEI.
They still want to slurp up all my juicy Firefox usage data and I bet they think a lot of such users will drop their services like a rock if it meant otherwise dropping their browser.
Or at least they will at some point in the near future.
> And it comes with the benefit that you control how it is stored and can apply as much redundancy as you want to feel comfortable.
Honestly, I agree!
I used KeePass back in the day (https://keepass.info/) but now use KeePassXC (https://keepassxc.org/) and it's really nice - I don't know any of my passwords because they're all randomly generated and are pretty secure, in addition to them being unique for every account. The only one I have to remember is my main password for decrypting the safe, which I also wrote down and entrusted to someone close to me due to its complexity.
It honestly works great, software to interact with the password safe is on every platform where I need it to be, in addition to it being super easy to reason about storage, because it's basically just a file - that I can then put on self-hosted Nextcloud, or another solution like that, or USB sticks or burn to CDs for all I care.
Maybe I should also migrate all of my TOTP stuff over to it and look into good Android apps at some point, then I wouldn't quite need Google Authenticator or FreeOTP anymore, either.
There's also the possibility of bringing my netbook with me, which also could have a Nextcloud client setup (or Syncthing, or some cloud based option), same as every other device that I own, which would have the last offline backup of the file even if the server itself would blink out of existence.
Honestly a bigger problem without my phone would be the fact that I basically couldn't pay for things all that well when using a card, because of a redirect to my bank when making a purchase online (to confirm it), which then makes me use https://www.smart-id.com/ with a code to confirm it. That's kind of a problem because it's not TOTP but rather it's bound to the device.
I can work around the password safe issue with an SD card that has the database on it, or a USB stick as well, but that wouldn't work for the app, so in the modern day I'd basically need to have two phones, the same way someone might have two sets of keys to their apartment or something. Kind of crazy when you think about it. And I'd also need a smart card reader to even register a new account in most cases, in combination with my government issued ID card.
You can use passkeys with a yubikey, right?
Adding a passkey to an account is like adding a yubikey to an account (experience wise). You can (typically) add multiple keys to your account.
It's also not all or nothing. You can (in every service I've setup) still have a password and an even a TOTP.
The multiple passkey option kicks out my other session when i use the other passkey.
That doesn't mean giving up on having good security, though. Passkeys don't work like eSims and other users' situations might not be the same. Their failure modes will be different. They might have more than one device (like a phone and a tablet), or they might not use MS Authenticator for their email, or they might have set up different recovery methods?
We need more backups and user education, which ideally would include rehearsing account recovery before it's actually necessary.
> But while they’re a big step forward, we know that new technologies take time to catch on — so passwords may be around for a little while. That's why people will still be given the option to use a password to sign in and may opt-out of passkeys by turning off “Skip password when possible.”
So, soon passwords will be added to “Killed by Google,” along with my account. (I keep zero devices logged in.)
It’s well past time to migrate off my few remaining use cases. I wonder if my employer will be able to reset my corporate account passkeys when the inevitable happens.
It would be awesome to have an "emergency" server where I could type in the URL, decrypt it with my passphrase and OTP, and get access to everything I need temporarily so I can re-bootstrap all my stuff. Of course, this doesn't solve the problem of SMS 2fa being used for everything, but it's a good first step.
I am in favor of crossplatform solutions like YubiKey. Apple and Google passkeys are lame.
Unless you store the passkey in a hardware Fido key like a Yubikey. Then the way to transfer it is to physically carry the key and plug it to another device.
This “cross-vendor” property is nice but it’s not required to defend against being locked out of one’s stuff.
I moved quite a bit of logins to Passkey and I chose to stay with the Apple ecosystem as my Passkey Lord/God. So far, it has worked and I have moved between devices (desktops, mobile, and the in-betweener).
Assuming I’m going to stay for quite a while with the Apple Ecosystem, am I doing it wrong by making my Passkeys pass through my Apple ID?
For instance, I change my eSim or number or replace phone, won't accept next time I login and then verify from the laptop, desktop, iPad, watch, or, heck, the Apple Polishing Cloth? (Assuming the cloth will become a smart cloth eventually).
I pretty much use 3; Yubikey in my workstation, portable Yubikey, phone. All 3 of those can bootstrap Google, which I use for email, and Apple, which I use for my phone. Then, everything else is in 1password, which are available through those mediums. Worst case, I am pretty sure in the most dire of dire emergencies, I can get my email back no matter what. Verify ID with my DNS provider, switch MX records, back in business. Even then, it's not necessarily essential to daily life. (A colossal inconvenient to lose access? For sure. Death sentence? Probably not.) All my SMS and Signal contacts are elsewhere. I can spend money out of my bank account by writing a check. I can get into work stuff by showing up in person at an office.
I do think that passkeys are probably too complicated for the ordinary user of computers; unfortunately that "we'll just email you a link every single time you want to sign in" seems like the most user-friendly passwordless authentication.
I also don't feel great about my habit of putting passkeys in 1password, because I know I'm locked in forever. But, I like the service, and when I want to switch, welp, at least there's a list of accounts I have to remake.
My biggest fear is something like forgetting my phone's passcode. One time I woke up, got distracted at just the wrong moment, and could not for the life of me remember my 6 digit passcode. (I also use the same code to unlock my workstation.) I had to distract myself and then use muscle memory to remember it. It was really crazy, truly one of those "did I just have a stroke" moments. I have that saved in 1password now, so if I have one unlocked device, I can refresh my memory. This happened a while ago and I don't think I have dementia. Just a weird quirk.
(Meanwhile, I can perfectly remember every 1-year-max-lifetime password I've ever had at any job. A lot of that good does when you can't remember a 6 digit number!)
I am not being sarcastic - which ever service your authenticating to make sure you have passkeys from at least 2 different devices so you do not lock yourself out.
If you don't fit into this multi device assumption, passkeys are not going to work well for you. There will not be a standard for transfer / recovery.
And the question they will ask is about the need to have two passwords.
Some common attack vectors like phishing would be more secure since you more or less automatically generate different credentials for different services, just as you get different access tokens from your oauth service. Token theft is an issue too, but only ever partially compromises you for a limited time.
Have 3 passkeys
2 of them on-person at any time (e.g. one on your phone TPM, one on a Yubikey)
1 of them off-site (e.g. keep a backup Yubikey at home in a fireproof safe, or use a 1Password passkey, depending on your threat model)
I thought passkeys were supposed to be convenient to use.
I use four: an Apple Passkey, a YubiKey I keep on me, a YubiKey at home, and a YubiKey in the bank. When I sign up for a service, I need to register all four of them. Not only is this generally a bit of a pain in the ass, but it also means I have to remember to go fetch the one in the bank vault periodically and update the credentials.
If I could save a stub locally that would let me register with a key not in my physical presence, that would go a long way to making this more usable. Even better would be the ability to register a bundle of them all in one go without having to do it four separate times.
As it stands right now, it’s hard to recommend to users who don’t understand or care enough to take all of these steps. Which to be clear is entirely reasonable on their part. It’s an unacceptable amount of work and mental accounting for it to be something the average person can do without high risk of losing their entire digital identity.
I feel you, but I don't think Average Joe's threat model requires keeping a Yubikey in a safe deposit box (this is besides the issue that safe deposit boxes are less safe than you think: https://www.nytimes.com/2019/07/19/business/safe-deposit-box... ). A cloud-based passkey (like 1Password) is fine as the off-site backup key for most people.
You're probably right, but this is still new enough that I'm nervous to rely on that. If 1Password has a data-corruption incident and you don't have other passkeys, there goes your digital identity. 1Password (or Apple Keychain) plus two YubiKeys is almost certainly fine. But that does still now run into the pain of registering multiple passkeys.
To be completely honest, I sometimes wonder if it's borderline malpractice that sites allow registering only a single Passkey. Registration processes should fundamentally require you to onboard two of them at a minimum, and encourage three. Or maybe I'm just becoming curmudgeonly as I get older. But I do worry that the current state of things—while absolutely on the right track—is going to be an unfolding disaster for non-savvy early adopters.
I have Yubikeys and find this frustrating.
Is there not a technical solution that should've happened by now, or is it not as simple as I'm imagining: can't hardware passkeys have a way to export whatever it is that's needed for services to register them (public key/s?) such that if you have 4 keys you can export 4 files to your PC and and time you create an online account just provide all four files at the same time to be registered?
I guess maybe it's not as simple as being a public key that can be registered without the key being around, some sort of active challenge/response needed as part of registration? Or is my imagined solution above completely workable and just overlooked so far?
That's exactly the part that makes this solution unworkable.
I just have a hardware key on my key chain and one on a pretty fireproof safe (which I got for other reasons). But I still added a phone recovery just in case.
As I understand it, the recovery process will always wait multiple days while sending many emails to me that it's been initiated.
They are when using a third party password manager like 1password or dashlane. At least in they are device agnostic. Haven‘t yet tried to export a passkey to another manager.
I don’t think I am alone in thinking I am on borrowed time. Someday, probably due to my own fault I will be locked out of Google and my digital life will be over.
If a private company can offer a similar login method like login.gov and let me talk to a real person when I am locked out like the USPS, I will be screaming shut up and take my money.
1) The House smartphone → it is where you install everything truly vital, like the main bank app (started mainly because of this), 2FA apps like authy google microsoft equivalents, passwords, streaming apps (to do their 2FA), etc. This phone NEVER NEVER leaves the house, except ONCE if the bank app requires on location authentication of the phone for the bank app to function, which is common practice with traditional banks.
2) The Street Smartphone → you essentially create a ''street bank account'', deposit sufficient money for day-to-day transactions for some days or weeks, install the app, and only keep this app installed for any money use (many people also avoid even using the same bank as the main bank app, as the main bank usually is a traditional bank with physical locations to get help - and has tons of personal information stored - and the street bank usually is a fin-tech bank that people do not really trust like old banks, either economically or for security, but it has less personal data anyways). It also has the essencial social media like Whatsapp, instagram, some password manager like bitwarden or the apple-google cloud, and 2FA (the ones who actually use it) is avoided in this device.
3) the thief smartphone → many people like to take some old phone around to give to a thief if the need arises, this way even the street smartphone is saved. Might not work if the thief smartphone is too old or clearly broken though.
4) the work smartphone → the only mostly chill 2nd smartphone on the list, useful to keep private life separate from the professional life, and also is useful to avoid the boss sneaking into the worker's private life and devices. There was a scandal here when a provincial government out of the blue installed a whole app in the smartphones of teachers AND students with no warning or any control whatsoever, and many people got scared that the administrative google service app being used by all (google education or some s*t) pretty much allowed the devices to be remotely controlled and viewed by the employer , be it private or public, so many people assumed any work devices is or can be done the same.
Can you elaborate ?
What does this "on location" process look like ? What do they ask you to do ?
A disaster scenario in practice means you are screwed either way here, tons of physical documents can be lost or destroyed too, but that is a calamity that by definition is exceedingly rare.
Most are worried about common thiefs, a scenario of robbery or assault that can happen anytime anywhere and frequently, repeatedly. The overall threat here is far larger that the rare scenario.
Now, to the complexity. Usually the thief smartphone is some old phone still around, might not even be working, and no one puts anything in there, it is literally a throw-away device. It has no complexity or hassle, and usually is free. The house smartphone, people usually repurpose some old smartphone or buy a cheap android. I still have an iphone 6 for this purpose, and if the app is up to date, it usually is safe enough. People will not be using the phone for anything else, it will not leave the house, so exposition is severely reduced.
It isn't a matter of if, it's just a matter of when. Backups and a thorough disaster recovery plan is absolutely mandatory for anyone who cares about their data. Some company is going to mess something up due to no fault of your own. It is inevitable.
Unfortunately, there aren't good disaster recovery options for some aspects of lost accounts, but having multiple accounts and avoiding single-points of failure help some.
[1] https://mastodon.laurenweinstein.org/@lauren/111103819626952... [2] https://mastodon.laurenweinstein.org/@lauren/111211366080459...
The criticism is based on the idea that most non-techie folks are unlikely to use a strong PIN and are unlikely to set up strong biometrics. There’s a related criticism about malware being able to steal passkeys on PC-based systems.
At least in this case the thief has to steal the physical phone instead of guessing "password123" on the google signin prompt from the comfort of their home.
Also- how many non-techy people do you know that avoid using on-device biometrics? On my end, the number is approximately 0.
> The criticism is based on the idea that most non-techie folks are unlikely to use a strong PIN _and are unlikely to set up strong biometrics._
On-device biometrics are typically _also_ used to unlock the device password manager, so my other remarks still apply. I bet a sizeable portion of the HN crowd also uses biometrics to unlock their well-configured password managers on their phone.
At least, that's what I personally do. Entering my very strong vault password every [lock duration] on a touch keyboard is already irritating enough; I'd rather just look at my phone to unlock my passwords when I need to use autofill.
...very high? I don't understand how this is unlikely, pretty much every phone owner with a google account is signed into that account on their phone.
What does this change?
And none of that helps you when someone robs you of your phone and says tell them your unlock code or they’ll stab you. Now they’ve got all your passkeys too.
So yes it is true that your phone and it's pin/biometrics are ultimately the most important thing for security. But passkey on your phone is no worse than the previous state.
But even this can't protect against getting locked out of your Google account due to some Google policy change, so ideally we'd rehearse how to get by without it.
I thought the Apple Store would check your driver’s license or whatever and reset your password, recovering whatever is protected by the escrow keys.
I know Google loses accounts all the time, mostly thanks to “surprise 2FA” combined with zero tech support. I’d believe Apple screws this up too, but I haven’t heard any anecdotes.
Care to share a link to examples?
Modulo the whole privacy/vendor lockin issue, passkeys are not a terrible alternative to people without 2FA reusing the same basic password on every single website.
However, when you actually rely on it to secure things, it quickly becomes a massive nightmare - made even worse by it being treated as equivalent to password+2FA.
passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks. A passkey alone is much more secure than the vast majority of password + 2FA combinations.
The only thing stronger than a passkey standing alone is a Security Key, but Security Keys come with a lot of usability downsides that can easily bite the average user, including:
- inconvenience: you have to remember to carry it around with you everywhere (and not lose it!)
- recoverability: you're completely screwed if you lose it and don't have extras that you already previously added to your accounts. (this also means that you need to buy at least two security keys to have a decent recovery story.)
- rotation (have to log in to every single service, one by one, to re-add new key if you change keys)
And if you really want the extra security that a Security Key provides, you can use a Security Key as a passkey.
Blanket statements like this demonstrate a misunderstanding that "security" is just one thing in a single lineal scale.
In reality you have to ask, secure against what? And to answer that meaningfully you need to a thorough threat model for the specific use case of person P and account A.
The same person P will have a different threat model for every account they have.
The D in STRIDE is for denial of service. Passkeys are much worse on this axis than any other solution. You need to evaluate for the specific combination (P,A) how much this matters vs. other criteria.
Here's the full context again:
passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks.
>The D in STRIDE is for denial of service. Passkeys are much worse on this axis than any other solution. You need to evaluate for the specific combination (P,A) how much this matters vs. other criteria.
How are passkeys (really, WebAuthn credentials in general) any worse in terms of denial-of-service attacks than passwords?
I think you're trying to make a point about specific passkey/password managers, rather than the actual credentials themselves. Is that accurate?
He says it's "easy to find" but apaprently he can't find it. https://mastodon.laurenweinstein.org/@lauren/111211489395997...
Why is "weak device password" a reason to avoid passkeys, when those users presumably have weak service passwords as well?
But that argument doesn't address how passkeys somehow make that worse.
Sure, if you don't want your valuable stuff stolen, don't put it on your phone. But that's a problem whether you use passkeys or passwords or passwordless links sent to your email or SMS.
The passkeys design, though, has a number of obvious deficiencies and limitations. It is drastically better than ye olde <input type="password" /> but it's not a good standard.
The other alternative is SRP, but no browser vendor had bothered to do anything about this, so it remains a curiosity implemented on a couple websites (with all JS crypto gotchas, so - no good).
For Google in particular, password/passkey isn't a binary choice(currently). You can fall back to the password sign-in flow if your device doesn't have a passkey.
To compare the risks and benefits, we need to know how often people actually re-use passwords, use 2FA, rely solely on their phone screen lock for access to all their accounts, use biometrics, need account recovery, and so on. That data is the only way to settle the debate (and would allow each person can settle it for themselves, perhaps differently based on their circumstances).
Google has most of this data. They should publish it to back up their claims.
That means that they're literally impossible to back up. If 1Password goes down, or the company stops operating, or anything else like that, your Passkeys are just... gone. Absolutely no way to recover them.
1: of course, a user could still be tricked into adding an attacker's passkey to their account or something
It was obvious from day 0 (to anyone except for Apple and Microsoft) that people do have multiple devices and not all of them are from a single vendor. My only explanation is that they deliberately decided to ignore this aspect, because it wasn't in corporate interests.
They made it significantly easier to lose all the passkeys, because they made it very hard to add multiple passkeys (you literally have to walk/run/drive/fly and grab every different device you have, get it online and register - or get properly locked in with a single vendor and pray they work for you, forever).
Carrying a Yubikey does not work (you can lose it). iCloud/Windows Hello does not work (you can be on a non-Apple/Microsoft device). 1Password is better but still does not really work (you can lose access to your account). They're all SPOFs, and avoiding SPOF was deliberately made hard (you can't easily enroll a "backup" Yubikey that you don't have at hand, and if you have it at hand it's not a backup anymore).
Heck, "official" demo at passkeys.io doesn't even bother to showcase how multiple passkeys are going to be a thing at all, which is an obvious red flag.
That is, not to mention that a growing number of vendors contributed to the crappiness by limiting what kind of authenticators and which platforms one can use (BestBuy, PayPal and so on), contributing to decreased security and increased headaches.
We fixed this on mobile years ago but email is still a goddamn mess. Moral of the story: never get locked in.
And sure, you and I have multiple devices. We're in the minority. Most people just have the one. Without another way in, they're irrevocably fucked.
Agile Bits support kept insisting it was the same as the old native app and people kept complaining about bugs until I stopped following it.
Do you have a different workflow where you use the main app a lot?
With 1password 7 whe safari plug in is more conveniently integrated than the chrome one which is pretty clunkly by comparison, though this is true of other chrome plug ins too. But that's not a big deal as I rarely use chrome anyway, just for google docs which don't need 1password.
See a recent post in the 1Password passkey AMA about this subject: https://old.reddit.com/r/1Password/comments/16to6x7/hey_redd...
Re. your point about 1Password going down: Your passwords and passkeys are all stored locally when they sync to your devices. If 1Password becomes unreachable for any reason, you still have access to everything in your vaults, you just can't sync between devices any more.
Edit: I took the last sentence out, it was childish on my part.
Also (i think) none of them are open source?
Yes, some individual implementers recognize the issue and have "log in with another device" (which is the best option you can have, although still quite clunky), so you can solve the chicken-and-egg problem of logging in on another platform's device to add your another platform's passkeys. But to best of my awareness, this is not a part of any standard or recommendation (it should've been).
And other implementers do the contrary and artificially limit your options so you can't add a portable authenticator with them without some hacking around.
While noble, why? 1Password exports a plaintext file that has all of the credentials in plaintext already.
Not “or”. Passcodes don’t provide availability, so they are not providing security.
This is undergrad-level stuff.
I still think the real reason is lock-in, but I could imagine this is their official justification.
Because you can export plain-text passwords just fine, and they give you exactly the same access as a PassKey does.
In other words, if a website doesn't like that their passkeys can be exported, they can block KeePassXC.
Temporarily, i guess? Since it's not stored in an open format?
Is this not bound to some sort of "Secure Enclave" or whatever, and won't survive a reinstall / restore / etc. ?
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-...
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://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.
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://news.ycombinator.com/item?id=37833390
Scenarios dealing with the loss of Passkeys:
The scenarios for dealing with the loss of Passkeys are effectively the same as dealing with the loss of your Password Manager (if you use one) or otherwise stored passwords.
Dealing with the loss of all your devices that use Passkeys If you manage to lose access to all your devices that are used to authenticate via Passkeys (e.g., a house fire), then there are two main outcomes: either you have your Passkeys synchronized to a cloud provider or other external entity that still has a copy of all your Passkeys, or you do not. If you do not have a backup of all your Passkeys, they are gone, and you will need to fall back to account recovery for each affected account. If you have a backup of your Passkeys, you would need to regain access to it on a new device and then synchronize the Passkeys to it and use them as normal.
Dealing with the loss of your accounts that synchronize and store Passkeys If you use a synchronization service attached to an account, it is possible that the account can be deleted or access to it otherwise lost. In this event, you would most likely still have a working copy of your Passkeys on your devices, and depending on whether or not you can export them or reconfigure synchronization with a new account, you would be able to add them to a new account, effectively creating a new account to store and synchronize your Passkeys.
Dealing with the loss of all your Passkeys
If your Passkey account is not only deleted but also tells all your devices to delete the Passkeys, or you lose all your devices and the accounts are deleted due to inactivity then you are basically in the same situation as having lost all your devices and not having a backup. You will need to fall back to account recovery for each affected account.
That said, what you describe is easily doable in other forms. For hardware tokens, you can have a spare Yubikey that's authorized on your accounts and keep that in a fire safe with its unlock PIN. For something like 1Password, you can print out a recovery kit [1] with the secret key and unlock password.
Agreed, I'm just not willing to endorse their use until there are robust recovery and remediation processes.
> For something like 1Password, you can print out a recovery kit [1] with the secret key and unlock password.
Yeah, this is what I want Google/Appleto provide as it is robust to both user incapacity and provider refusal-of-service.
They seem ripe for corporate use where ransomware and phishing are common threats and IT can manage account resets by walking over to their desk.
The idea that printing a backup is easy and an option for many people is often not the case.
Fair enough, but that is an argument for multiple durable recovery and remediation solutions, which few of the current providers have.
For all of its many weaknesses, a password has that one major advantage over all the other authentication methods, and unless a new method provides a similar advantage, most people will keep using a password, just like they did even with the appearance of private keys, biometrics, USB tokens, SMS or TOTP.
I go out on a limb and say one smartphone usually - that is at heightened risk of getting stolen. With passwords, the person would probably just pick something they can remember in case the phone gets stolen. With passkeys, what should they do?
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.
This is a privilege I currently enjoy right now, and one I am not really eager to give up.
Ecosystem lockin is not how we make a new technology like this successful. And all players in the game understand that.
Watching https://github.com/keepassxreboot/keepassxc/issues/1870 with baited breath... :)
Firefox on Desktop tells me to "touch my security key". Not sure how that works. Firefox Android gives me a few hardware options to store my passkey to. Chrome Desktop asks me to enable Bluetooth. Chrome Android asks which Google Account to use.
For every account I have a hardware key for, there are 3 hardware keys associated with that account - 2 on-site, 1 off-site.
By count of sites, most sites don't appear to take security that seriously so anything more than a password is off the cards, but the big ones - the ones that actually matter; email, cloud, etc. should all be able to be secured.
I suppose every time one makes an account one can register the two on-site keys, and then rotate one of your on-site key to off-site and take the off-site key home with you, and then finally register it.
Maybe I should get a third key...
Sounds paranoid / crazy - but I have 0 anxiety about being locked out of an account that matters.
They strongly want to lock you in to their own authentication platforms (iCloud Keychain, Windows Hello, 1Password*), that's why they don't want to address this.
It's impossible they're not aware about those issues. Anyone with a brain and some technical expertise would come up with those questions in an evening or two, and Passkeys were worked on for months. To best of my awareness, there is no official acknowledgement (support replies "no, you can't do this" doesn't count, that's just restating facts, not acknowledging an issue).
*) Ok, 1Password says they're all about user freedoms and that it's up to user to decide where they store their passkeys - but that's what they say, not what they do. What they do is indistinguishable from Apple and Microsoft.
See the section titled "Recovery security" in this article:
https://support.apple.com/en-us/102195
Relevant excerpt for those too lazy to click through:
"However, it's also important that passkeys be recoverable even in the event that all associated devices are lost. Passkeys can be recovered through iCloud keychain escrow, which is also protected against brute-force attacks, even by Apple."
Also, I'm pretty sure if Apple decides to block your iCloud account, you're most likely SOL.
Passkeys make it more likely that you’ll have to resort to account recovery, because it’s explicitly easier to lose passkey access than a password access (assuming that all platforms that implement passkeys implement password management as well, and that every password manager allows “export” by showing password to a naked eye).
One can write a copy of their password in a notebook and use it from anything with a keyboard and network connection. This mechanism is built in.
Passkeys are explicitly worse in this regard, as they don’t address export at all. Some implementations may be at par, but the overall spec is strictly worse, as it fails to address number of obvious issues.
Talk about victim blaming. Google and other companies introduce policies that make total identity lockout both easier and more problematic. Instead of investing in customer service to deal with this issue, the customer needs to "have a plan". What a crazy coincidence that this policy increases Google's profitability by decreasing support.
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.
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.
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.
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.
1. Advanced protection doesn't yet support passkeys. You must keep U2F in place for now. 2. If you have a U2F key configured on your account, Google will prompt you to use it as a passkey before telling you that it's not a passkey and you must login with your password. The net result is that anyone using phishing resistant MFA loses the ability to have their MFA step "remembered" on a device because Google will always prompt for the U2F factor before the password.
This aside, I've been doing a lot of testing with FIDO2 flows using security keys and passkeys across device types and platforms in preparation to roll out passwordless via Okta with a couple of smaller clients. Overall, I love the authentication flow, but there are a lot of gotchas to keep in mind. We've spent a considerable amount of time mapping out the happy path, creating onboarding resources, and documenting business continuity scenarios. The personal use case is actually more of a challenge in some ways, because you need to think about each service rather than just one IdP.
FYI, the easy path right now if you need to support multiple environments is to invest in 1Password or another password manager that supports passkeys. This provides the most consistent user experience and works across most platforms, though we're still having trouble with Android 14.
We're sticking to hardware keys for highly privileged accounts, so admins get a pair of FIDO2 keys. Everyone else gets one Yubikey, which serves as a backup if they lose access to their devices or need to login on an untrusted device. Android is also a problem here. Even in 14, it doesn't seem to support passwordless FIDO2 flows.
Why would they? When Passkeys provide another opportunity for Google to lock-in their customers.
Google has been a big proponent of FIDO, having been an early adopter of U2F in Chrome and leveraging it for advanced protection. More recently, they have extended Chrome support to FIDO2/passkeys and made this move to make it the favored means of authentication for Google accounts.
Given that strategy, it’s a bit of a head scratcher to see Android lagging behind its desktop and mobile competitors. Why stick your mobile customers with second class support for the passwordless technologies you’re pushing everywhere else?!
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.
Anything that Google controls you have absolutely no way to get in contact to resolve issues. This is already a problem with all of their products. Locking all of your access behind a Google controlled door is just setting yourself up for a future nightmare.
For example, it is completely valid to say I genuinely do not know my 1000 long multiple special character password; it could be on a piece of paper, in a file encrypted with multiple layers. Essentially, there is no foolproof way to ever prove whether I know a given password, or not, especially if the password is only ever in my head (assuming the plaintext version is never logged, all you would ever have as 'proof' is a hash to compare it to).
Passkeys make it so that, I imagine, there is an element of 'proof' at all times; your face, fingerprints (which in some countries you are required by law to provide), I can't disprove I "own" my fingers so that element is always there, and you can be compelled to provide your fingerprints at any time for any reason - with a password, it is impossible to know whether I know a password.
In that sense, a password is far, far, far stronger than any other method of authentication.
Take a scenario: Mr Police wants access to your phone, it's protected only by your fingerprint, pretty easy to gain access. Now do the same but with a password that's sufficiently complex, written on a now shredded piece of paper, and there is genuine plausible deniability.
I imagine in a lot of cases this is extremely important and passkeys will be shunned altogether.
>We’ve found that one of the most immediate benefits of passkeys is that they spare people the headache of remembering all those numbers and special characters in passwords.
So they aren't considering at all how easy is the autofill password feature with a password manager (that they even have built in Chrome/Android).
Passwords are a nightmare for both users and service providers for a variety of reasons. And password autofill is a bandaid at best.
If I had a quarter for the number of times I've personally used a password manager to auto generate a password which was then either reject by the website due to absurd password complexity requirements, or had the password seemingly accepted but in reality silently truncated behind the scenes....
I know you're commenting on a Google blog post, but FWIW Apple acknowledges password managers/autofill in the "Deploy passkeys at work" talk from WWDC 2023:
"Let’s look at a side-by-side comparison of the experience of creating a new password versus creating a new passkey. As you can see, creating a passkey is significantly faster and easier than creating a password. Just Face ID and you’re done. Now that we’ve looked at creation, let’s compare the experience of signing back in. With a password, the user has to remember and type in the password. With a passkey, they just Face ID and they’re done. A password manager can help improve the experience, but even the best password manager can’t compete with the user experience of passkeys. You are used to having to make tradeoffs between better security and a better user experience. Passkeys achieve something rare: great security and a great user experience."
Source: https://developer.apple.com/videos/play/wwdc2023/10263/?time...
Passkeys might (or might not) have other benefits, but ease of use is entirely a question of cherry-picking.
The significantly better passkey sign-in UX that I’m talking about exists on all major platforms. And the UX is handled by browser and operating system APIs, so it’s not really something the app or website can mess up.
Also, any solution that still involves password-based login prompts would be worse than passkeys because passwords are still shared secrets, and password hashes would remain juicy targets for attackers in server breaches.
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.
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.
“But it’s safe in the Google/Apple/Microsoft cloud” is not an acceptable answer.
They've been accidentally enabling it for nearly a month if not more. And the UX has been infinitely confusing. I've been using 2fa for a decade (not an exaggeration, an understatement). I've been using u2f since the first month it was available and FUCK Google for this blog post.
A month ago I logged in and tried to check on my security tokens. Their UI was silently upconverting them. Without telling me. And the flow made it look like it was just deleting them. Hours later I realize it had re-enrolled them AND IT LOST THE DESCRIPTION I GAVE TO THEM. To be clear, it trashedt the decription I gave them during (what I didn't know at the time) was re-enrolling them as passkeys, because i sure as hell wansnt in the passkeys area. So not only did I inadvertently change them, they're now indistinguishable and unidentifiable to me. So if I want to ensure my primary and backup tokens are enrolled properly , I have to do it all over again, with all of them in my possession
Seriously, I have defended google against all sort of claims with respect to their 2FA and they can absolutely get up their own after what they pulled, and now this blog post.
Do some god damn basic (user) testing FFS. I would literally pay $1000usd right this second to scream at the people who green-lit and implemented this. And another $1000usd to ensure to people here that I know DAMN WELL what I'm talking about here. It's not like I don't have video evidence of exactly what I'm stating here on an unlisted YT video tweeted at Google Security.
Edit2: to be VERY clear, I have a video I reviewed, just now, that shows me trying to enroll an existing Security Token with a description, it disappearing, it then appearing as a Passkey with no description.
(I ask mainly so that I can watch out for whatever bit you. On the face of it, the blog post seems pretty anodyne. The screenshot shows that it’s optional, not forced, since there’s a "not now" button.)
EDIT: oh, they auto converted your security keys to passkeys? With no option to roll back? Yeah, that’s not great. https://support.google.com/accounts/answer/6103523?hl=en&co=...
As far as I call tell, my physical yubikeys that went though this process have continued working with the same ultimate user experience, thank God. Minus the 45 minutes where I thought I was locking myself out due to them disappearing from the ending landing page that listed my enrolled Security Tokens, due to the buggy upgrade UX flow or the fact that I have no way of confirming which of my primary/secondary tokens are now actually enrolled because it trashed my descriptions during this upgrade.
I am actually infinitely sorry at the times I openly questioned user error when people expressed Kafka-esque nightmares wrt to google auth. I'm actually quite annoyed at myself for ever doubting them.
Passkey 2FA: unlock your phone and the passkey on your phone can log you in.
Traditional 2FA: remember a password AND unlock your phone (where your TOTP is stored) and you can login
Method Convenience Security
Password only: 4/10 2/10
Passkey 2FA: 9/10 8/10
Traditional 2FA: 6/10 9/10
That being said passkeys win if you also take convenience into account. I've updated my original comment with convenience scores to reflect that.
Nobody is a strong number, why?
I don't want to use biometrics for logging in to my SSH terminal. I dislike having to use my phone for authentication methods.
I go many places without my phone. Even tempted to gon on holiday without it. Maybe I'm just one of the few who actually enjoys turning it off when coding, developing or whatever.
No one's explained it to me. Other than "DoNT UsE PaSsWoRds", that's not my fault.
Why should I have to learn it, why should my mother have to learn it. This an a totally thrown in your face situation.
Theres plenty of posts in this thread explaining to why its a flawed design. You tell me why not.
Most, if not all (I've not read every post) of the 'flaws' mentioned generally exist in computer security; for example, no one is impervious to a thug and a weapon. The implementation is as simple as generating a key pair; the private key is stored in a secure enclave, either on device or in a secure location, and the public key is shared with the 3rd party. All services provide some recovery method upfront, clearly stating the importance of a backup. There is only so much they can do before you accept the responsibility for managing your security and privacy online. Resorting to "won't someone think of the children" doesn't help either. My mother, who is 74, has no problem with passkeys.
Is it perfect? No. There are 'better' competing standards, but they don't have anywhere near the consensus of the broader security field. Is it better than the current status quo? Definitely. Public key cryptography is significantly better than username/password combinations, even with TOTP or HTOP second factors, though ultimately, it will be a while before they disappear.
Also even with traditional 2FA, TOTP can be phished. See https://github.com/kgretzky/evilginx2
WebAuthn almost entirely eliminates phishing risk (at least with respect to credential harvesting), and Passkeys are a really nice, clean UX for using WebAuthn.
An implication of that is passkeys let you use the same authenticators across multiple services safely. Instead of keeping track of unique passwords across all those services (or worse, reusing passwords), you can just have a passkey-registered phone and one or two Yubikeys for backups/convenience. You'd be a very hard target for account compromise. That setup is highly phishing-resistant and immune to credential-stuffing, without the cognitive load of passwords.
The reason being is the secret used to authenticate you is non-portable (since it's based on asymmetric crypto, it doesn't need to be shared). On the other hand, portable credentials, like TOTP/HOTP code AND passwords are responsible for almost all compromise today.
Bearer token based authentication will always be inferior to FIDO/U2F - it's not even the same ballgame.
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.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.
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.
... that is a statement that some people will find convenient and some people will find terrifying. As much as I'm excited for the convenience, this is my primary concern: how easy is it for a stranger to unlock your phone? Most people intentionally keep their phones easy to unlock because they're doing that dozens of times a day.
Biometric data is only stored on your device. Logging into an app or website with a passkey just uses bog standard asymmetric crypto (public/private keypair). Also a lot of thought was put into the WebAuthn standard (an open standard) to make sure it can't be used as a tracking vector.
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.
You have to meet people where they are at.
per some support document (sorry lost the link), by default, Android users will have passkeys synced to their google account. So first of all, this is a lock-in play on Google's part. The passkey FAQ only mentions iCloud, so second of all it's a duopoly reinforcement. (This really needed Apple to first release passkey support.)
Beyond that, there are so very many ifs, ands, and buts around recovery and third party device usage that a typical user can't really keep it straight.
It's more convenient ... until it isn't.
I thought it was the same as security keys, which are like digital, but still physical, keys. They are awesome, one just has to have two and you are set. Passkeys tied to a cloud service or device like a smartphone are a terrible alternative (comparatively), from privacy and security (as in not get locked out) standpoints. At least they use fido2 so pushing for passkeys add support for security keys at the same time..
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.
I disable all kinds of biometrics from my devices when traveling for this reason specifically. Passwords in my password manager aren't the whole password. There's another component in my head that I won't (and, more importantly, cannot be compelled to) disclose.
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.
The only way I can think of to explain this to a non-techie is “your account is now tied to your [singular] device, and neither a password nor a replacement device (like a new sim card) will let you in.”
So, it really does remove both factors from 2FA, and the logical conclusion holds.
Either anyone can get into an account with a “I broke my phone” social engineering attack, or the account owner cannot reliably authenticate.
Something you know: Your pin
Something you are: Your FaceID/Fingerprint
So, when you are holding your dead phone, you realize that there is nothing you know or have that will let you into the account (and there never was such a thing).
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?
Hopefully Tor Browser can turn on security.webauth.webauthn in a safe way before sites force it to be used, too.
The only annoying thing about this setup is having to manually add each key to each new passkey-enabled account I have.
I like the whole idea of syncing a single key. But the whole chain must be owned by me and me alone.
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).
Note that i said "all your devices" so the cloud backup you dream of will also be inaccessible because I can't authenticate to that either.
And I know about backups... what about your average user who is likely to own a single phone and no other device? They lose access to everything if they drop it in the toilet?
https://support.apple.com/en-gb/HT212360
Account recovery contact
> Yes, you can continue to log in using your traditional log in [sic] method, which in most cases would be using your username and password.
My desktop doesn't have a camera, fingerprint reader or touch screen...
If you registered, say, a Yubikey, many moons ago, on your Google account. Is this Yubikey now automagically going to become a "passkey"?
Or will you have to choose between logging in with your Yubikey or with a new passkey? (say something Google controls, in your phone for example)
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
2. Most services let you add more than one passkey. Using 1Password, or using iCloud Keychain or similar, you can sync passkeys between devices. Even with iCloud Keychain, if you have only one device, you're given a recovery code that can bootstrap the entire system from zero if your only device is stolen.
I’m glad I only keep my Google account around for historical purposes and YouTube.
https://www.stavros.io/posts/clearing-up-some-passkeys-misco...
https://docs.google.com/document/d/1eBjQDWkbqXJSL4GRrAdTUcAx...
TL;DR:
============
Major insights in this paper:
Passkeys level up security, and while Passkeys make some tradeoffs concerning security vs. usability, they do not introduce any new attacks and make many existing attacks much harder or impossible (e.g. brute forcing attacks or credential stuffing) Passkeys will bypass the hurdle of getting people to start using password managers, and will likely result in the widespread use of biometrics to secure Passkeys Passkeys can potentially make account sharing harder once attestation is supported, something a lot of service vendors are in favor of. Passkeys are also easier to deploy and reliable due to optional device synchronization, which should reduce the need for account recoveries and lower support costs Passkey client support in both software and secure hardware tokens is widespread and available now on most platforms, browsers and most third-party password managers Passkeys are being deployed by major vendors (e.g. Google https://blog.google/technology/safety-security/passkeys-defa...)
============
Conclusion:
No new significant risks or attacks are introduced from the threat model perspective. From a usability and reliability perspective, Passkeys are infinitely better than passwords. Finally, from a support perspective, chances are that if you currently use a system to manage your passwords, it already has Passkey support. For high-security applications, you can also choose to use your hardware token.
Web applications and websites are becoming increasingly critical to everyday life (banking, healthcare, education, shopping, etc.). We must improve security across the board and get rid of old and insecure things like usernames and passwords. The world has also changed, and virtually everyone has a smartphone, something unimaginable even ten years ago, let alone twenty.
Simply put, in every situation where you use a password, you should upgrade to a Passkey if possible.
The problem with Passkeys is not that it's not possible, but that the standard is lacking any guidelines for things like this. There is no interoperability in general, it's accidental at best. And this is concerning.
Same goes for a lot of aspects that are attributed to Passkeys as "this can be solved this way", but in no way documented (in a way promoted by any major vendor), let alone standardized, let alone be required by some standard to be "Passkey-compliant".
In short, I think this can be summarized as "Passkeys lack proper standardized best practices document, encouraged by renown parties".
It is wrong to hand-wave at some specific implementation and say that because that implementation is okay, the whole standard is fine.
----
Also, you may consider adding another concern, "authenticator must be physically present to be registered". This limits ability to add new devices (which was not an issue with other systems, such as TLS client certificates).
In simple terms, one cannot add a Yubikey that lies in a safe in a secure vault under a mountain, they must have it at hand, when they're online.
This Passkeys/Webauthn limitation leads to people having significantly greater difficulty adding backup options, contributing to higher chances of getting locked out (temporarily or permanently) that it could've been, would Passkeys be designed differently.
----
Both things don't explicitly introduce any new weaknesses, compared to passwords. But the problem with Passkeys is that they're here to stay for a long while. So a push towards "you must fix this before it's too late" petitioning collective FAANG (who are the only entities that were able to push asymmetric crypto to web, no grassroots movement was able to do this - many attempts were made and all had died in oblivion) is extremely important.
like biometric + one time passcode?
The biggest mistake that the passkeys movement did is try to make it sound more marketable at the cost of oversimplification.
First up, these aren’t really “no password” mechanisms. They’re closer to ssh certificates. You need to authenticate through some other mechanism and then agree to do the equivalent of creating and installing ssh certificates on your device.
The ssh certificates get synchronized across your devices securely by your cloud provider. But they can never serve as the primary authentication mechanism - that will still have to be a traditional authentication mechanism.
It’s mildly infuriating that someone decided to take this simple idea and confuse the fuck out of everyone by positioning it as some alternative to a password based authentication mechanism. Obviously everyone is going to come and ask a ton of questions about how a mechanism without any passwords should work. And then the responses further confuse everyone because they don’t want to admit “no actually you still need passwords”
/rant
> But they can never serve as the primary authentication mechanism - that will still have to be a traditional authentication mechanism.
Why not?
Think about the failure mechanisms. What government ID? Why might the face change? Etc. Even if these sound like outliers, at scale essentially anything will happen.
Consider a shared computer in a university laboratory or at a public library. Or maybe an iPad that is shared by a family.
As a service provider, you usually can not assume that someone using your service will log in with a dedicated device or with a device that has their primary google or apple accounts setup on it. (Some rare exceptions might exist).
I don’t think anyone wants to deal with customer support problems of “oh, I’m stuck in a different country when on a holiday and my phone got stolen, can you please recreate this key exchange process for me on this untrusted device logged in from public wifi at a coffee shop?”
Like with ssh certificates, you create more problems than you solve if you use passkeys as the primary authentication mechanism.
To answer your question, yes it would be primary authentication if you used it that way. But no sane person would. Hopefully.
If the result is that users are not using passwords, then aren't passkeys an alternative to passwords?
Case in point, creating a new google account as a 13yo. If you don’t have a password and you lose your one device, you lose everything. This isn’t hypothetical; it just happened to a family friend.
Not sure why the discussion got booted to the bottom of the thread. Looks like it’s a lesson not to label your comment a rant.
It reflects that the mechanism is a way to securely store some identity related information. It is not a mechanism to establish that identity.
The value proposition is still obvious: You need to establish your identity once, and then you can securely save it and share it across devices and avoid having to reestablish your identity every time.
It also removes the “password” confusion entirely. Establishing identity could be through a fingerprint or verifying a government issued Id card in person etc.
The name also correctly reflects what it is doing while still sounding marketable to non technical users. The mental model that a non technical user will build more closely reflects what is actually happening - which is always helpful to build a good user experience.
Give me an implementation I can self-host, without Google, Apple, etc. having effective control (including claws in my relevant software supply chain) and with an easy user experience, where I can maintain secure backups (on my own infrastructure, thank you) and smooth transition to future devices, and ideally, if needed, securely export root keys (cause if I don't control them then someone else owns them), and maybe I'll be interested.
In the meantime plain old high-entropy passwords with a good manager gives me all those features and a simplicity that's hard to beat.
In my 30+ years of computing I've suffered more harm from failures of other companies than I have from any failure of my own diligence. The whole lesson learned is to reduce trust in them and, maybe I'm wrong, but everything I've read about passkeys and the like seems to put me at liberty of the companies developing and pushing the implementations of them down my throat. It will take a lot of trust before I give up my ability to copy/paste my credentials.
Firefox has a build that supports passkeys, and I believe 1Password has an extension for Firefox that supports passkeys.
If "all you need" for Passkey support is a custom extension, it should be straightforward to create one that does whatever you want (including storing your private keys in plain text in your home directory, which many argue is a bad idea, but that's not the point).
Is 1Password a magically signed and authorized extension, or can any Joe pound out a quick hack using JS and Firefox?
I appreciate that the client and credential management should be sophisticated and secure, etc. But the API is the API, it's supposed to be an open API, and I can understand Chrome, Safari, and Edge, being closed source browsers, may or may not allow anyone to hack their own keystore regimen.
But, I don't think Firefox is doing that (unless the 1Password extension is magically blessed by Firefox somehow). At a minimum, you can always go the source, and rebuild Firefox to do what you want. Involved, to be sure, but possible.
> Passkeys are a new way to sign in to apps and websites. They’re both easier to use and more secure than passwords, so users no longer need to rely on the names of pets, birthdays or the infamous “password123.” Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN. And, unlike passwords, passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes.
I HATE paragraphs like this. It's as if you're purposely obfuscating what they really are.
HN: Yeah, but what if disaster scenario?
A1: If you're authenticating to Google because your $DAYJOB mandates it, contact your Enterprise Administrator. As part of their multi-gazillion deal with the dark side, I'm sure there is some kind of support for a recovery mechanism, and if there isn't: yeah paid holiday until they figure it out!
A2: If you rely on Google for personal-slash-small-business reasons, please refer to the previous writing on the wall, and accept that all is probably lost...