Passkey Implementation: Misconceptions, pitfalls and unknown unknowns
corbado.com
corbado.com
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.
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.
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.
[0] https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...
Why do you assume they have also implemented correctly for all cases?
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.
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...
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?
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.
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)
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.
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 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".
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.
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.
Make the fallback too lax and you might as well not bother with 2FA/Passkeys at all.
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.
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.
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.
That would be glorious. It would be great if it was standards-based, too, to prevent vendor lock-in.
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...
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.
Bruh
This is akin to CA/B Forum threatening to ban use of OpenSSL because it has a -nodes flag.
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 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?
> 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!
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."
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 would love to use a hardware device in lieu of a password manager. I just need a tolerable backup/restore scenario.
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.)
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
"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.
https://news.ycombinator.com/item?id=35855133 ("HN: Passkeys will be importable, exportable, cross-device, and across managers")
Because that affects my choice to adopt them today.
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).
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”)
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
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$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.
We're a year later and the needle didn't move on this. Which is a bit worrying
Passkeys are webauthn credentials. Store them in whatever webauthn store you like. I use a combination of bitwarden and iCloud.
Passkeys are residential keys and they consume storage. The minor upside is that they free the user from remembering their username.
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.
- 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...
https://github.com/settings/security (Passkeys section)
https://docs.github.com/en/authentication/authenticating-wit...
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.
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.
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).
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.
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.
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
use a third party manager like Strongbox to avoid faang and biometrics if you want.
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".
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.
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.
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.
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?
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.
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.
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.
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.
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.
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]).
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.
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.)
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.
THIS is the explanation that I was looking for. Short and straight to the point.
Thanks!
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.
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.
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.
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.
Even more true in Corp IT. People will learn to use passkeys with SSO at the office and take those habits home.
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
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.
On the other hand, most Password Managers now support Passkeys, including Bitwarden.
Great write up though, thanks for this
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!
Have you ever used aws sigv4 for s3 buckets? Pretty ubiquitous example of signed requests in practice.
What’s does that mean?
(Sorry for noob question)
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.
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.
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.
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.