Passkey Implementation: Misconceptions, pitfalls and unknown unknowns

https://www.corbado.com/blog/passkey-implementation-pitfalls-misconceptions-unknowns

by vdelitz • 2 years ago

184 186 2 years ago

okhuman• 2 years ago

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.

grose3• 2 years ago

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/

toomuchtodo5• 2 years ago

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

grose3• 2 years ago

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.

agl2• 2 years ago

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.

grose3• 2 years ago

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.

foxylad3• 2 years ago

We ask the user to name each passkey. One more modal dialog during registration, but seems to work well.

tptacek2• 2 years ago

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.

simonw• 2 years ago

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.

kemotep• 2 years ago

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.

johngalt• 2 years ago

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.

teeray• 2 years ago

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.

dcow6• 2 years ago

I don't think your assumptions are holding empirically, though.

https://passkeys.directory/

p0seidon17• 2 years ago

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.

p0seidon17• 2 years ago

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

tptacek2• 2 years ago

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

throwaway20563• 2 years ago

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.

lo0dot03• 2 years ago

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.

snailmailman• 2 years ago

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?

pat2man• 2 years ago

There is a Bluetooth part of the spec too. If your phone can’t talk to your computer via Bluetooth it won’t work.

jeroenhd4• 2 years ago

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.

zie2• 2 years ago

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.

jillesvangurp• 2 years ago

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.

p0seidon17• 2 years ago

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.

zie2• 2 years ago

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.

CatWChainsaw8• 2 years ago

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.

shepherdjerred• 2 years ago

Passkeys != biometric auth

CatWChainsaw8• 2 years ago

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

iknowstuff• 2 years ago

silly hot take.

use a third party manager like Strongbox to avoid faang and biometrics if you want.

cloverich2• 2 years ago

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.

CatWChainsaw8• 2 years ago

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

jeroenhd4• 2 years ago

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.

CatWChainsaw8• 2 years ago

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

livueta• 2 years ago

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.

Nathanba• 2 years ago

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

pmontra• 2 years ago

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.

p0seidon17• 2 years ago

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?

jeroenhd4• 2 years ago

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.

quectophoton2• 2 years ago

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

patrakov• 2 years ago

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.

p0seidon17• 2 years ago

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.

foxylad3• 2 years ago

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• 2 years 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?

p0seidon17• 2 years 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?

foxylad3• 2 years 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• 2 years ago

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

moooo99• 2 years ago

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

8n4vidtmkvmk• 2 years ago

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

rkeene22• 2 years 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.

dcow6• 2 years ago

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.

1oooqooq7• 2 years ago

have implemented support for passkeys

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

MyFedora3• 2 years 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.

WorldMaker4• 2 years 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.

p0seidon17• 2 years 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.

byyll• 2 years ago

Conflict of interest coming from a company selling passkey implementation.

hedora• 2 years ago

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

umvi2• 2 years ago

You can use yubikeys as passkeys, if you are afraid of a Google/Apple ban

sph2• 2 years ago

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.

galaxyLogic• 2 years ago

Would it not be best if Passkey authorization was implemented as a service, so that not everybody have to re-implement the same thing?

lo0dot03• 2 years ago

No, decentralisation is a positive aspect of the internet.

alberth2• 2 years ago

Dumb question: are passkeys essential a “login token” (binded to a device)?

dcow6• 2 years ago

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…

drdaeman• 2 years ago

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!

zigzag3122• 2 years ago

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.

alberth2• 2 years ago

challenge response protocol

What’s does that mean?

(Sorry for noob question)

__MatrixMan__3• 2 years ago

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.

agl2• 2 years ago

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.

p0seidon17• 2 years ago

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.

1oooqooq7• 2 years ago

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)

michaelt2• 2 years ago

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.

MyFedora3• 2 years ago

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.

4ad2• 2 years ago

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

klabb33• 2 years ago

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?

paranoidrobot2• 2 years ago

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.

p0seidon17• 2 years ago

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

arianvanp2• 2 years ago

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.

__MatrixMan__3• 2 years ago

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.

red_admiral4• 2 years ago

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.

__MatrixMan__3• 2 years ago

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.

steve_taylor• 2 years ago

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.

ktosobcy• 2 years ago

Passwords may not be ideal but I will always take them (with 2FA/YK) over passkeys... the latter is just asking for trouble :/

fifteen1506• 2 years ago

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.

p0seidon17• 2 years ago

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.

ffo5• 2 years ago

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

growse8• 2 years ago

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?

Macha• 2 years ago

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.

wkat42422• 2 years ago

The export is important in case you want to move to a different service or password manager.

lrvick• 2 years ago

You actually can backup your webauthn master seed with a Ledger as a 24 word phrase you write down.

red_admiral4• 2 years ago

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.

JakaJancar• 2 years ago

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?

idle_zealot• 2 years ago

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.

gregorvand• 2 years ago

Behind the scenes, 10+ companies are working on passkey export / import

Great write up though, thanks for this

p0seidon17• 2 years ago

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?

red_admiral4• 2 years ago

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

jmakov2• 2 years ago

Um.. isn't today recommended to use ecdsa for ssh keys?

red_admiral4• 2 years ago

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.

Passkey Implementation: Misconceptions, pitfalls and unknown unknowns

Related Stories