Passkeys will come at a cost

I have the same problem with Google 2FA.

"We sent a notification to your S21".

No, I'm holding my S21 in my hand, unlocked. About 1/3 of the time, there's no notification. Or it takes five minutes to arrive.

This is only one of many problems I've had with Google recently. I went from haphazardly trying to avoid their products for privacy reasons to now putting max effort into minimizing my Google usage because everything they do is badly broken. I've just spent two weeks getting my business re-listed on Maps after it was flagged for no reason. Impossible to talk to a human. They give you a number to call on every support email, but it's for advertising support who can't do anything about a suspended business account and are very surprised (refuse to believe in fact) that the Google business team gives out their number for support. It took me half an hour of repeating the question in different ways for the Google Ads support woman to admit that there is no way to talk to a human about Google Business.

Bitter? Hell, I'm an anti-Google evangelist now.

Nit: Passkeys don't get sent to Android. Instead, the Gmail login would ask you to prove you possess the passkey on the Android by scanning a QR code displayed by the browser.

However I totally get your point. The UX is confusing. The terminology is confusing. Even if each step in the UX gives you an explanation of what it does, it's still useless because people are trained to skip the small print with explanation and click the biggest, most colorful button, especially when they are in a hurry. It's a genuinely hard problem for UX design.

Exactly, I'm seriously considering taking my business off google's ecosystem because of the unwanted "we've sent a notification to your phone" confirmation requirement. I could understand if they did that if I suddenly tried to login from the other side of the world, or let's say I always use Linux and suddenly my browser identifies as windows etc. But if you're running a privacy focused browsers (ungoogled chromium) it happens every single time you're trying to authenticate. From the same IP.

What if my phone is dead? What if I lost it and I'm trying to recover location service credentials by sending a password reset to my email and I can't login? Then the whole "answer some questions" dance starts. If a hidden and unaccountable algorithm decides you running ungoogled chromium on Linux is suspicious and you happen to misremember an answer to some question it might ask (what percentage of available storage are you currently using?) good luck gaining access. BTW, I a paying user of Google.

>Terrible UX by Google

Honestly these days I do a double take when a piece of UI is not terrible.

This sent me over the edge. It forced the realization that Google does not make decisions based on users. I know, I know, obvious - but even though I "knew" that, it had not clicked that obviously they would make decisions BAD for users. Google makes money from advertisers. They provide just enough service to users that does not send them away. And just enough to keep competitors at bay. As long as users don't leave they don't really care -they don't have to care.

This is the way it is. If we want something different we need services not paid for by advertisers. (And no. While google exploits users one way, apple does another. Picking your poison is not a choice).

To be fair, this is really just Google being idiotic with their product UX and has nothing to do with passkeys. I think most anybody would be confused if Google randomly changed their login UX to something users aren’t familiar with.

Honestly, I think if you’re using 2FA, you should also have 2 different ways to provide a 2nd factor (like TOTP or notification to your phone).

Yep, this is how Comcast is for me. I never get the notification for the "registered device" even though it's a newish popular phone. I don't trust passkey because It relies on a certain device, instead of something you can just write down or save to a browser use on multiple devices.

If I lose my phone, I can't get into my email to do anything else.

passkeys are really defined by the FIDO Alliance

Based on FIDO standards, passkeys are a replacement for passwords that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices. Unlike passwords, passkeys are always strong and phishing-resistant.

[1] https://fidoalliance.org/passkeys/

> I have always understood that Apple defined a Passkey to be a key pair that is synced through iCloud Keychain. Even their WWDC 2021 presentation distinguishes passkeys to be different than security keys because they are "always with you" (the device sync aspect) and "recoverable". I think the definition was later extended to other cloud sync methods.

Their goal was an industry initiative, not an Apple Passkey product. By the time they were released in 2022, the definition loosened to be an experience, e.g. discoverable and providing the option for user verification.

The user can choose whether or not to use a passkey provider that is backed up/recoverable, and the relying party gets a signal to this effect. They might use this signal to determine whether to prompt to remove the password login option.

> how attestation is handled (and can be trivially abused to kill companies)

What's this issue?

I think this is not as bad as attestation abuses.

My guess of what will happen is if a service sets `rk=required` and you are on a platform that doesn't want to (or can't) enable/support it, the process would always fail and you wouldn't even be able to register. Which seems like a shoot-yourself-in-the-foot kind of move if the goal is to onboard users and get more business...

I'm pretty sure the goal here is to turn your phone into your passkey, _and nothing else_. Everything written in that article makes sense if you keep that in mind.

It's a poorly argued point, agree. Essentially the author is arguing that the ability in the WebAuthN protocol for Relying Parties to be able to specify `rk=required` is considered harmful because it excludes tons of TPM hardware from being able to work as a Passkey wallet/db. I think most people in the comments probably agree. That doesn't excuse all the confusion the author creates by essentially bike-shedding the definition of passkey for half the essay.

I believe the primary point is that WebAuthn is being pushed to use a "passkey" model where each site creates a credential that consumes storage. Displayable site and user account names, a user record handle, and the private key all take up storage, along with a few other items.

A mobile phone could store 10 thousand passkeys without breaking a sweat. Modern hardware keys might only be able to store 25 total in available flash.

The reason for wanting this storage is discoverability - the ability to hit say GitHub.com's new passkey support on the login page, and log in without having to even type in an account name. The browser provides a password manager-like experience. Just like passwords in a password manager, the passkey locally becomes a record of an account on a site.

However, WebAuthn also has quite a few other, non-passkey modes. Non-discoverable credentials expect you to provide a list of handles for a particular user account, which were provided by the keys as part of registration. Only credentials which match a handle are given as options during authentication. For hardware security keys, they leverage this to actually store the record needed for the future cryptography in the handle itself - this mode doesn't take up flash storage.

So the user would type their username, some API returns a list of handles, and this could be used against a security key to authenticate - without no storage limitations.

The problem with this argument IMHO is that a lot of sites take a policy of not revealing if an account exists or not. We've seen recovery processes that say "if this account exists, you should receive an email shortly". A login process that provides an API to detect if a username or email address has an associated account and how many credentials have been recorded against it may simply not be acceptable to the site.

It seems more likely that we eventually have security keys with 10x the available storage, rather than sites adopting this process widely enough to make an impact against the current hardware limits.

The article assumes quite a bit of knowledge of FIDO2 and your confusion is understandable.

> How/why? What's the connection to passkeys or HSMs?

Passkeys are implemented on top of FIDO2 and specifically utilise the "resident key" functionality of the FIDO2 spec (according to the article; I don't personally understand passkeys). FIDO2 hardware authenticators are not HSMs exactly, though they are similar and some devices (like Yubikeys) are both HSMs and FIDO2 authenticators.

> Yeah okay... does this imply that all resident keys are discoverable keys? Or that all discoverable keys are resident keys? Or both?

In FIDO2 "resident key" and "discoverable key" are synonymous. "Resident key" is the term used in the spec, however "discoverable key" is commonly used. One of many such cases of FIDO creating confusing terminology.

> No. Does "keys" here mean passkeys? Or keys stored on HSMs? Or both? Or something else entirely?

Neither, it refers to FIDO2 hardware authenticators (e.g. Yubikeys) which are commonly referred to as "security keys".

> Okay so an HSM can apply to an unlimited number of accounts because it can store... some kind of key wrapped in another key (of the same type? different type?)

A FIDO2 hardware authenticator (which is not a HSM per se) can be registered with unlimited accounts because it is effectively stateless; it doesn't store anything (assuming that you are NOT using resident keys, which must be stored).

When the authenticator is registered with an account, it generates a key pair on the device (e.g. an EdDSA key pair). Instead of storing the key pair, it encrypts the private key with the onboard master key (e.g. an AES256 key). It then sends the plain text public key and the encrypted private key to the "relaying party" (e.g. google.com) who stores it. When authentication is attempted, the encrypted private key (i.e. the "wrapped" key) is sent to the authenticator where is decrypted onboard and then used to produce a digital signature.

Note: The FIDO2 does not actually specify how to implement non-resident keys - wrapped keys are just one way of doing it. FIDO2 only requires that the private key must be securely derivable from the credential ID (where the credential ID is actually arbitrary data which may or may not be a wrapped key).

This doesn't really change much, though? My keys can only have 25 resident keys on them, and I also have more than 25 passwords stored in my password manager.

Is there a clear path to a yubikey device supporting 1000+ resident keys and doing so well in the near future?

What does the cost look like? Are we talking $50 or $500?

I just looked a the technical manual for the 5 series, and it only supports 25. I only have two right now, but I have way more than 25 TOTPs.

I don't know what the Bio FIDO ones have, but if it is similar, YubiCo may not have a product well placed for a large number of RKs.

~Edit: The Bio's have the same limit of 25

Why should I be forced to upgrade? Non-resident keys also eliminate weak passwords and password reuse. Using resident keys only add marginal improvement (ie. you can plug in a key and the service knows which account it belongs to), and that doesn't seem like a good justification to deprecate all the existing authenticators in use today.

Can you give me a high level description of why passkeys won't work with my current hardware key, and then explain why they went with that implementation instead of one that works with my current hardware key?

My worry is in the future there may sometimes be no other option than to take this "advantage". If a site implements the new auth standard, will it also keep the current username/password/2fa as an alternative option?

I would go as far and say it's a too charitable take.

Shared residual keys _should not exist_ (outside of short term temporary usage, e.g. not 2FA/FIDO).

They are a liability, they are a security risk, they promote bad security practices.

Best example TOTP (which from a security POV is quite flawed). You don't want to ever share the shared secret across devices (or back it up) but due to it being possible and flawed 2FA implementation being the norm not the expectation you are kinda forced into it. And as thinks look now passkeys will go into the same highly flawed user hostile direction.

Someone using easy to guess simple passwords probably isn’t using a Yubikey and also likely has no interest in getting one at all. Those 2 categories are very different people.

Well no, because a brand new yubikey 5 has the same limit

Just print backup codes or add second "drawer" key. The whole idea is great, but has several issues: very bad marketing, wierd configuration flow for average user, push for airdropable/cloud synced keys (this is a bad idea) and the most important one, the cost of keys.

Wouldn't this include passwords? People lose those all the time.

The proof will be in the pudding, but I suspect that widespread adoption of passkeys will make account lockout less common, rather than more, for the vast majority of people.

I think this is a conscious design choice made to keep these devices as "dumb" as possible. As soon as you add storage, you start opening up the same surface for vulnerabilities as any other storage device, next comes compute and eventually you have a full fledged computer instead of a dumb yubikey.

I don't know if this is the only reason, but mass storage devices seem to have a ludicrously unacceptably high failure rate and short lifetime to be something I key large potions of my life to.

I'm sure they can go up in storage, but the more you add to them the more you increase the chances of fault. And these things currently take a hell of a beating before they don't work anymore.

There is also something a bit more auditable about a smaller storage. Though, even the small sizes are probably pushing the bounds of what can realistically be audited nowadays.

Because secure tamper resistend storage is expensive.

I would even go as far and say from a security POV the best security key is the key which has 0 storage. Because in my experience any protocol which injects and stores a secure token into a security key/enclave/whatever instead of deriving it from shared secrets etc. has serious flaws. Sometimes it's fundamentally security flaws (like TOTP). Sometimes it's complexity flaws. Similar you don't really EVER want to share a secure key for HSK/2FA across multiple devices. It means if one device leaks it it's corrupted for all of them. Instead you want a separate key (oversimplified) on _each_ device. Login provider/server side wise the overhead for this is negligible in the bigger picture.

It's less that they are limited in memory, and more so that they are designed to not have memory limits.

If you look at TPMs, basically each time you want to sign something, your input is the data you want to sign and a sealed private key. The sealed key is the private key that was generated by the TPM and then symmetrically encrypted with the key embedded in the TPM. You store the sealed key in your mass storage, and provide it to the TPM for each signing operation. This design allows you to have as many keys as your mass storage will allow you to save.

Maybe even make it modular. Sell something that looks like a thumb drive but has a slot in the back that you can plug a small security key into (think something with a form factor like a YubiKey Nano).

When a security key is plugged into the slot the thumb drive provides storage for the security key and appears to the computer as a security key.

When a security key is not plugged into the slot the thumb drive functions as an ordinary thumb drive.

You would ordinarily keep the security key plugged into the slot, but if you ever decided you needed more storage you could by a bigger storage module, remove the security key from your old storage module, plug the old module into the computer, copy the encrypted files, plug in the new module, copy the files to it, then plug in the security key.

When I use a Yubikey for passwordless authentication (FIDO2), it challenges me for a PIN before asking me to touch the device. If I give it too many incorrect PINs, the Yubikey locks up and requires a device reset, which invalidates all previous registrations to use that key for authentication. It doesn't seem like a big deal if someone steals my hardware token.

https://support.yubico.com/hc/en-us/articles/4402836718866-U...

I don't see phones as being very different in terms of also being a physical security key.

Yeah, this is basically my take. At this point, the idea everyone is converged on is that you have a locally encrypted secure "vault" of some kind, that you can trust, and you need to verify identity with that system, perhaps with a password and perhaps with a key. It is easier to have some trust that your password manager of choice is more secure, rather than having to assume that every service in existence you create an account for is secure (or unphishable.) So, by the time you use a passkey, you're quite often in a more secure context where you've already established that identity: to your operating system, to your password manager that owns your passkeys, etc.

It also seems likely that places that didn't support hardware keys now or recently probably wouldn't have supported them in the near future. But the ROI for a Passkey solution is likely much higher since the buy in (just some software support) is much easier for people to achieve. Of course, this is only true for websites mainly; a Passkey is basically the equivalent of "Standardized SSH keys" for a website.

I see hardware keys as more useful for second factors like actually unlocking your vault with your passkeys inside of it, which might also want a password. I suspect hardware keys still have a bit of life left in them.

The Passkey login flow is actually super, super nice now that I can use it on GitHub, Gmail, etc as a primary method.

i think they could be great for websites i don't really care about and already use weaker passwords. but for important sites where security matters? nope

If you think about it, the core problem can be described as "authentication of the biological being with an electronic system".

When passwords are used, the authentication interface is a keyboard and you don't have any actual guarantees that the person typing the password is the person who claims to be. The passwords could have been extracted in so many ways because it depends on easily transferable knowledge.

Moving the authentication interface to device2device is actually much better, you no longer assume that the easily transferable knowledge was not transferred. Instead, you assume that the biological being is capable of keeping track of the authentication device and people are naturally good at it.

You can increase the number of authentication channels to tighten it up a bit, you can restrict the authentication of the biological being with the device(FaceID) which will be used for authentication with remote systems but at the core I think it feels right to assume device(phone, key etc.) means the person.

It's also quite a human thing to do. At home, we share not only the Netflix password but one of the credit cards. For practical reason, one credit card stays with the spare keys and when there's something to buy for the house anyone can grab that card and use it. We trust each other that the card would be used properly, everyone knows the pin code but that's rarely needed since contactless payment is the norm anyway. It's much more natural than keeping track of the expenses and then pay each other the outstanding amounts. However, It's probably illegal and if the bank finds out about it, they will cancel the card.

IMHO, the IT systems desperately need to approach human behaviour by working in analogous ways with the real world. Since I'm involved with IT systems I don't struggle most of the time but people who are not that tech savvy are having hard time figuring out daily stuff like What is the iPhone's password for, What is the iCloud password for, what is the Gmail password for, why I need to enter a code in WhatsApp etc.

Actually, I think I struggle too - I never came along to understand Mastadon. I'm prbably defenceless against phishing attacks on Mastadon, I will type whatever the screen tells me to type.

I've been trying to wrap my head around this and my layman understanding is that there's an assumption (but maybe not baked into any requirements/standard) that use of the hardware key is locked behind either a biometric check (FaceID/TouchID/etc) or password. In other words, there might be an implicit second factor baked in to the passkey itself.

I'm not sure that a second factor was ever the goal of 2FA, but rather the desire was a key that users couldn't pick themselves (because they use their birthday, they tell example.com their Google password every time they log in, etc.)

That said, I don't feel great about letting security keys be the only factor. They can be stolen. So can phones, but phones make you unlock them before they'll be your password. (Windows Hello is the same thing.) That seems like the right balance to me. Your phone can authenticate that you are you; a USB dongle can't.

Until there is something like pre-registration ("here are all my keys from all my devices, trust them all" - not possible with current standards) mechanism - I suppose, yes?

I don't really understand if there's any other way to make all this work if not for portable authenticators. How one is supposed to log in from a different machine if it's from a different ecosystem that doesn't have the original passkey (e.g. log in on an iPhone if I've signed up from a non-Apple desktop computer)?

When using a resident/discoverable credential the authenticator is supposed to authenticate the user (using a pin, biometrics, etc.) This fulfills the multi-factor requirement. All passkeys/webauthn credentials are something you have and you can use a something to know/something to are to unlock the credential stored on the authenticator.

> Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them

Yes because the keys have a PIN just for this usecase. Similar to the ATM card or SIM card you already know

Password managers have already made passwords obsolete. I literally don't know any of my passwords except my master one. Passkeys are an insanely overcomplicated solution we don't really need.

Browsers just need a simple HATEOAS API for password managers to hook into, and web apps expose some HTML that triggers the browser. The password manager can then determine how to authenticate the user (however the user wants!), auto-inject the secret for that website, and the user is automatically logged in. E-mail reset if anything goes wrong.

From the "we're a website that wants super fancy security" perspective, I get that they want something more complex. But there should be levels of security that the user can opt-in to.

For example: most websites are fine with a simple password hash, assuming the password manager uses random passwords. Any website can implement that, every password manager can implement that, and it's better than 99% of regular users' password use today. So there's your baseline auth method.

Then if you want something like TOTP, OIDC, public-key crypto, etc the server can advertise it, the client can opt-in to it, and authentication can continue. But not every site needs to implement it, and not every user cares to use it. Basically, we don't need every site and every user to use the most secure methods. We just need to make it easier to get a baseline of improved security, and allow people to slowly opt-in to stronger security.

Physical security keys can have pins.

Realistically, I don't think this will completely replace Yubikeys, nor do I think that only "security nerds" use them.

In reality - the majority of leading organizations use Yubikeys to secure authentication across their company. While it's likely not as common for consumers, it is probably the most trusted solution in the enterprise today.

> Passkeys are meant to be a password _replacement_,

No. Passkeys parasitize on FIDO2 U2F standard, that was developed to be (as the name implies) the second factor. Resident keys are meant for on-device 2FA with PIN, a functional replacement of smart cards.

Someone (Apple maybe) thought it’s a good idea to consider WebAuthn being good enough to be the only authentication factor (no resident keys, no hardware bond, keys are roamed via iCloud) but TouchID/FaceID protected on device. And they branded them as passkeys.

> and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them.

You don’t. 2FA is not a goal on itself. The goal is to have user authentication that is protected from phishing, brute force and credential stuffing, and also not as hard to implement as smart cards.

FIDO2 does that. The problem with Apple’s, Google’s or Microsoft’s implementations is not that they are less secure on a protocol level between the authenticating site and the user’s device, that’s exactly the same protocol. The problem is that the site has now to trust user’s personal account in one of these platforms and that the user did the right thing and also the platforms will always be doing the right thing - e.g., they will handle attacks on user’s personal account properly.

Passkeys combat phishing and sell mobile devices that have secure enclaves, tho the mobile operating software is apparently syncing the master key between devices enrolled in the same subscriber account. However, during MOST urban assaults, phone theft/damage is among the first thing to happen. It’s why all of this phone-as-token crud combined with FaceID are bad ideas that put convenience above security. The government should be pushing everyone into a federal SSO so that this is not needed and so they don’t need to worry so much about encryption.

> Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them.

Hardware security keys that implement FIDO2 UAF can be protected by PINs/passwords or biometrics, the former being "something you know", and the latter "something you are", with the security key itself being "something you have".

Which is why the author mentioned using a pin or biometrics to unlock the hardware security device.

>Passkeys are wonderful for consumer use, because they're meant to enable your own ability to break glass, by backing up the credential to other devices. You can do this via iCloud (by default) or via things like Airdrop.

> Technically, the devices you share this credential to, cannot provide "attestation" - attestation is the "proof" that the keypair was created by a specific device (like a Yubikey, Apple Machine, etc). Manufacturers (like Yubico) ship a keypair / certificate onboard your key, that can't be extracted. There are no external methods to interface with this keypair - granting admins high confidence this is a real Yubikey.

Passkey is not a technical term, but an experience term. So it somewhat falls apart when you use it for technical arguments.

Apple supports passkeys. Android and Chrome support passkeys. Microsoft supports passkeys. Yubikeys supports passkeys.

But the authentication process for user verification and the capabilities/restrictions around things like cloneability may differ wildly.

A government agency may choose to support passkeys, but only when provided by a FIPS-certified authenticator which meets AAL2 requirements. Those won't come from Apple or Google, at least not today.

An enterprise may choose to support passkeys that are generated via software/configuration provided by their MDM management product. Apple announced beta support for this.

However, if you are doing government-to-citizen you may experience a lot of pain trying to mandate those particular hardware authenticators. It will be painful to convince citizens to spend $80+ USD on hardware. It will also be painful because web technologies are built around user choice, and WebAuthn API and user experience are unlikely to ever be optimized to help restrict user choice.

>Passkeys are wonderful for consumer use, because they're meant to enable your own ability to break glass, by backing up the credential to other devices. You can do this via iCloud (by default) or via things like Airdrop.

What happens when Google or Apple decided to ban you for mistake due to anti-bot or anti-fraud detection or whatever ever nonsense?

yubikeys (5) can be used as passkeys

no not far enough

residual keys are IMHO a security misdesign and shouldn't exist

but now the industry hype is pushing to make the the de-facto mandatory way

I don't want to store passkeys in my password manager, the same way that I don't want my TOTPs to be stored in my password manager.

If my 1P/LastPass/BitWarden gets hacked/compromised/pwned by someone across the globe, they still can't compromise my critical services because they don't have my hardware token. I just have to rotate all of my passwords.

If you store everything in your password manager, you've just turned your 2FA/MFA into 1FA.

This is also why you shouldn't copy SSH private keys around, just because "it's easier to only have one fingerprint". Generate one private key per device. This is somewhat mitigated by `-sk` type keys, though. (SK SSH keys are still basically unusable because they are not recognised by a significant amount of versions of SSH, including the default MacOS SSH client).

I think you understand it right. Or, if you are misunderstanding something, I am misunderstanding as well.

We absolutely need to allow soft implementations to exist. The platform providers are already doing this. You should be able to use your password manager as a passkey manager. The RP shouldn't dictate any of this and the protocol should actively resist platforms locking people in to (their) blessed implementations.

Apple doesn't do attestation so if you require that you're already leaving out the biggest platform.

But it's a bad thing for self hosters anyway. Because parties will make exclusive deals or only wish to deal with authenticators they trust (eg that pay them for 'certification')

Passkeys are not tied to hardware. You can save them in iCloud, Bitwarden and lots of other tools. You can also share them to another device [1]

[1] https://developer.apple.com/passkeys/

Isn't the physical key a whole computing device with high grade storage ? I can't imagine those using cheap consumer grade off the shelf storage parts.

You can't just drop in a generic storage IC which are cheap and plentiful.

You need one with a certain degree of verified _good_ encryption mechanisms built in. You do not want it ever communicating with the processor in plain text if you are selling a security device.

I think you mean you see three comments by the same person mentioning that.

They're just using the wrong word.

And how many sane persons will understand what a public ssh key is?

You aren't buying a USB mass storage device when buying a security key. Completely different product, different requirements.

> small fraction of visitors

This site won't work on Windows 7 / Chrome 69 as it only supports TLS 1.3 [1]. I believe 5% of the web can't connect [2].

But the text on the site is for technically minded people and the content includes commands you should run and security configuration. Tampering of the content could be quite harmful.

[1] https://www.ssllabs.com/ssltest/analyze.html?d=fy.blackhats....

[2] https://caniuse.com/?search=tls1.3

In the spirit of the article:

Yes

how does authn happen here?

RP sends ID and I respond with the secret code? that's subject to replay attacks.

I'm pretty sure that is how non-resident keys work on some platforms (like the first gen yubico U2F tokens).

The main feature of resident (aka discoverable) keys is that the RP doesn't need to know anything about which key is about to be used, so it can just say "send me an auth for example.com", and the browser and key handle the rest.

However, with non-discoverable keys, the RP has to provide a reference to the key, which could actually have encrypted private key matter in it.

> Gonna only say this once. Stop building your forts with only one wall and one gate. Build many walls to cross, many gates to open, observe the user through each of these.

Obviously that's better but if you make the user jump through too many hoops they're just going to pick someone else to do business with.

This is why Fido is a good idea, it's not only more secure but also easier. In the security world that's kinda like magic, usually you're end up trading one for the other.

What I don't get is why can't the browser just maintain a list of accounts that it knows work with the non-resident key? The username is not secret information, so why does it need to be held in the key?

This is more of a use of cryptography for authn, not designing the cryptosystem itself.

why is this rated -1? NIST is right up there with DARPA and tennis in terms of unassailable institutions.

Someone gains access to a Passkey. You generate a new Passkey and replace the registered Passkey for the server. Someone gains access to your fingerprints or retina scan... Game over?

In 2014 the fingerprints of Angela Merkel and the German Defense Minister were "cloned" by taking high resolution pictures at a press conference. Against targeted attacks, using something that's readily visible on your person isn't the best idea.

What's your game plan for replacing your retina or fingerprints if compromised?

Biodata is the least secure because it can't be easily changed and the technology already exists to compromise them.

biometrics aren't passwords. They are only somewhat useful as authentication if you can verify that they are attached to the person you are authenticating, which generally only works in person.

> since a fingerprint or a retina scan makes a fine good two factor as well

Last year I was making new IDs for myself and my mother which in the newest version require fingerprints being provided beside the biometric photo. The office clerk lady who served us had a real struggle with taking scans of our fingerprints. Our skin was damaged due to low temperature and extensive use of alcohol-based sanitizing gel because of the current situation back then. She gave us vaseline cream so this would go a little bit easier but no luck - each of us spent around 10 minutes scanning each finger till it got finally digitalized.

The scanner used could a really cheap one and thus blamed for prolonging this whole scanning process or it was our skin condition or both these things. Whether it was, by this experience even if episodic one, I don't think that fingerprints are "a fine two factor".

As for eyes: it's really unlikely it might happen to many people but eyes can be damaged and there are eye diseases that might affect verification. Not mention post-procedures treatment that excludes use of this scan technique for some time.