Passkey Implementation: Misconceptions, pitfalls and unknown unknowns(corbado.com)
corbado.com
Passkey Implementation: Misconceptions, pitfalls and unknown unknowns
https://www.corbado.com/blog/passkey-implementation-pitfalls-misconceptions-unknowns
189 comments
I would if I could use them. But no, Windows refuses to connect to Android, it times out. Same thing on Linux. Android itself? Your encrypted data is locked on this device, and following the help article doesn't do anything. Three different platforms, none with functional passkey support. Awesome UX. My grandparents would've thrown their phone out of the window by now if a website they need to visit requires passkeys. And no, before you ask, Bluetooth is working just fine. I regularly send files between my computers and my phone via Bluetooth, that's not the problem.
https://passkeys.directory/ indicates that plenty of relying parties have implemented support for passkeys and I’ve yet to hear about any efforts taking 100 sprints (if TFA is to be believed that it’s 100x harder than a single sprint’s worth of work). Indeed a rather lazy exaggeration.
> have implemented support for passkeys
Why do you assume they have also implemented correctly for all cases?
Why do you assume they have also implemented correctly for all cases?
Our blog is full of examples of implementation analysis, and we have not encountered one implementation that is bug-free or leverages the complete toolset (same for us: we have just identified a bug in our implementation that relates to WebKit's user-gesture requirements on iOS versions before 17.4). That's not because of them being sloppy, it's just very difficult to get it right; that's exactly the point. For example, Uber and Amazon both did not get it right (until today). Of course, it is possible to implement passkeys without any external resources, and to be honest, we appreciate any effort, be it open-source, tutorials, or commercial applications. If you have been on an authentication team in a big B2C company and truly want to retain the trust of your customers, then you appreciate passkeys immediately as they solve one of the biggest problems... So we are also happy to see a half-good implementation as it improves security.
is it honestly better than TOTP in terms of security, ease of implementing "correctly*, and convenience?
> So please don't put passkeys in the too-hard basket after reading this article. Users love them, and they are going to be ubiquitous very soon.
It's funny but that's almost exactly what #15 in the article even eventually states that you can't ignore passkeys because users love them and they will be ubiquitous very soon and also that the article isn't meant to alarmist "it's all too hard" but cautionary "have you considered x?" but they knew writing it will sound alarmist (because of course they wrote some parts of it in an alarmist tone for clickbait/salesbait). Of course #15 ends with trying to sell their product.
It's funny but that's almost exactly what #15 in the article even eventually states that you can't ignore passkeys because users love them and they will be ubiquitous very soon and also that the article isn't meant to alarmist "it's all too hard" but cautionary "have you considered x?" but they knew writing it will sound alarmist (because of course they wrote some parts of it in an alarmist tone for clickbait/salesbait). Of course #15 ends with trying to sell their product.
We tried to make the article fun to read. In the end, we could have omitted our hint about our product, but honestly, we have gathered a lot of know-how there for anyone who wants to build passkeys on their own. Our blog and this article are one of the better resources to start with, and even without it, our product offering is obvious. But: We are very commited to help anyone implementing passkeys.
Why not use Keycloak, then add OIDC to your Flask app, in 4h?
I think Keycloak is always the wrong choice if you’re looking to simplify your authentication stack
This matches our experience too. Out of curiosity, do you use email as the identifier? And if so, do you verify during the initial signup flow?
We use email or phone number as the identifier. We recommend verifying on sign-up, but it is actually a configuration option. We have other customers who want to request OTP on the next sign-in. Not validating the identifier on sign-up comes with a long list of potential security/ux race conditions further down the chain (especially if you also support social logins). What is your approach?
Yes, we use email as the identifier, and yes we verify on signup.
We certainly aren't exceptional, and I expect that implementation will become easier as passkeys become more popular, and browser/device APIs develop. So hopefully later adopters will find it even easier than we did.
We certainly aren't exceptional, and I expect that implementation will become easier as passkeys become more popular, and browser/device APIs develop. So hopefully later adopters will find it even easier than we did.
So not a weekend project but not crazy hard. Probably still rules it out for my hobby apps.
A weekend project is probably fine -- I wrote a Passkey-based SAML IdP in a weekend (re-using the SAML IdP from a different project). It's written in Tcl.
The hardest part of dealing with the Passkeys was remembering to read the whole specification before implementing it -- I spent a lot of time parsing their CBOR/COSE-based specification so that I could get the public key before "discovering" that there was a method for that defined by the specification.
The hardest part of dealing with the Passkeys was remembering to read the whole specification before implementing it -- I spent a lot of time parsing their CBOR/COSE-based specification so that I could get the public key before "discovering" that there was a method for that defined by the specification.
You must know something about the domain. One time I spent several weeks falling to implement a minimal SAML relying party. Not even an idp. I found the spec to be impenetrable without a baseline understanding of the jargon. All the definitions seemed to be circular like when I end up on a Wikipedia article for some fancy math concept.
It's been a while, but I read through the OASIS spec for SAML for my implementation. There is a lot of yak shaving and I also had to implement XML Digital Signatures (XML-DS), and XML Canonicalization (C14N), but overall I don't think it took too long for something that worked, and was a library so I could just give it a key (or PKCS#11 handle) an identity and get back a SAML Assertion, which is fundamentally what I was after. It's available for viewing here [0].
[0] https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...
[0] https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...
Implementing SAML from scratch should take a long time - it's one of the most footgun-prone designs I've ever seen.
'Yak shaving' as a phrase is new to me, and I love it.
Even though I work at a company that also supplies passkeys support to its customers, I feel it is worth for people to have a read of (1). The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. Oh, and if a customer ever wants to change the domain name for branding related stuff, is also where the fun starts.
My 2 cents are that passwords/2fa, passkeys, federation and maybe soon verifiable credentials are concepts that will work for a long time in parallel. So, if you ever choose a system that does the "identity/authentication" plumbing work for you, I think you should focus solutions that are open source and allow you to mix and match the different concepts. IMO this applies to b2c and b2b alike ;-)
[1] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
My 2 cents are that passwords/2fa, passkeys, federation and maybe soon verifiable credentials are concepts that will work for a long time in parallel. So, if you ever choose a system that does the "identity/authentication" plumbing work for you, I think you should focus solutions that are open source and allow you to mix and match the different concepts. IMO this applies to b2c and b2b alike ;-)
[1] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
> The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material.
I'm struggling a little bit with the use case here. Yubikeys and other HSMs also don't allow you to export the key material, and sites should have account recovery flows for people who lose access to their devices / HSMs / password manager databases.
Is it merely a convenience thing, or is there an actual problem that can only be solved by allowing key material export?
I'm struggling a little bit with the use case here. Yubikeys and other HSMs also don't allow you to export the key material, and sites should have account recovery flows for people who lose access to their devices / HSMs / password manager databases.
Is it merely a convenience thing, or is there an actual problem that can only be solved by allowing key material export?
Yubikeys have a single master private key, and derive site-specific keys from that. It makes sense in this model not to allow key export. On the other hand, if you have 100 sites you log in to, you can use one key for everything. If you get a new computer, you can just carry on using the same key. If you lose or damage your key, admittedly things get harder.
Passkeys are defined by at least one authority as "resident keys" in the sense that you have one key stored for each site. If you have more than one computer, or your old one breaks and you buy a new computer, you somehow have to get your 100 keys from A to B (and possibly keep them in sync). You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place.
Even enterprise HSMs can do this to some extent with key-wrapping. (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.)
Personally, the way I'd like key-based authentication to work is something like how SSH keys work currently, where people who know what they're doing can set things up in a way that works efficiently for them. You can choose yourself whether you want 1:n or m:1 or m:n relationships between your keys and your sites and how to manage them.
Passkeys are defined by at least one authority as "resident keys" in the sense that you have one key stored for each site. If you have more than one computer, or your old one breaks and you buy a new computer, you somehow have to get your 100 keys from A to B (and possibly keep them in sync). You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place.
Even enterprise HSMs can do this to some extent with key-wrapping. (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.)
Personally, the way I'd like key-based authentication to work is something like how SSH keys work currently, where people who know what they're doing can set things up in a way that works efficiently for them. You can choose yourself whether you want 1:n or m:1 or m:n relationships between your keys and your sites and how to manage them.
Because the audience for passkeys is non-technical we are ending up with paternalistic user-hostile implementations that make all the problems the user's.
I don't want to be locked into a platform. I don't want to have to shoulder the burden of making sure I enroll new hardware tokens every few years because I can't just backup / restore the key material in a sensible manner. I don't want one more thing to worry about or pay somebody else for.
I have been using a password manager since 2002. I intend to keep using some kind of password management (password vault, tokens, passkeys, etc) for the rest of my life. I'm worried that the ergonomics of passkeys are very bad and not well thought-out for the long term.
I'm worried the market is skewing in that direction and I will be forced into passkeys and away from passwords to retain access to basic services. I don't really want to be a vassal of a feudal platform lord for my personal password management needs.
Having said all that, you said:
> If you lose or damage your key, admittedly things get harder.
That's worrisome to me. I think the implementers are thinking about it from an "if things go wrong" perspective. I come at things from a "let's have contingencies for when things go wrong".
For what passkeys do I think end users are ill served by the default mode being either user-hostile or feudal.
> Even enterprise HSMs can do this to some extent with key-wrapping.
This. I feel like passkeys are taking the lifecycle model kinds of questions that HSM buyers have to make and thrusting them upon non-technical end users.
Businesses might purchase an HSM with key-wrapped export or backup functionality because they need fault tolerance, disaster recover, and support for key lifetimes that exceed individual hardware component lifetimes. End users don't seem to be getting this choice with passkeys.
It feels like the people implementing passkeys haven't thought about handling those kinds of considerations in a way that provides convenience and security to end users. The answers I see all amount to "Enroll multiple keys for each site. Handle it yourself manually. End users are too stupid to be trusted to handle this well. Tough luck for you if you don't like this beautiful garden we've built for you."
I don't want to be locked into a platform. I don't want to have to shoulder the burden of making sure I enroll new hardware tokens every few years because I can't just backup / restore the key material in a sensible manner. I don't want one more thing to worry about or pay somebody else for.
I have been using a password manager since 2002. I intend to keep using some kind of password management (password vault, tokens, passkeys, etc) for the rest of my life. I'm worried that the ergonomics of passkeys are very bad and not well thought-out for the long term.
I'm worried the market is skewing in that direction and I will be forced into passkeys and away from passwords to retain access to basic services. I don't really want to be a vassal of a feudal platform lord for my personal password management needs.
Having said all that, you said:
> If you lose or damage your key, admittedly things get harder.
That's worrisome to me. I think the implementers are thinking about it from an "if things go wrong" perspective. I come at things from a "let's have contingencies for when things go wrong".
For what passkeys do I think end users are ill served by the default mode being either user-hostile or feudal.
> Even enterprise HSMs can do this to some extent with key-wrapping.
This. I feel like passkeys are taking the lifecycle model kinds of questions that HSM buyers have to make and thrusting them upon non-technical end users.
Businesses might purchase an HSM with key-wrapped export or backup functionality because they need fault tolerance, disaster recover, and support for key lifetimes that exceed individual hardware component lifetimes. End users don't seem to be getting this choice with passkeys.
It feels like the people implementing passkeys haven't thought about handling those kinds of considerations in a way that provides convenience and security to end users. The answers I see all amount to "Enroll multiple keys for each site. Handle it yourself manually. End users are too stupid to be trusted to handle this well. Tough luck for you if you don't like this beautiful garden we've built for you."
If you're already a password manager user, then it sounds like your gripe is "my password manager doesn't support passkeys." That seems either a short-term issue that would be resolved in time, or you need to find a more powerful manager. It seems the browsers allow passkey providers to be pluggable already, as several third-party vaults support passkeys.
So I see your concern as more "I need to find a password/passkey manager that fits my desires" and less "passkeys require being locked into a platform."
So I see your concern as more "I need to find a password/passkey manager that fits my desires" and less "passkeys require being locked into a platform."
I worry that people who think device attestation and not being able to backup passkey data being good things are too close to the driver's seat when it comes to the direction of passkeys. I see a possible future where free and open source passkey implementations won't be usable because relying parties will want to see device attestation.
I would love to use a hardware device in lieu of a password manager. I just need a tolerable backup/restore scenario.
I would love to use a hardware device in lieu of a password manager. I just need a tolerable backup/restore scenario.
Apple is playing consumer advocate here by refusing to support device attestation keys on consumer hardware. With the large market share of the iPhone that's a key wedge that should keep things relatively open on the consumer side, presuming Apple sticks to their ideals here. The biggest advocates for device attestation are doing so for corporate "enterprise environments" and that will likely be a dividing line that corporate networks may require device attestation and consumer devices and applications won't/can't.
"Resident keys" is the solution, not the issue.
With U2F it was hard to track which sites used the key. If I wanted to move to a different physical key, what sites should I update to not need to worry about arbitrary account recovery processes? This is one of many reasons I hate SMS verification and why I didn't use U2F beyond a few high-value sites. But with resident keys there is a list of sites I can walk through to migrate or to keep "in sync" with a spare key. Just like with passwords and OTP. Needing to sync them is an existing problem with passwords and OTP; I'd consider it solved, but even if you don't, I don't see why that's suddenly "consumer-unfriendly."
For the service lock-in concern, the resident aspect makes it easier to migrate. Yes, there might be a way to make it easier still, but when the alternative is a physical key it seems a strange demand. I'm the sort of user that'd use a physical key, though, even if the number of available resident key slots is low at the moment.
(If a site doesn't support more than one passkey, then I wouldn't use passkeys on the site.)
With U2F it was hard to track which sites used the key. If I wanted to move to a different physical key, what sites should I update to not need to worry about arbitrary account recovery processes? This is one of many reasons I hate SMS verification and why I didn't use U2F beyond a few high-value sites. But with resident keys there is a list of sites I can walk through to migrate or to keep "in sync" with a spare key. Just like with passwords and OTP. Needing to sync them is an existing problem with passwords and OTP; I'd consider it solved, but even if you don't, I don't see why that's suddenly "consumer-unfriendly."
For the service lock-in concern, the resident aspect makes it easier to migrate. Yes, there might be a way to make it easier still, but when the alternative is a physical key it seems a strange demand. I'm the sort of user that'd use a physical key, though, even if the number of available resident key slots is low at the moment.
(If a site doesn't support more than one passkey, then I wouldn't use passkeys on the site.)
> You could do this with a third-party cloud service (and pay subscription fees for it), but in this model it seems consumer-unfriendly to me to not allow me just to back up and transfer my own keys, especially when it's not possible on all sites to register more than one passkey in the first place.
I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced. We might disagree with each other on which is more important, but I can certainly see a perspective that disallowing export (for a specific implementation) is more important than convenience.
I'm also not sure to what extent the spec / implementers need to provide functionality to work around the fact that some sites are not implementing passkeys properly. That feels a bit icky.
I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced. We might disagree with each other on which is more important, but I can certainly see a perspective that disallowing export (for a specific implementation) is more important than convenience.
I'm also not sure to what extent the spec / implementers need to provide functionality to work around the fact that some sites are not implementing passkeys properly. That feels a bit icky.
>> I get this, but I think it needs to be acknowledged that export presents a risk and that needs to be balanced.
I see it from the other perspective--not allowing key export is a risk since the user does not have full control of their key and cannot fully manage how it is used.
It is a key and needs to be protected, but not allowing key export / import disrespects the user's choice and freedom and is a perfect recipe for vendor lock-in.
What is the ideal balance between protecting the key and respecting the user's choice and freedom?
I see it from the other perspective--not allowing key export is a risk since the user does not have full control of their key and cannot fully manage how it is used.
It is a key and needs to be protected, but not allowing key export / import disrespects the user's choice and freedom and is a perfect recipe for vendor lock-in.
What is the ideal balance between protecting the key and respecting the user's choice and freedom?
There's risks both ways :)
> What is the ideal balance between protecting the key and respecting the user's choice and freedom?
There's no right answer to this. The eternal struggle of mankind is living with the fact that other people have different value systems and therefore end up making decisions that are consistent with their values but that someone else disagrees with.
This is the classic "do you give the user enough rope to shoot themselves in the foot with?" dilemma. Not being able to do what you want with a key that belongs to you? Bad. Having your key stolen because the systems that look after it explicitly let it be exported? Also bad!
> What is the ideal balance between protecting the key and respecting the user's choice and freedom?
There's no right answer to this. The eternal struggle of mankind is living with the fact that other people have different value systems and therefore end up making decisions that are consistent with their values but that someone else disagrees with.
This is the classic "do you give the user enough rope to shoot themselves in the foot with?" dilemma. Not being able to do what you want with a key that belongs to you? Bad. Having your key stolen because the systems that look after it explicitly let it be exported? Also bad!
> (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.)
Bruh
This is akin to CA/B Forum threatening to ban use of OpenSSL because it has a -nodes flag.
Bruh
This is akin to CA/B Forum threatening to ban use of OpenSSL because it has a -nodes flag.
The difference is yubikeys have been mainly used in enterprise settings where the reset approach is "get IT to assign a new yubikey to your account or boot your old yubikey". Passkeys are aimed at the general consumer who has been a very rare user of the yubikey. Now you're back to trusting every user to physically keep track of their passkeys, rather than trusting a pool of IT admins.
The export is important in case you want to move to a different service or password manager.
In theory, You should be able to add a new passkey to your account, and remove the old one.
Some of the physical security devices even doesn't support exporting private keys. You ask something (encrypt/decrypt/sign) with a mailbox interface and you get the results. Key is never (and can't be) exposed outside of the secure enclave. Said keys are generated in an isolated RNG inside the key, too. So the system is completely self-contained.
I understand the desire of flexibility and convenience, but this is a tradeoff on a slider. Some designs are full-in on security others are not. We should make choices according to that.
Some of the physical security devices even doesn't support exporting private keys. You ask something (encrypt/decrypt/sign) with a mailbox interface and you get the results. Key is never (and can't be) exposed outside of the secure enclave. Said keys are generated in an isolated RNG inside the key, too. So the system is completely self-contained.
I understand the desire of flexibility and convenience, but this is a tradeoff on a slider. Some designs are full-in on security others are not. We should make choices according to that.
It sounds really really inconvenient when you have a lot of accounts on different websites. Imagine login to add new passkey andremove the old passkey for 100 websites (and my password manager already stores much more than 100 accounts).
Yes, I'm aware that it's very inconvenient. I did the same for my TOTP codes because Google Authenticator didn't restore your keys if your devices were different.
So, I had to manually migrate TOTP secrets from 30+ accounts back then, by removing 2FA, and re-enabling it with a new secret.
As I said before, it's a sliding scale trading off between security and convenience. Select your poison and its dosage, and do your own cocktail.
Or, providers will develop a workflow to migrate or add new devices easily. Like "validate on another validated device to add this new passkey" scheme.
So, I had to manually migrate TOTP secrets from 30+ accounts back then, by removing 2FA, and re-enabling it with a new secret.
As I said before, it's a sliding scale trading off between security and convenience. Select your poison and its dosage, and do your own cocktail.
Or, providers will develop a workflow to migrate or add new devices easily. Like "validate on another validated device to add this new passkey" scheme.
I know, I use yubikeys for all my important stuff.
But I view passkeys as more for the low-hanging fruit. All the crap accounts that every webshop and news outlet makes you create these days. I have 500+ accounts in my current password manager. Not being able to migrate that away to another service would be a nightmare. Being locked in with a big tech company would be too.
What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile.
Also, if software password managers don't offer export options it doesn't mean it's impossible to export. They just don't want to make it possible. But an adversary could. The only way to really make it impossible is hardware tokens which is great for important stuff but not really for those thirteen in a dozen accounts.
But I view passkeys as more for the low-hanging fruit. All the crap accounts that every webshop and news outlet makes you create these days. I have 500+ accounts in my current password manager. Not being able to migrate that away to another service would be a nightmare. Being locked in with a big tech company would be too.
What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile.
Also, if software password managers don't offer export options it doesn't mean it's impossible to export. They just don't want to make it possible. But an adversary could. The only way to really make it impossible is hardware tokens which is great for important stuff but not really for those thirteen in a dozen accounts.
> What my ideal would be is to have the master key on multiple HSMs (like multiple yubikeys) so they are safe but mobile.
That would be glorious. It would be great if it was standards-based, too, to prevent vendor lock-in.
That would be glorious. It would be great if it was standards-based, too, to prevent vendor lock-in.
I just looked on github (where I have 4 passkeys registered), and I noticed that the bitwarden one has a little "Synced" flag next to it. The tooltip says "This passkey is eligable for backup by its provider", so sites can distinguish between exportable ones and non-exportable ones.
That's different from what most people mean by "exportable", which is that the provider will give you a copy of the passkey which you can import into another provider.
Syncable means that the provider can backup your passkey to someplace under their control, from whence they can restore it to a different device of yours where you also have that provider's client software.
Here's how Github explains it [1]
> Many passkeys support syncing, where your passkey is backed up by the provider's account system (iCloud, Google account, password manager, etc.). If you ever lose your device, you can recover your synced passkeys by signing in to your passkey provider.
BTW, the flag on Github should probably say "Syncable" rather than "Synced".
[1] https://docs.github.com/en/authentication/authenticating-wit...
Syncable means that the provider can backup your passkey to someplace under their control, from whence they can restore it to a different device of yours where you also have that provider's client software.
Here's how Github explains it [1]
> Many passkeys support syncing, where your passkey is backed up by the provider's account system (iCloud, Google account, password manager, etc.). If you ever lose your device, you can recover your synced passkeys by signing in to your passkey provider.
BTW, the flag on Github should probably say "Syncable" rather than "Synced".
[1] https://docs.github.com/en/authentication/authenticating-wit...
That's interesting information, thanks!
I mean the question if private keys should be synced is the fun one to argue about ;-)
My thinking is always if you do passkeys for phishing protection or potentially UX improvements then there is no harm syncing keys. (I would argue the security is increased by adding phishing protection over password/2fa) If you do it for security, then you do not want to sync keys and rely on key storage that do not allow extraction (most secure will be "offline" key stores like YubiKeys). I guess the latter is more important in enterprise/business scenarios rather than in b2c context.
A little OT but it will also be fun in b2c explaining customers that there keystore is full on the hardware key. (of the top of my head YubiKey 5 have a limit of about 25 keys)
My thinking is always if you do passkeys for phishing protection or potentially UX improvements then there is no harm syncing keys. (I would argue the security is increased by adding phishing protection over password/2fa) If you do it for security, then you do not want to sync keys and rely on key storage that do not allow extraction (most secure will be "offline" key stores like YubiKeys). I guess the latter is more important in enterprise/business scenarios rather than in b2c context.
A little OT but it will also be fun in b2c explaining customers that there keystore is full on the hardware key. (of the top of my head YubiKey 5 have a limit of about 25 keys)
If passkey is an additional factor, I'm on the same boat with you. You can sync them all the way down.
But if it's the only factor, I can't see a difference between password reuse and passkey reuse. If I can recover it in any way, then it's (very) game over.
So I'm not mad that you can't sync a passkey if it's the single factor. Because as we don't reuse app passwords for multiple devices or normal passwords for multiple sites, we shouldn't use the same private keys on many devices, allowing a more granular and better approach.
Of course this is my view and some people won't agree. I prefer a good multi-layer system, not a single passkey opens the whole world style one.
But if it's the only factor, I can't see a difference between password reuse and passkey reuse. If I can recover it in any way, then it's (very) game over.
So I'm not mad that you can't sync a passkey if it's the single factor. Because as we don't reuse app passwords for multiple devices or normal passwords for multiple sites, we shouldn't use the same private keys on many devices, allowing a more granular and better approach.
Of course this is my view and some people won't agree. I prefer a good multi-layer system, not a single passkey opens the whole world style one.
Why do you think it is reuse?
You will not use the same passkey for multiple application/service.
You will generate a passkey per application/service.
I will certainly though not disagree on security... if that is your thing then do not sync private keys around, but the tradeoff is always there. If security would be critical, I would favor client certs with smartcards, but browsers do not support that "too well"
You will not use the same passkey for multiple application/service.
You will generate a passkey per application/service.
I will certainly though not disagree on security... if that is your thing then do not sync private keys around, but the tradeoff is always there. If security would be critical, I would favor client certs with smartcards, but browsers do not support that "too well"
If I share the same private key for an account with "n" devices, losing (incl. theft of) that key will lock me out.
If I have "n" private keys for an account, I can use another private key and revoke the lost/compromised one. It's that simple.
Your secure enclave is not much different electronically from a smart card with a biometric password actually. People think Passkeys as SSH keys on disk, but it's more of a long private key on a single-way secure enclave. This is why people cry "platform lock-in". It's platform lock-in, but it's a secondary effect. It's actually a "proper HSM, but integrated".
If I have "n" private keys for an account, I can use another private key and revoke the lost/compromised one. It's that simple.
Your secure enclave is not much different electronically from a smart card with a biometric password actually. People think Passkeys as SSH keys on disk, but it's more of a long private key on a single-way secure enclave. This is why people cry "platform lock-in". It's platform lock-in, but it's a secondary effect. It's actually a "proper HSM, but integrated".
Yes but the same logic about loosing the secret applies to passwords and any other factors (given we ignore a potential reset process)
Providers will most of the time allow to register multiple passkeys or other authentication means, hopefully ;-) which has its own downsides.
I am well aware how the internals work of keystores. But the benefit with "client certs" is that on mTLS you get added benefits besides where the key is stored. And that is that you can "prevent" mitm attacks.
But I guess that is a subject for another thread.
Providers will most of the time allow to register multiple passkeys or other authentication means, hopefully ;-) which has its own downsides.
I am well aware how the internals work of keystores. But the benefit with "client certs" is that on mTLS you get added benefits besides where the key is stored. And that is that you can "prevent" mitm attacks.
But I guess that is a subject for another thread.
Resident passkeys really are just the 2020-JavaScript version of X.509-based mutual authentication - naturally it's incompatible with anything but the web, sits on a weird level of the stack, and is somehow even less transparent to the user. On the other hand, certificate slots still seem to run approximately a dollar each.
Haha comparison made me giggle.
When using a passkey as the only factor, it gets complicated, but I think that will be the future: Email and SMS as fallbacks with additional factors like risk-based location checks (or local storage hints) to have a viable recovery mechanism parallel to passkeys. I think Github has a nice approach that we use as a role model: Collect as many fallbacks as possible in a convenient manner. Adding passkeys on any new device and regularly reminding people to check their fallbacks. That's still way more secure than passwords only, where the fallback is practically always a form of email OTP. Also social logins from Google or Apple can act as a fallback as they are (mostly) 2FA.
I'm not against using a passkey as a single factor, and having fallbacks. It's reasonable if you can reliably attach that key to a physical device, so the device can't be impersonated.
I don't think that we should target MIL-xxx standards for daily use, but my security is comparably important to me as military's missile codes are important to them.
So, I don't want my passkey-based services to have a security theater in the name of convenience. There should be some friction to force a baseline security.
I don't think that we should target MIL-xxx standards for daily use, but my security is comparably important to me as military's missile codes are important to them.
So, I don't want my passkey-based services to have a security theater in the name of convenience. There should be some friction to force a baseline security.
Agree, but I think in a B2C context, you need convenience first; then security can follow.
I think it depends. Banking, primary e-mails, etc. are extremely important systems today, and they should bias towards security. Other platforms where we talk can take a more balanced approach, and more casual sites can lean towards convenience, if you ask me.
Indeed, the problem with lots of fallbacks is that they can invalidate user's requests for higher security. Security can sometimes end up being only as strong as the weakest link.
Make the fallback too lax and you might as well not bother with 2FA/Passkeys at all.
Make the fallback too lax and you might as well not bother with 2FA/Passkeys at all.
Perhaps what you are missing is the "middle ground" here because it is an implementation detail of some of the passkey implementations (especially some of the ones meant to be "consumer-resilient": derived keys. Rather than keeping every key for every site in hardware, you might use some secret shared between the hardware keys plus whatever site-specific salt/pepper/hash into some key derivation function (KDF).
For those kinds of keys extraction is sort of meaningless: the private keys maybe aren't even stored at rest, they are re-derived as necessary. You can sync the encrypted shared secret and all the site-specific salt/pepper/hashes even to devices that can't decrypt them. (That's how secure but consumer-friendly syncing is built, and that's a part of how recovery pathways get built.) But it isn't useful on its own without the hardware keys that you can't themselves export.
You can have syncing with the root keys being exportable/extractable. That's already how many of the consumer solutions are being built. That's part of where the consumer-friendly security is for Passkeys.
For those kinds of keys extraction is sort of meaningless: the private keys maybe aren't even stored at rest, they are re-derived as necessary. You can sync the encrypted shared secret and all the site-specific salt/pepper/hashes even to devices that can't decrypt them. (That's how secure but consumer-friendly syncing is built, and that's a part of how recovery pathways get built.) But it isn't useful on its own without the hardware keys that you can't themselves export.
You can have syncing with the root keys being exportable/extractable. That's already how many of the consumer solutions are being built. That's part of where the consumer-friendly security is for Passkeys.
Deriving per-domain key pairs from a single master secret is what SQRL did, makes perfect sense for most use cases, allows for straightforward paper backup and transport between devices.
https://www.grc.com/sqrl/sqrl.htm
The use case is that I’m an Apple/iCloud user and want to migrate to Google/Linux/whatever and don’t want to go to 100 sites manually to change my passkey?
You actually can backup your webauthn master seed with a Ledger as a 24 word phrase you write down.
These crop up every now and again but they never address my biggest concern, which how we can be sure that https://w3c.github.io/webauthn/#attestation-object will not create a situation where only approved devices are allowed to authenticate.
It's not hard to imagine Google and Apple and a few others finding ways to pressure authenticators into blocking access to users of devices that cannot prove that they're running firmware which bellyfeels ingsoc.
It's not hard to imagine Google and Apple and a few others finding ways to pressure authenticators into blocking access to users of devices that cannot prove that they're running firmware which bellyfeels ingsoc.
Device attestation is exactly what you want in a corporate (or government) environment, and exactly what you don't want for your own private devices.
In a sense though, we've already lost that fight: try ordering an uber (or anything else that has an app but not an equivalent website) without both your device and OS being from one of a small set of approved manufacturers. Firefox OS never had a chance.
In a sense though, we've already lost that fight: try ordering an uber (or anything else that has an app but not an equivalent website) without both your device and OS being from one of a small set of approved manufacturers. Firefox OS never had a chance.
People said I wouldn't be able to use ride sharing apps or banking apps on GrapheneOS but so far I've been able to.
Pager duty won't open though, which is a shame because having separate work/personal profiles on the same device was kind of the point.
Pager duty won't open though, which is a shame because having separate work/personal profiles on the same device was kind of the point.
It is a fair worry. On one side, there are sites with regulations that they are supposed to meet and it's hard to do so without knowing something about the passkey provider. If we want to try and replace SMS OTP, which is depressingly easy to compromise, we can't ignore such things.
On the other, we don't want to create a situation where it's impossible to start a new passkey provider because you'll never get 1000s of websites to put you on their allowlist.
So far, we haven't done attestation for passkey providers at all. There is only the AAGUID, which is a spoofable identifer should any sites try to filter based on it. There are legitimate cases where sites are required to know more, but we're trying to find a path that doesn't lead to the problems that you worry about and, so far, are erring on the side of openness.
On the other, we don't want to create a situation where it's impossible to start a new passkey provider because you'll never get 1000s of websites to put you on their allowlist.
So far, we haven't done attestation for passkey providers at all. There is only the AAGUID, which is a spoofable identifer should any sites try to filter based on it. There are legitimate cases where sites are required to know more, but we're trying to find a path that doesn't lead to the problems that you worry about and, so far, are erring on the side of openness.
> it's impossible to start a new passkey provider because you'll never get 1000s of websites to put you on their allowlist.
You ignore history. and human nature.
Everyone will just hardcode a big `if microsoft || google || apple` and call it a day. And over time local gov will require companies under their TLD also add gov.TLD and that will be status quo forever.
As other commenters mentioned, EU official login (which accepts SMS but not TOTP!!!) already works with passkeys with only weird approved devices (mostly android/ios apps which try very hard to detect non-stock roms)
You ignore history. and human nature.
Everyone will just hardcode a big `if microsoft || google || apple` and call it a day. And over time local gov will require companies under their TLD also add gov.TLD and that will be status quo forever.
As other commenters mentioned, EU official login (which accepts SMS but not TOTP!!!) already works with passkeys with only weird approved devices (mostly android/ios apps which try very hard to detect non-stock roms)
> On one side, there are sites with regulations that they are supposed to meet
I find it rather hard to believe there are websites subject to regulations that are impossible to comply with today?
Are you sure you didn't hear this from someone creatively interpreting some unrelated regulation? Standards committees are always full of people trying to cram their employer's patents and products into the standards.
I find it rather hard to believe there are websites subject to regulations that are impossible to comply with today?
Are you sure you didn't hear this from someone creatively interpreting some unrelated regulation? Standards committees are always full of people trying to cram their employer's patents and products into the standards.
Disclaimer Corbado Co-Founder here: That passkeys (WebAuthn) as a standard can support different levels of security requirements in the future on a common ground is probably the best thing. Even with an unknown new passkey provider, that's still more secure for the average consumer on a broad scale with legitimate passkey providers being 99.9% of the market. For regulated entities, that's an important area of extension. But even for banks, passkeys can easily replace the first factor, as phishing there is the biggest concern. I would argue that Passkeys+SMS OTP for banking is probably far more secure than any other option currently available (even with the sad security of SMS OTP), just because consumers cannot give their First-Factor voluntary away to phishing... Well maybe not better that any option but a lot of them.
I want to self-host my account credentials. Or more accurately, I absolutely do not want Apple | Google | Microsoft to be able to lock my account, and thereby lock me out of every other account. Especially as two of them have already done so.
If I could act as a passkey provider for myself, similar to how I can do that with SSH, then that’d be great. I do not comprehend why it’s not allowed, apart from being part of a further grasp for power by those companies.
If I could act as a passkey provider for myself, similar to how I can do that with SSH, then that’d be great. I do not comprehend why it’s not allowed, apart from being part of a further grasp for power by those companies.
Well, you can store your passkeys in a password manager like KeePassXC. Open-source password/passkey manager actually means more or less self-hosting your credentials as a third-party provider.
Google/Apple don't have to pressure anyone.
Companies like PayPal and eBay are already gate-keeping the ability to use PassKeys based on user-agent.
Firefox on Ubuntu doesn't get the option to sign-in with PassKeys on Paypal. Fake the UA over to Safari on OSX and it'll happily work.
Companies like PayPal and eBay are already gate-keeping the ability to use PassKeys based on user-agent.
Firefox on Ubuntu doesn't get the option to sign-in with PassKeys on Paypal. Fake the UA over to Safari on OSX and it'll happily work.
That is probably because their implementation was released prior to Firefox implementing passkeys, and they have not yet updated their system.
You don't have to fear it. It's already here. I can't store my electronic government id on my Yubikey since it's not an approved device. So unless I buy a certain hardware token, my only option is to entrust my private key to a privately-owned certificate authority named A-Trust that forgot to renew their own root certificate once, taking out all government websites and services, and blamed an influx of users on a DDoS attack, in a regulatory environment where companies and even the government itself sue security researchers for disclosing security vulnerabilities responsibly, combined with tech illiterate journalists that buy whatever press statement they publish without verifying anything. Yeah uh, how about no? I trust my Yubikey more than you. I in fact lack so much trust in A-Trust that I assume my electronic government id is compromised, and that I among a few others call them A minus Trust, not A Trust.
Are you from Austria by any chance? So this is why I can't provision my yubikey for government authentication?
Australia, India, China, Brazil, EU. That I know of.
US have id.me which is even worse than everything under the sun, and passkey bound by device would be a welcome alternative.
Pray you never get poor enough to have benefits gate kept by digital goverments logins.
US have id.me which is even worse than everything under the sun, and passkey bound by device would be a welcome alternative.
Pray you never get poor enough to have benefits gate kept by digital goverments logins.
Here in Austria authentication revolves around this A-Trust entity (which is anything but) that the GP mentioned.
The way it works is by SMS, which is very bad. They also have two absolutely appalling and confusing apps for authentication (and signing documents, but that never works), but they are useless from a security point of view as you can always revert back to SMS. And sometimes you need both the SMS and the app. Ugh. Also, if you are a non-Austrian citizen you need to register your phone with the police to be able to fully use most services.
I want to get rid of this SMS loophole, and my understanding is that they used to support smartcards[1], and now support FIDO2 keys. Smartcards are annoying so I am trying to use my Yubikey, but when I try to provision it, it fails with some generic error.
[1] Our health insurance cards used to be these smartcards, but I believe this system has been discontinued, although it's definitely still in use for medical services.
The way it works is by SMS, which is very bad. They also have two absolutely appalling and confusing apps for authentication (and signing documents, but that never works), but they are useless from a security point of view as you can always revert back to SMS. And sometimes you need both the SMS and the app. Ugh. Also, if you are a non-Austrian citizen you need to register your phone with the police to be able to fully use most services.
I want to get rid of this SMS loophole, and my understanding is that they used to support smartcards[1], and now support FIDO2 keys. Smartcards are annoying so I am trying to use my Yubikey, but when I try to provision it, it fails with some generic error.
[1] Our health insurance cards used to be these smartcards, but I believe this system has been discontinued, although it's definitely still in use for medical services.
my point is that Australia, like the others i mentioned, are phasing out sms. and more importantly, already phased out TOTP. Because they want you to use a dumb app which collect data.
Yes, exactly. Here is a list of approved hardware tokens: https://www.a-trust.at/de/fido/
I don’t know anything about this. But let me guess: they also require you to use edge or chromium or some closed source and shitty sidecar application on your desktop?
FWIW Apple explicitly doesn't support attestation for consumer apple-IDs. Only for managed apple IDs. Exactly because they didn't like the implications of forcing authentication to pre-approved implementations.
You mean they don't support third party attestation for consumer apple-IDs. Between parts pairing and the degree they've locked they're app store down, Apple is the king of things that refuse to be useful unless they're running in an approved environment.
They're just ensuring that their right to mistreat users is an exclusive one. Handcuffs are handcuffs, even if Apple is the only one who has the key.
They're just ensuring that their right to mistreat users is an exclusive one. Handcuffs are handcuffs, even if Apple is the only one who has the key.
This thread is a great survey of why the passkey roll out is so controversial. Even without the inevitable “but what if Google/Apple permabans me?” thread, we have confusion about whether QR codes are sufficient, biometrics are necessary, and a baffling UI that maybe means to say “debug the bluetooth stacks on whatever devices are nearby”.
You can use yubikeys as passkeys, if you are afraid of a Google/Apple ban
What if you lose your yubikey?
"Go enroll a new one in your 500 accounts" is not a good enough answer. The thing about a regular password manager is that it does not get lost.
"Go enroll a new one in your 500 accounts" is not a good enough answer. The thing about a regular password manager is that it does not get lost.
For 500 accounts you would need 20 yubikeys. That’s quite a yubikeyring.
True. I personally prefer non-residential keys that don't take up any space on your yubikey. The keys are reconstructed on the fly based on a value that I receive from the server I am authenticating against.
Passkeys are residential keys and they consume storage. The minor upside is that they free the user from remembering their username.
Passkeys are residential keys and they consume storage. The minor upside is that they free the user from remembering their username.
The point isn’t that we should have to trust Apple/Google for our passkeys — it’s that we should have full control over the backing store used by our password manager(s).
Where does it say that you have to trust Google / Apple?
Passkeys are webauthn credentials. Store them in whatever webauthn store you like. I use a combination of bitwarden and iCloud.
Passkeys are webauthn credentials. Store them in whatever webauthn store you like. I use a combination of bitwarden and iCloud.
The standard supports exports, it should arrive; the vast majority of users will never export them from Google or iCloud synced storage though.
https://news.ycombinator.com/item?id=35855133 ("HN: Passkeys will be importable, exportable, cross-device, and across managers")
https://news.ycombinator.com/item?id=35855133 ("HN: Passkeys will be importable, exportable, cross-device, and across managers")
Until it arrives it's nothing but an empty promise. The biggest players have a lot to gain from not allowing export, or doing what Apple does with "right to repair" and now the DSA in the EU; technically "supporting" repairability or interoperability while making it all but impossible in reality.
It's no surprise that they're trying to gain as much adoption as possible without having it, and that export is the part of the spec that was apparently not deemed important enough to have ready before doing so. KeepassXC is the only one supporting it, and just look at how much backlash they got, with veiled threats of requiring attestation and banning its usage.
No, there is zero reason to be optimistic towards this.
It's no surprise that they're trying to gain as much adoption as possible without having it, and that export is the part of the spec that was apparently not deemed important enough to have ready before doing so. KeepassXC is the only one supporting it, and just look at how much backlash they got, with veiled threats of requiring attestation and banning its usage.
No, there is zero reason to be optimistic towards this.
I have been following the discussions closely in https://github.com/w3c/webauthn and I haven't seen anything about exportability there in the past year. The only reference I can find is that post on Hachyderm from a year ago.
We're a year later and the needle didn't move on this. Which is a bit worrying
We're a year later and the needle didn't move on this. Which is a bit worrying
I am unfamiliar with passkeys. Can they be exported and imported, or WILL it be possible one day?
Because that affects my choice to adopt them today.
Because that affects my choice to adopt them today.
Individual choices to not adopt due to this requirement is unlikely to impact mass market adoption. While I certainly hope the export capability is delivered as promised, it won’t hold most folks back from adopting this auth mechanism.
https://www.engadget.com/google-says-its-secure-entry-passke... (“Google says its secure entry passkeys have been used a billion times by 400 million Google accounts”)
https://www.engadget.com/google-says-its-secure-entry-passke... (“Google says its secure entry passkeys have been used a billion times by 400 million Google accounts”)
https://github.blog/2024-04-24-securing-millions-of-develope... ("Finally, as a result of our improved enrollment experience and passkey rollout, our data shows that it’s 47% more likely users will configure two or more forms of 2FA.") that is also promising so it is not just Google, where somebody could argue they promote it for other reasons.
So the average user has only used passkeys 2.5 times? Yikes.
and i bet it went like:
1. login on computer. click next mindlessly on setup flow.
2. use account
3. try to login on phone. click next mindlessly on setup flow again.
4. where's my data?! oh well, lost my old account. let's use the new one
5. eternal confusion while switching devices. never return to site again.
= 2.5 times per user
1. login on computer. click next mindlessly on setup flow.
2. use account
3. try to login on phone. click next mindlessly on setup flow again.
4. where's my data?! oh well, lost my old account. let's use the new one
5. eternal confusion while switching devices. never return to site again.
= 2.5 times per user
How often do you login to your Google account once logged in? I don't remember the last time Google asked me to login, because the session persists.
I hope that you properly segment your browsing then, because surely you don't browse the web while logged in to google?
Moving the goalposts to a data security and privacy concern from strong auth factors. I don’t care if Google has my browsing history. I do care if someone else can log into my account, or ease of managing my own credentials. Auth protects you from others, data security and privacy measures protect you from the counterparty.
Not moving the goalposts. Just stating why you'd want to login often, or solve it in some other way.
> https://www.engadget.com/google-says-its-secure-entry-passke...
lol. engadget literally copied and pasted the press release they gov via email! it still have all the links hidden by their corporate phishing thing:
lol. engadget literally copied and pasted the press release they gov via email! it still have all the links hidden by their corporate phishing thing:
like: https://urldefense.com/v3/__http://g.co/passkeys__;!!Op6eflyXZCqGR5I!GFYwYEDk1Zq0xZpr4q834hOMHa1R4ovVB7D37okCF9TxEVdc5cuJkzdaExbdZ1BvCPR5xkjYtLaF_0Ldk8v53R8$Native implementations do not allow exporting and importing. Of course technically it’s possible but they gone great lengths hiding it from user “for security”, so probably they wouldn’t allow any export.
If you run vault warden, it worked for me at passkeys.io and it’s just an SQL DB, so surely you could extract anything (although I didn’t see a specific UI for it).
If you run vault warden, it worked for me at passkeys.io and it’s just an SQL DB, so surely you could extract anything (although I didn’t see a specific UI for it).
I have not tested it but some users in the bitwarden forum has mentionned that it's included in the vault export (cf https://community.bitwarden.com/t/passkey-portability/59177/...).
Password managers like 1Password support PassKeys.
You can get a second one as backup. They actually recommend to do this themselves and provide tools for cloning.
Correct me if I'm wrong but I don't think you're meant to clone them per se. You're better off creating a unique passkey for each device, and if one is lost you can revoke that passkey without bricking your backup device as a login method at the same time.
That's how I treat my Yubikeys at least. The only downside with this is that some services (e.g. PayPal) only let you create one passkey.
That's how I treat my Yubikeys at least. The only downside with this is that some services (e.g. PayPal) only let you create one passkey.
"The only downside" is a show stopper that means you do not have a Backup at all.
Most services let you fall back on traditional username and password if you lose your passkey
Then why have one?
Very thorough article, nice! I'll add some other pain points I experienced:
- You need to let users register more than 1 passkey, but how to show them which is which? There are lists like this one[1] and FIDO provides a (maybe irrelevant?) list on their site[2] stuck inside of a JWT. I ended up using that JSON list + registration date + browser UA that registered it + "currently using" indicator when the current session derives from that specific passkey. Still kind of feels like a mess.
- The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64, which doesn't have native browser support. Not a big deal (just a couple helper functions needed) but kind of confusing if you're trying to implement the client or server bits from scratch. [Edit: as explained by a reply below, this is part of the actual spec!]
- I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously. The APIs seem to be mutually exclusive, differentiated by some options (some of which are already deprecated?) and requiring empty lists to be passed in certain places. I'm trying to bolt on passkeys to a pre-existing auth flow and all I want is the closest thing to "use the browser's built in password manager". Ended up giving up on resident keys for now.
[1]: https://github.com/passkeydeveloper/passkey-authenticator-aa...
[2]: https://fidoalliance.org/metadata/
- You need to let users register more than 1 passkey, but how to show them which is which? There are lists like this one[1] and FIDO provides a (maybe irrelevant?) list on their site[2] stuck inside of a JWT. I ended up using that JSON list + registration date + browser UA that registered it + "currently using" indicator when the current session derives from that specific passkey. Still kind of feels like a mess.
- The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64, which doesn't have native browser support. Not a big deal (just a couple helper functions needed) but kind of confusing if you're trying to implement the client or server bits from scratch. [Edit: as explained by a reply below, this is part of the actual spec!]
- I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously. The APIs seem to be mutually exclusive, differentiated by some options (some of which are already deprecated?) and requiring empty lists to be passed in certain places. I'm trying to bolt on passkeys to a pre-existing auth flow and all I want is the closest thing to "use the browser's built in password manager". Ended up giving up on resident keys for now.
[1]: https://github.com/passkeydeveloper/passkey-authenticator-aa...
[2]: https://fidoalliance.org/metadata/
> The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64
WebAuthn itself uses base64url rather than base64. See, e.g., the `id` field here: https://www.w3.org/TR/webauthn-2/#iface-pkcredential
(It was probably a mistake, but it predates me so I don't know the motivation.)
> I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously.
Non-discoverable credentials can only be used if their credential ID is passed in an allowlist. Discoverable credentials (a.k.a. "resident" in the API, although that name is a bit misleading) _can_ be enumerated in an allowlist. So they can work together, but to have the allowlist you must collect a username first or have some other way of know which account is pertinent to the current session.
WebAuthn itself uses base64url rather than base64. See, e.g., the `id` field here: https://www.w3.org/TR/webauthn-2/#iface-pkcredential
(It was probably a mistake, but it predates me so I don't know the motivation.)
> I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously.
Non-discoverable credentials can only be used if their credential ID is passed in an allowlist. Discoverable credentials (a.k.a. "resident" in the API, although that name is a bit misleading) _can_ be enumerated in an allowlist. So they can work together, but to have the allowlist you must collect a username first or have some other way of know which account is pertinent to the current session.
Aha, so it is part of the spec. Thanks for clarifying that. Appreciate the advice on discoverable credentials as well! I was probably leaving out the discoverable creds from the allowlist. Getting the timing down for when to ask for credentials was a bit tricky but I think I see the whole picture now.
I will say though, when it all works out it's a really nice way to log in, and my users are happy about it.
I will say though, when it all works out it's a really nice way to log in, and my users are happy about it.
Do you allow users to rename their passkeys in your user interface? I very much like how GitHub handles this, take a look in that view if you have a GitHub account. You also get nice info like "Seen from this browser" and "Synced" (non device bound passkeys) indicators if applicable.
https://github.com/settings/security (Passkeys section)
https://docs.github.com/en/authentication/authenticating-wit...
https://github.com/settings/security (Passkeys section)
https://docs.github.com/en/authentication/authenticating-wit...
That's a good idea, thanks for the suggestion! Maybe I'll let them rename the keys with the provider as the default name. Haven't played with GitHub's implementation yet but I'll play around with it.
We ask the user to name each passkey. One more modal dialog during registration, but seems to work well.
There have been times in the past where we took something moderately simple (random number generation once you've got a good entropy source; digital signatures) and turned them into a monster (Dual-EC DRBG; ECDSA). It turns out those were bad ideas.
The more I read about passkeys, the more I feel we're creating a new monster here. I'm just glad there's no "alg:none" option included.
If you have a device that can store and sign with resident keys for a private/public key infrastructure, I don't see why we need all the extra complexity unless you want to charge everyone $4.99/mo for a key management SaaS, or force the last remaining Win11 users who log in with a local account onto Microsoft Accounts and Windows Hello (which I understand is the only way to get passkeys in edge without third-party software or devices).
The more I read about passkeys, the more I feel we're creating a new monster here. I'm just glad there's no "alg:none" option included.
If you have a device that can store and sign with resident keys for a private/public key infrastructure, I don't see why we need all the extra complexity unless you want to charge everyone $4.99/mo for a key management SaaS, or force the last remaining Win11 users who log in with a local account onto Microsoft Accounts and Windows Hello (which I understand is the only way to get passkeys in edge without third-party software or devices).
Um.. isn't today recommended to use ecdsa for ssh keys?
I personally recommend EdDSA - just one letter difference, but a very big one under the hood! (If you're using `-t ed25519` then you're using EdDSA.)
EDIT: Github agrees with me: https://docs.github.com/en/authentication/connecting-to-gith... they recommend EdDSA/ed25519 as first option, and RSA as fallback. ECDSA is not in the list at all.
EDIT2: gitlab (https://docs.gitlab.com/ee/user/ssh.html) also recommends ed25519 (which uses EdDSA for signatures). They'll grudgingly let you use ECDSA but point you to https://leanpub.com/gocrypto/read#leanpub-auto-ecdsa for a lecture on why it's a bad choice; there are actually more problems with it than the ones covered on that page that would be far harder to fix.
EDIT: Github agrees with me: https://docs.github.com/en/authentication/connecting-to-gith... they recommend EdDSA/ed25519 as first option, and RSA as fallback. ECDSA is not in the list at all.
EDIT2: gitlab (https://docs.gitlab.com/ee/user/ssh.html) also recommends ed25519 (which uses EdDSA for signatures). They'll grudgingly let you use ECDSA but point you to https://leanpub.com/gocrypto/read#leanpub-auto-ecdsa for a lecture on why it's a bad choice; there are actually more problems with it than the ones covered on that page that would be far harder to fix.
Thank you for that and the linked resources, makes more sense now!
About three weeks ago, I grabbed some samples out of a freezer at -80C without gloves because it was quick. Yes it was stupid! (It's also quite common that someone who needs to "grab one sample real quick" does this.) The fingers on my right hand felt prickly for a couple minutes after that but no harm, it seemed. Well it took a couple weeks but the fingertips on my right hand all started blistering and one finger basically has a second-degree burn. My left hand, which I didn't use on the freezer, seems to be experiencing mirroring blisters, and I have no explanation since I didn't do anything (stupid or otherwise) to burn/blister them. If I were relying on passkeys and I couldn't register multiple keys, like one for each of my ten fingers plus face plus hardware token, I'd be locked out of my passkey-protected accounts for... I mean I honestly don't know how long, my fingerprints could still be healing a month from now.
So between that and the kinks that still need to be worked out regarding exporting and FAANG lock-in, I'll keep using my passwords. And wearing gloves when using -80C freezers.
So between that and the kinks that still need to be worked out regarding exporting and FAANG lock-in, I'll keep using my passwords. And wearing gloves when using -80C freezers.
I don't get the problem, if you can enter your password you can also enter your Windows/macOS/Android/iOS password/PIN to authenticate with your passkeys. Windows Hello will accept a TPM PIN if facial recognition and fingerprint scanners aren't available, for example. Android will unlock the passkey storage just fine if the fingerprint scanner dies by using the PIN instead.
Your fingerprints and your passkeys aren't connected at all. You can choose to only connect them to biometrics if you opt to disable all alternative authentication methods on your computers/phones/etc, but as you explained yourself, that would cause quite a few problems.
Your fingerprints and your passkeys aren't connected at all. You can choose to only connect them to biometrics if you opt to disable all alternative authentication methods on your computers/phones/etc, but as you explained yourself, that would cause quite a few problems.
basically this
https://news.ycombinator.com/item?id=39706876
I don't see the connection? There are pros and cons to passkeys, and the linked comment has some valid concerns, but you will always be able to use your passkeys without biometrics as long as your phone and computer will unlock without biometrics.
It was the wrong comment, sorry about that.
https://news.ycombinator.com/item?id=40172324
https://news.ycombinator.com/item?id=40172324
Passkeys != biometric auth
Technically correct yet I would not be surprised if they're still quite widely used. And the second part?
All phones ask for PIN or pattern in addition to face/fingerprint. Use that.
For the average user this is safe enough. (i.e) keep google/apple password safe. Then all is fine.
> exporting and FAANG lock-in
You don't ever have to even sign into FAANG if you can put up with inconvenience.
- Buy a U2F FIDO key like OPEN SOURCE https://solokeys.com/ or Yubikey etc - You can register this key directly at the website or - Use https://bitwarden.com/passwordless-passkeys/ - Every password manager need to implement it obviously
For the average user this is safe enough. (i.e) keep google/apple password safe. Then all is fine.
> exporting and FAANG lock-in
You don't ever have to even sign into FAANG if you can put up with inconvenience.
- Buy a U2F FIDO key like OPEN SOURCE https://solokeys.com/ or Yubikey etc - You can register this key directly at the website or - Use https://bitwarden.com/passwordless-passkeys/ - Every password manager need to implement it obviously
Symmetrical nature is strange -- almost like Raynaud's. But anyways I hadn't realized just how quickly that temperature could damage your skin, that's wild. Hopefully they heal up quickly.
It wasn't the cold air itself so much as the fact that I had to handle metal doors and racks to get to the cardboard boxes holding the sample vials. I didn't touch any one thing for longer than a few seconds but I guess even if you only spend a couple minutes doing that, cumulatively it added up.
Since I'm off microbe duty for the weekend I started to play science with the rest of the fingers on my right hand, comparing what does better healing - antibiotic ointment, petroleum jelly, or "liquid bandage".
Since I'm off microbe duty for the weekend I started to play science with the rest of the fingers on my right hand, comparing what does better healing - antibiotic ointment, petroleum jelly, or "liquid bandage".
Updating/elaborating here before the comment window closes on the off chance that an obscure log on HN helps in the future.
The situation with my fingertips matches most with Pompholyx/dyshidrotic eczema in the sense that the first thing to happen was very tiny pinprick blisters called vesicles appearing on my fingertips before they developed a callus-like texture which has generally given way to skin peeling, in that one case enough to make me think I had a second-degree burn.
I've never had ezcema before, so no wonder I wasn't thinking about it. But that itself is bizarre, because a 30-year streak comes to an end with no conclusive reason. Triggers can include metals (not around any unusual ones AFAIK), allergies or weather (?!?), foods (never a problem before!), stress (okay, great), sweaty palms (biologists wear gloves all the time and it's never been a problem before), potential fungal infections, chemical irritants, and more. And as I said originally, this showed up a couple of weeks after what I thought was the most likely trigger, so it probably isn't actually the trigger.
It can be chronic, or happen once in your life and never again! The symptoms are supposed to fade after "a few weeks", so hopefully 2 down now. Treatments include keeping hands hydrated, stress management, antihistamines, moisturizing creams with dimethicone, calcineurin, or steroids, and even UV light treatment. Hygiene is important for preventing bacterial infection.
Still hoping it clears up soon.
The situation with my fingertips matches most with Pompholyx/dyshidrotic eczema in the sense that the first thing to happen was very tiny pinprick blisters called vesicles appearing on my fingertips before they developed a callus-like texture which has generally given way to skin peeling, in that one case enough to make me think I had a second-degree burn.
I've never had ezcema before, so no wonder I wasn't thinking about it. But that itself is bizarre, because a 30-year streak comes to an end with no conclusive reason. Triggers can include metals (not around any unusual ones AFAIK), allergies or weather (?!?), foods (never a problem before!), stress (okay, great), sweaty palms (biologists wear gloves all the time and it's never been a problem before), potential fungal infections, chemical irritants, and more. And as I said originally, this showed up a couple of weeks after what I thought was the most likely trigger, so it probably isn't actually the trigger.
It can be chronic, or happen once in your life and never again! The symptoms are supposed to fade after "a few weeks", so hopefully 2 down now. Treatments include keeping hands hydrated, stress management, antihistamines, moisturizing creams with dimethicone, calcineurin, or steroids, and even UV light treatment. Hygiene is important for preventing bacterial infection.
Still hoping it clears up soon.
Last update, had an e-visit with a NP who said it sounded like dishydrotic ezcema, hooray guessing skills. Got prescribed a steroid cream which insurance refuses to cover, and a dermatologist appointment next week. I wash my hands, pat them dry, cover them in lotion or petroleum jelly, and cover the fingertips in bandages, and honestly it's just slowly getting worse. Cotton gloves dried my hands out in minutes. US health insurance is BS.
My wife actually developed this in her late twenties (now 39). She hasn't had much luck keeping it from slowly progressing, but it comes and goes in waves. Lotion / steroid helps a little but nobody has a good solution for it, yet. She works w/ her hands and it hasn't limited her, but is frustrating.
I don't have anything helpful really but feel free to reach out (email in bio) if you want me to put you in contact w/ my partner just to have someone to chat with about it. Best of luck in managing it.
I don't have anything helpful really but feel free to reach out (email in bio) if you want me to put you in contact w/ my partner just to have someone to chat with about it. Best of luck in managing it.
silly hot take.
use a third party manager like Strongbox to avoid faang and biometrics if you want.
use a third party manager like Strongbox to avoid faang and biometrics if you want.
I still haven’t really migrated to passkeys yet. Until Bitwarden on iOS properly supports them I won’t fully switch. I don’t want to have to manage a passkey on every device. So I will wait until I can sync between all my devices.
But when I did play with them a bit it seemed so full of weird pitfalls. Aren’t I supposed to be able to use my phones passkey to login on my PC with a QR code? I never got that to work. The article implies that might be a windows 10 vs 11 issue- but why? It’s a QR code. Windows 10 should be capable of displaying a QR code. I tried it just now. Windows pulls up a “making sure it’s you” box, with no buttons other than cancel, and no option to use the passkey from elsewhere. This computer doesn’t have a passkey, what is windows doing?
But when I did play with them a bit it seemed so full of weird pitfalls. Aren’t I supposed to be able to use my phones passkey to login on my PC with a QR code? I never got that to work. The article implies that might be a windows 10 vs 11 issue- but why? It’s a QR code. Windows 10 should be capable of displaying a QR code. I tried it just now. Windows pulls up a “making sure it’s you” box, with no buttons other than cancel, and no option to use the passkey from elsewhere. This computer doesn’t have a passkey, what is windows doing?
There is a Bluetooth part of the spec too. If your phone can’t talk to your computer via Bluetooth it won’t work.
[deleted]
QR codes are usually the fallback method, I believe, because they're clunky and they suck if you need to do it more than once per week.
Laptops and phones use Bluetooth Low Energy (among others) to communicate (CTAP 2.2) which is what your computer may be waiting on.
I can't tell you why you couldn't log in, I use Bitwarden's passkeys and they work reliably for me. If you want the added security your phone's hardware encryption provides, I believe there are a few annoyances, particularly with the way Android 13 and lower, but I haven't had to look into those yet.
Laptops and phones use Bluetooth Low Energy (among others) to communicate (CTAP 2.2) which is what your computer may be waiting on.
I can't tell you why you couldn't log in, I use Bitwarden's passkeys and they work reliably for me. If you want the added security your phone's hardware encryption provides, I believe there are a few annoyances, particularly with the way Android 13 and lower, but I haven't had to look into those yet.
Conflict of interest coming from a company selling passkey implementation.
I'm honestly bamboozled why anyone gives passkeys the time of day, given the mess that is attestation and its ability to enforce user-hostile ecosystem lockin:
https://github.com/keepassxreboot/keepassxc/issues/10407
https://news.ycombinator.com/item?id=39698502
https://news.ycombinator.com/item?id=39706876
In principle, it's a great idea. This specific implementation should be treated as DoA because of how attestation works.
https://github.com/keepassxreboot/keepassxc/issues/10407
https://news.ycombinator.com/item?id=39698502
https://news.ycombinator.com/item?id=39706876
In principle, it's a great idea. This specific implementation should be treated as DoA because of how attestation works.
I still don't understand what problem passkeys solve for me that my random passwords in my password manager didn't already solve. This is both about threat model and credentials management.
Threat model: it seems to me that passwords protects against whom I want to be protected against.
Credentials management: I sync my password manager db across my devices. If I lose one device for any reason, I have the passwords on the other ones and in the backup.
Threat model: it seems to me that passwords protects against whom I want to be protected against.
Credentials management: I sync my password manager db across my devices. If I lose one device for any reason, I have the passwords on the other ones and in the backup.
> I still don't understand what problem passkeys solve for me that my random passwords in my password manager didn't already solve.
I just don't understand them at all. As in, I somehow can't just wrap my head about that they are.
My current understanding is that they are like NIH client TLS certificates, but whose content you can never even read (not even the encrypted bytes), that you can't backup (because you can't read), and that's why you have to use a proprietary device with custom hardware from a random company to act as a middleware between your actual secrets (hidden in-device) and you, and trust that device and company to handle the auth for you.
At least that's my current understanding, as far as the details I could find about them (my search terms seem to be failing me). If I could understand them better, maybe I wouldn't be so pessimistic.
So, given that that's how they look to me, they rank pretty low in my trust scale of stuff that I should let handle my auth, including ownership of any secret material. That scale currently looks like this (most trusted first):
(1) Open source software > (2) Desktop computer components that you can plug into motherboard > (3) Smartphones > (4) Let Google/Apple/Microsoft generate and control my secrets > (5) USB sticks from random companies.
(P.S.: Yes, computer components are closed, but even if I don't completely trust them they still rank higher based just on them having existed for longer, so you kinda know what to expect and how incidents are handled.)
I just don't understand them at all. As in, I somehow can't just wrap my head about that they are.
My current understanding is that they are like NIH client TLS certificates, but whose content you can never even read (not even the encrypted bytes), that you can't backup (because you can't read), and that's why you have to use a proprietary device with custom hardware from a random company to act as a middleware between your actual secrets (hidden in-device) and you, and trust that device and company to handle the auth for you.
At least that's my current understanding, as far as the details I could find about them (my search terms seem to be failing me). If I could understand them better, maybe I wouldn't be so pessimistic.
So, given that that's how they look to me, they rank pretty low in my trust scale of stuff that I should let handle my auth, including ownership of any secret material. That scale currently looks like this (most trusted first):
(1) Open source software > (2) Desktop computer components that you can plug into motherboard > (3) Smartphones > (4) Let Google/Apple/Microsoft generate and control my secrets > (5) USB sticks from random companies.
(P.S.: Yes, computer components are closed, but even if I don't completely trust them they still rank higher based just on them having existed for longer, so you kinda know what to expect and how incidents are handled.)
> I somehow can't just wrap my head about that they are.
Passkeys are just resident webauthn credentials. Nothing more complicated than that.
> and that's why you have to use a proprietary device with custom hardware from a random company to act as a middleware between your actual secrets (hidden in-device) and you, and trust that device and company to handle the auth for you.
There's a few open source password managers that support passkeys now.
Passkeys are just resident webauthn credentials. Nothing more complicated than that.
> and that's why you have to use a proprietary device with custom hardware from a random company to act as a middleware between your actual secrets (hidden in-device) and you, and trust that device and company to handle the auth for you.
There's a few open source password managers that support passkeys now.
> Passkeys are just resident webauthn credentials. Nothing more complicated than that.
THIS is the explanation that I was looking for. Short and straight to the point.
Thanks!
THIS is the explanation that I was looking for. Short and straight to the point.
Thanks!
The problem they solve is that almost nobody uses a password manager. The vast majority of people log in using PartnerNameYearOfBirth or Password123 and about two decades of trying to get people to stop doing that have failed.
For people using password manager implementations, passkeys also add a layer of protection by being practically unphishable. This comes at the restriction of companies not being able to drop the domain names they once used to set up authentication (there is tooling for migrating between domains, though) as passkeys bound to old domains won't be valid for new ones.
If passkeys are implemented well, using hardware encrypted storage, you also never risk a copy of your passwords falling into the wrong hands when you get infected by malware. Synchronised password databases are vulnerable to basic key loggers in a way that passkeys aren't.
For people using password manager implementations, passkeys also add a layer of protection by being practically unphishable. This comes at the restriction of companies not being able to drop the domain names they once used to set up authentication (there is tooling for migrating between domains, though) as passkeys bound to old domains won't be valid for new ones.
If passkeys are implemented well, using hardware encrypted storage, you also never risk a copy of your passwords falling into the wrong hands when you get infected by malware. Synchronised password databases are vulnerable to basic key loggers in a way that passkeys aren't.
> The problem they solve is that almost nobody uses a password manager.
Numbers pulled from Google seem to suggest 1/3 or so, which probably varies a lot across the world. But that’s not too bad given it’s never really been shoved down users' throats. They’ve been pushed pretty hard in PC magazines and media. They’re not entirely obscure.
> For people using password manager implementations, passkeys also add a layer of protection by being practically unphishable.
True, but it’s still some protection: auto-fill won’t work on a different domain so phishing is harder. However, note that many legit sites, even payment gateways etc, use multiple strange-looking domains sometimes. This is beyond irresponsible imo, and the clear fault of the service provider.
> If passkeys are implemented well, using hardware encrypted storage, you also never risk a copy of your passwords falling into the wrong hands[…]
This is only theoretically true. Regular people aren’t able to provision and secure multiple auth devices in case of house fire, theft, or loss. What happens in practice is an account recovery flow, usually through email, sms or support, which is prone to all kinds of non-crypto attacks, including phishing.
Per-device passkeys alone are possibly an improvement in convenience but not as a last-resort identity, in practice. From a security POV it’s very similar to pw managers, and so far I like them more because of they’re vendor agnostic. Ideally we’d have pw managers simply manage key material instead of a random pw, when supported by the provider. I already use GitHub this way, with Bitwarden.
Numbers pulled from Google seem to suggest 1/3 or so, which probably varies a lot across the world. But that’s not too bad given it’s never really been shoved down users' throats. They’ve been pushed pretty hard in PC magazines and media. They’re not entirely obscure.
> For people using password manager implementations, passkeys also add a layer of protection by being practically unphishable.
True, but it’s still some protection: auto-fill won’t work on a different domain so phishing is harder. However, note that many legit sites, even payment gateways etc, use multiple strange-looking domains sometimes. This is beyond irresponsible imo, and the clear fault of the service provider.
> If passkeys are implemented well, using hardware encrypted storage, you also never risk a copy of your passwords falling into the wrong hands[…]
This is only theoretically true. Regular people aren’t able to provision and secure multiple auth devices in case of house fire, theft, or loss. What happens in practice is an account recovery flow, usually through email, sms or support, which is prone to all kinds of non-crypto attacks, including phishing.
Per-device passkeys alone are possibly an improvement in convenience but not as a last-resort identity, in practice. From a security POV it’s very similar to pw managers, and so far I like them more because of they’re vendor agnostic. Ideally we’d have pw managers simply manage key material instead of a random pw, when supported by the provider. I already use GitHub this way, with Bitwarden.
> True, but it’s still some protection: auto-fill won’t work on a different domain so phishing is harder. However, note that many legit sites, even payment gateways etc, use multiple strange-looking domains sometimes. This is beyond irresponsible imo, and the clear fault of the service provider.
Which is why the Passkeys spec clearly spells out this responsibility to the service providers and breaks if they get it wrong, truly making it their problem to solve. (It's the direct source of most of the complications described in the linked article's section #13, and indirectly mentioned in other sections.) Passkeys are domain specific and only domain specific and browsers do and will enforce that. It does what auto-fill can't and if a service provider uses multiple domains and gets things wrong, they are broken and have a service outage on their hands to fix, rather than "maybe they temporarily changed domains" still being a phishing vector for those relying on auto-fill as an anti-phishing deterrent (that still catches people that should know better because too many well known services are unreliable about temporarily jumping domains or just plain using way too many domains due to internal silos that shouldn't be so visible externally [cries in Azure]).
Which is why the Passkeys spec clearly spells out this responsibility to the service providers and breaks if they get it wrong, truly making it their problem to solve. (It's the direct source of most of the complications described in the linked article's section #13, and indirectly mentioned in other sections.) Passkeys are domain specific and only domain specific and browsers do and will enforce that. It does what auto-fill can't and if a service provider uses multiple domains and gets things wrong, they are broken and have a service outage on their hands to fix, rather than "maybe they temporarily changed domains" still being a phishing vector for those relying on auto-fill as an anti-phishing deterrent (that still catches people that should know better because too many well known services are unreliable about temporarily jumping domains or just plain using way too many domains due to internal silos that shouldn't be so visible externally [cries in Azure]).
Thanks for clarifying. And I agree with you. Users doing manual domain matching by gut feeling and glancing on the critical path was not a great idea, but made even worse by jittery companies who confused DNS with their org chart. So in that sense passkeys are superior, even to (traditional) pw managers. I’d be the first to cheer for a great passkey integration in my pw-manager of choice.
What I worry about is that companies will (yet again) grossly misuse improved auth technology to make the combined auth flows an even bigger shit mound than it already is, both for users and the poor souls who have to implement them. I don’t know exactly how, but I’m sure they’ll find a way.
What I worry about is that companies will (yet again) grossly misuse improved auth technology to make the combined auth flows an even bigger shit mound than it already is, both for users and the poor souls who have to implement them. I don’t know exactly how, but I’m sure they’ll find a way.
What all big platforms encounter is that the actual attacker already knows the password. That is because (1) it has been leaked on another platform and the user uses the same or (2) because it has been stolen from the computer of the user or (3) the user gave it away voluntarily because he has been phished. Most of the time it is (1) and (3). On Hacker News, we are a very tech-savvy group, and I agree if you stick to your approach that's secure. In a bigger view, that is absolutely not the reality for big B2C platforms. With passkeys (1) and (3) technically impossible and (2) is nearly impossible. Does that make sense?
The problem is that, while your setup has excellent de-facto security, what matters is security posture. The parties that you authenticate to do not know and cannot know that your actual security is better than your posture visible to them. They have nothing to rule out the hypothesis that you use the same password everywhere else, and they still suspect that you can, by mistake, enter the same password on a phishing site.
By using passkeys, you prove to the relying parties that you do not use the same credential on another possibly insecure (hackable) website and that the browser will not reuse the credential for you on a phishing site, as it is technically impossible.
EDIT: all of the above is based on the marketing materials. I do not have any passkeys, but I use my Nitrokey U2F for 2FA on some important websites. I will possibly switch once platform-level or browser-native support for passkeys (as opposed to extensions like the ones provided by BitWarden or KeePassXC) is available on desktop Linux.
By using passkeys, you prove to the relying parties that you do not use the same credential on another possibly insecure (hackable) website and that the browser will not reuse the credential for you on a phishing site, as it is technically impossible.
EDIT: all of the above is based on the marketing materials. I do not have any passkeys, but I use my Nitrokey U2F for 2FA on some important websites. I will possibly switch once platform-level or browser-native support for passkeys (as opposed to extensions like the ones provided by BitWarden or KeePassXC) is available on desktop Linux.
the principle is the reason why I am staying up to date on this. In principle I would feel better if the stuff stored in my bitwarden account are hardware related keys that do not help an attacker even if they guessed my master password and downloaded them all. I consider that an important security benefit... although honestly at this point I don't even know anymore if this is still true given that passkeys now sync across hardware... surely...
Disclaimer: I am a Corbado Co-Founder.
I have commented further down, and I really think that, from a broader perspective, there is a great chance that there will be strong positive effects for consumers. I agree that there is a threat with attestation being used to lock out certain implementations. On the other hand, the technical details do not allow that because the IDs can be changed easily. Also, there is no attestation enforced for passkeys, and that should stay that way. But I agree with one concern: If Apple or Google wanted to achieve such things, they could, just because of their market dominance in browsers. However, I just do not see how that would make sense for them from an economic perspective.
I have commented further down, and I really think that, from a broader perspective, there is a great chance that there will be strong positive effects for consumers. I agree that there is a threat with attestation being used to lock out certain implementations. On the other hand, the technical details do not allow that because the IDs can be changed easily. Also, there is no attestation enforced for passkeys, and that should stay that way. But I agree with one concern: If Apple or Google wanted to achieve such things, they could, just because of their market dominance in browsers. However, I just do not see how that would make sense for them from an economic perspective.
I tried out making a passkey on passkeys.io just now. On an Android phone, up-to-date OS, Bitwarden set as the preferred password manager, the "create a passkey" button, when tapped, switches to a loading spinner very breifly, then resets. Nothing else happens. I guess I'm not going to be using any passkeys.
I have a nodejs passkey implementation over at AuthC https://github.com/authcompanion/authcompanion2 a simple user management server. For javascript developers https://github.com/MasterKale/SimpleWebAuthn has been a good way to get started with a poc before venturing deeper into webauthn (passkeys) spec.
Two assumptions I have, and I'd love for people to shoot me down on this:
1. Most applications will get "Passkey" support by dint of OIDC SSO support; OIDC IdPs are the things that will implement Passkeys (SIWA and SIWG for "retail" users).
2. Direct Passkey adoption in applications will round towards zero, maybe excepting huge applications like Insta; people will do Passkeys with their Google account, but not with (say) Doordash.
If those premises hold, I probably don't need to be sold (though this post is helpful and incredibly detailed) on why not to do my own direct implementation of Passkeys; it makes more sense for us to nail OIDC.
1. Most applications will get "Passkey" support by dint of OIDC SSO support; OIDC IdPs are the things that will implement Passkeys (SIWA and SIWG for "retail" users).
2. Direct Passkey adoption in applications will round towards zero, maybe excepting huge applications like Insta; people will do Passkeys with their Google account, but not with (say) Doordash.
If those premises hold, I probably don't need to be sold (though this post is helpful and incredibly detailed) on why not to do my own direct implementation of Passkeys; it makes more sense for us to nail OIDC.
100% That is exactly how it is playing out. People do not register (2passkeys * 20 services). They sign in with Google or Microsoft and call it a day. Privacy implications ignored.
Even more true in Corp IT. People will learn to use passkeys with SSO at the office and take those habits home.
Even more true in Corp IT. People will learn to use passkeys with SSO at the office and take those habits home.
Corp IT is starting to ram passkeys down everyone’s throats hard, so I expect this effect will start to happen in the next year or so.
TBH, this is better than custom UI that blocks password manager copy paste.
> Doordash
I would assume apps that are non-geek oriented will do quicker adoption. In my experience, many people are looking at passkey like a
- Password manager that is automatically working fine on their phone - Apple or Google takes care of everything. And users think of it like 'Sign in with Google/Apple equivalent'. Press fingerprint/face-ID and all just works.
Only PITA I expect is that banks type dinosaurs will screw up this (like they did with 2FA - with custom apps and non-standard implementations). I wish W3C would some way ban these but banks are somehow escaping standards.
I would assume apps that are non-geek oriented will do quicker adoption. In my experience, many people are looking at passkey like a
- Password manager that is automatically working fine on their phone - Apple or Google takes care of everything. And users think of it like 'Sign in with Google/Apple equivalent'. Press fingerprint/face-ID and all just works.
Only PITA I expect is that banks type dinosaurs will screw up this (like they did with 2FA - with custom apps and non-standard implementations). I wish W3C would some way ban these but banks are somehow escaping standards.
What you're saying mostly makes sense to me, but there's one big edge-case that I care about.
For my own applications I like to have my staff-level admin access work independently of external providers. I don't want to run into a situation where my Google account (or some other SSO service) has been accidentally banned by a weird machine learning algorithm hiccup and now I can't sign into my own service's dashboard to sort out problems.
Admin accounts are also exactly the kind of thing that I want to have my own 2FA for - so passkeys are ideal for them.
So yeah, Passkeys for retail users is something I'll outsource to an IdP, but I'm still very interested in them for my own "staff-level" administrative accounts.
For my own applications I like to have my staff-level admin access work independently of external providers. I don't want to run into a situation where my Google account (or some other SSO service) has been accidentally banned by a weird machine learning algorithm hiccup and now I can't sign into my own service's dashboard to sort out problems.
Admin accounts are also exactly the kind of thing that I want to have my own 2FA for - so passkeys are ideal for them.
So yeah, Passkeys for retail users is something I'll outsource to an IdP, but I'm still very interested in them for my own "staff-level" administrative accounts.
Yeah that’s a break glass account situation. Even with a self hosted IdP solution, it going down isn’t going to perform the OIDC SSO dance to get into whatever service so having that backup account or fallback authentication access is important.
Disclaimer: Co-Founder Corbado here. B2C Auth is much harder than people think. Consumers are unforgiving when it comes to UX. Big Tech sets the bar pretty high for what consumer experience should be. In B2B or B2E authentication, the UX is often horrible, but there is no choice for the user. He has to log in. On e-commerce sites, there are plenty of alternatives. At the same time, protecting customers becomes increasingly difficult; they just reuse passwords or lose them somehow. We think consumers will demand "Face-ID Login for the Web" (consumer simplification), which, from their point of view, is very simple. Even simpler than Social Login.
OIDC implementations for consumers are often not good enough; we have seen other companies promote them for Passkeys. We think that can be suitable for B2B-Auth but not for B2C
OIDC implementations for consumers are often not good enough; we have seen other companies promote them for Passkeys. We think that can be suitable for B2B-Auth but not for B2C
What percentage of Doordash customers do you think log in with a direct account, as opposed to Facebook or Google?
It is difficult to say, but there are some reservations people have because sometimes they are not sure what exactly happens with social login, or they have one Google Account associated with the wrong email, and they do not want to use it. Google Social is particularly strong on Android, of course, but in general, there have been different numbers published ranging from a 15-65% take rate depending on the product, the target group (age), and how strongly it is positioned within the product. In our own numbers, we can see that when offered social in parallel to passkeys, 30-40% go with social sign-up but much less for login when a passkey is added (of course, on our page, there is a heavy early adopter skew pro passkeys).
I don't think your assumptions are holding empirically, though.
https://passkeys.directory/
https://passkeys.directory/
Yes, I agree. We still have passwords although Social Logins have existed for years. And Passkeys are also adopted because they increase security from a 2FA perspective.
2. means having your Google Account blocked locks you out of every other site, thus i will not use passkeys on sites that require login through Google.
Fear, uncertainty and doubt is the sword Corbado wants to live by, so it's the sword it should die by. You shouldn't trust Corbado with your users because the risk is too high and there are much more trusted solutions such as Auth0. Its implementation of passkeys is much more user-friendly. It doesn't require users to enter their email address. On my Mac, for example, it's one click, one fingerprint, then I'm in.
Passwords may not be ideal but I will always take them (with 2FA/YK) over passkeys... the latter is just asking for trouble :/
I'd honestly prefer a standard login page (or aria fields well defined for all inputs) so my password manager could click 'login' automatically.
On the other hand, most Password Managers now support Passkeys, including Bitwarden.
On the other hand, most Password Managers now support Passkeys, including Bitwarden.
As a password manager user, nothing really changes. As you pointed out, you can use them on any major platform to actually hold your passkeys. The thing is, in the broader scale, password manager use is very low among average consumers. Passkeys are a form of built-in secure password manager for all consumers, without any action needed. This thread is full of different views, and there are also downsides to it, but in this sense, it's a free upgrade in security for the majority of consumers.
[deleted]
Would it not be best if Passkey authorization was implemented as a service, so that not everybody have to re-implement the same thing?
No, decentralisation is a positive aspect of the internet.
[deleted]
Behind the scenes, 10+ companies are working on passkey export / import
Great write up though, thanks for this
Great write up though, thanks for this
Thanks. We have heard that also and we would appreciate it. In my experience, it is already difficult to find a technical compromise within a team of 5 people who like each other and work together for years. Finding a solution on the current scale of passkeys is really a big effort and at the end it also needs to be implemented, so I would not be surprised if it takes a long time for this to happen. Do you have an estimate?
Dumb question: are passkeys essential a “login token” (binded to a device)?
No. Passkeys aren't device bound but they are a challenge response protocol so no token transits the wire during auth flows. It’s why they are cryptographically more secure than a shared secret (token). However most implementations take the result of a passkey login and issue a session token so…
AFAIK passkeys are not a protocol. They are cryptographic key pairs (public and private keys). Private key is stored on a device and public key on a server. Private key often is device bound, and it never leaves the device. That's where a challenge response protocol comes in. It enables to provide proof of private key ownership without exposing the private key and it should also prevent replay attacks.
No. A _passkey_ is a syncable non-attested key pair used during wenauthn flows, by definition.
> challenge response protocol
What’s does that mean?
(Sorry for noob question)
What’s does that mean?
(Sorry for noob question)
> However most implementations take the result of a passkey login and issue a session token so…
Is there a way to avoid this and use token for every request in real world?
I mean, that’s an interesting idea, but I think it’s not going to work in practice (can’t make user show face or touch a token on every request). Please let me know if I’m wrong here!
Is there a way to avoid this and use token for every request in real world?
I mean, that’s an interesting idea, but I think it’s not going to work in practice (can’t make user show face or touch a token on every request). Please let me know if I’m wrong here!
Well, every mutual TLS handshake authenticates again. And then establishes a session key. But if you fire up a new session (new tab?), boom, new mutual authentication. It's just that the private key is stored in a keystore, and not on a device, and you don't need to keep your finger on the fingerprint reader all the time.
You could have every message signed with the sending party's private key, at some performance cost. And that signing could happen in a hardware device. Essentially what happens with hardware wallets for bitcoin.
You don’t have to if you have the notion of an active unlock session.
Have you ever used aws sigv4 for s3 buckets? Pretty ubiquitous example of signed requests in practice.
Have you ever used aws sigv4 for s3 buckets? Pretty ubiquitous example of signed requests in practice.
tldr; It's still a giant mess, and until browser developers get around to fixing it, it's probably better to punt on Passkeys for now.
The question is, can the mess get fixed enough before developers like me give up and move on to something else. I gave up a while ago, figured I'd check back in a few years. My current guess: I'll never have to implement them.
The question is, can the mess get fixed enough before developers like me give up and move on to something else. I gave up a while ago, figured I'd check back in a few years. My current guess: I'll never have to implement them.
That's my current impression as well. The companies involved are more interested in making themselves the center of the universe than in collaborating to address the rather obvious user and developer experience issues. Nobody seems in a hurry to do this.
It's the same reason why previous attempts at federated identity have fizzled out. Both MS and Google loved the idea of the whole world using them exclusively as the only identity provider but then balked at the notion of their users using an identity provider that wasn't them. Passkey is a repeat of this. Apple loves the idea of people using iphones to identify with whatever. Android, not so much. And MS of course wants to keep a tight grip on passkey's used to sign into Office, Windows, etc.
It's the same reason why previous attempts at federated identity have fizzled out. Both MS and Google loved the idea of the whole world using them exclusively as the only identity provider but then balked at the notion of their users using an identity provider that wasn't them. Passkey is a repeat of this. Apple loves the idea of people using iphones to identify with whatever. Android, not so much. And MS of course wants to keep a tight grip on passkey's used to sign into Office, Windows, etc.
Disclaimer: Co-Founder Corbado here. I think the simplicity actually for the user is why they are so successful already. I can understand a lot of the criticism, although I am not that skeptical regarding the lock-in. I think this discussion is probably already lost with most consumers having their life within Google or Apple cloud via the mobile phone. Although the discussion is valuable, it should not be held over passkeys.
For passkeys, we truly believe even if those options are weighed against each other, the benefits are weighing more. Big consumer-facing platforms have huge problems securing accounts for users. If you force them to use classic MFA (SMS or TOTP), the usage drops and recovery/fallback processes skyrocket. They don't want MFA. Risk-based MFA can help but is not perfect as attacks get more precise.
So we think the adoption will be faster than browser developers can get around fixing all of the issues, because once a standard is adopted, it gets more and more difficult to streamline things. But we are looking forward to it.
Of course, we see it that way, because we are building a company around it, but I have been battling against account takeover for years and took great pride in trying to protect the data as a developer, our users entrusted us. So I see a real chance here to improve security in the consumer market.
For passkeys, we truly believe even if those options are weighed against each other, the benefits are weighing more. Big consumer-facing platforms have huge problems securing accounts for users. If you force them to use classic MFA (SMS or TOTP), the usage drops and recovery/fallback processes skyrocket. They don't want MFA. Risk-based MFA can help but is not perfect as attacks get more precise.
So we think the adoption will be faster than browser developers can get around fixing all of the issues, because once a standard is adopted, it gets more and more difficult to streamline things. But we are looking forward to it.
Of course, we see it that way, because we are building a company around it, but I have been battling against account takeover for years and took great pride in trying to protect the data as a developer, our users entrusted us. So I see a real chance here to improve security in the consumer market.
When it comes to security, having to paper over buggy, not well realized implementations is just asking for disaster.
You want your security code to look and act and BE boring. Nothing about Passkey's fits that definition at the implementation or code level.
The idea IS awesome, the implementation is terrible. Not because they were awful developers that implemented it, but because it got rushed to production before it was ready. If they continue to iterate and fix the issues and make the implementation boring, close off all the edge cases, etc. Then it will be amazing and I'll praise passkeys. Until then, I'm afraid it's a new x.509/client TLS cert in the browser disaster waiting to happen.
You want your security code to look and act and BE boring. Nothing about Passkey's fits that definition at the implementation or code level.
The idea IS awesome, the implementation is terrible. Not because they were awful developers that implemented it, but because it got rushed to production before it was ready. If they continue to iterate and fix the issues and make the implementation boring, close off all the edge cases, etc. Then it will be amazing and I'll praise passkeys. Until then, I'm afraid it's a new x.509/client TLS cert in the browser disaster waiting to happen.
We added passkeys to existing password authentication for a python flask app, and it took about 40 hours. 20 hours to get basic registration/authentication working, and another 20 hours to tweak the UX (things like popping up a "Want to use passkeys?" dialog occasionally, a passkeys page so users can manage them - all huge problems according to the article).
So please don't put passkeys in the too-hard basket after reading this article. Users love them, and they are going to be ubiquitous very soon.