4 ms·

The issues the article raises are real, but it paints passkey implementation as much harder than it actually is. It's in Corbado's interests to exaggerate the d

The issues the article raises are real, but it paints passkey implementation as much harder than it actually is. It's in Corbado's interests to exaggerate the difficulties. 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.

bendavis381 2y ago
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?
- p0seidon 2y ago
  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?
- foxylad 2y ago
  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.
doctorpangloss 2y ago
Why not use Keycloak, then add OIDC to your Flask app, in 4h?
- moooo99 2y ago
  I think Keycloak is always the wrong choice if you’re looking to simplify your authentication stack
8n4vidtmkvmk 2y ago
So not a weekend project but not crazy hard. Probably still rules it out for my hobby apps.
- rkeene2 2y ago
  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.
  - recursive 2y ago
    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.
    - rkeene2 2y ago
      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.tcl https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...
      - michaelt 2y ago
        Implementing SAML from scratch should take a long time - it's one of the most footgun-prone designs I've ever seen.
dcow 2y ago
https://passkeys.directory/ 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.
- 1oooqooq 2y ago
  > have implemented support for passkeys Why do you assume they have also implemented correctly for all cases?
  - p0seidon 2y ago
    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.
    - 1oooqooq 2y ago
      is it honestly better than TOTP in terms of security, ease of implementing "correctly*, and convenience?
MyFedora 2y ago
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.
WorldMaker 2y ago
> 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.
- p0seidon 2y ago
  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.

bendavis381 2y ago

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?

p0seidon 2y ago
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?
foxylad 2y ago
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.

doctorpangloss 2y ago

Why not use Keycloak, then add OIDC to your Flask app, in 4h?

moooo99 2y ago
I think Keycloak is always the wrong choice if you’re looking to simplify your authentication stack

8n4vidtmkvmk 2y ago

So not a weekend project but not crazy hard. Probably still rules it out for my hobby apps.

rkeene2 2y ago
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.
- recursive 2y ago
  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.
  - rkeene2 2y ago
    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.tcl https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...
    - michaelt 2y ago
      Implementing SAML from scratch should take a long time - it's one of the most footgun-prone designs I've ever seen.

dcow 2y ago

https://passkeys.directory/ 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.

1oooqooq 2y ago
> have implemented support for passkeys Why do you assume they have also implemented correctly for all cases?
- p0seidon 2y ago
  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.
  - 1oooqooq 2y ago
    is it honestly better than TOTP in terms of security, ease of implementing "correctly*, and convenience?

MyFedora 2y ago

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.

WorldMaker 2y ago

> 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.

p0seidon 2y ago
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.