> have implemented support for passkeys

Why do you assume they have also implemented correctly for all cases?

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

That is probably because their implementation was released prior to Firefox implementing passkeys, and they have not yet updated their system.

Are you from Austria by any chance? So this is why I can't provision my yubikey for government authentication?

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?

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.

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.

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.

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.

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.

basically this https://news.ycombinator.com/item?id=39706876

Technically correct yet I would not be surprised if they're still quite widely used. And the second part?

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

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

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.

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.

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.

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.

What percentage of Doordash customers do you think log in with a direct account, as opposed to Facebook or Google?

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.

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.

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.

> challenge response protocol

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!

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.