Hacker News Reader

Comment by wkat4242 | Hacker News Reader

I wish the support of real tokens would also benefit from the attention Passkeys receive though. They use the same protocol after all.

On Firefox on Android I still get the message that physical tokens are not supported on mobile when I try to authenticate to e.g. PayPal. I don't really like Passkeys because I prefer the security of real tokens (yubikeys). And I don't want to register with big tech companies to be able to use passkeys - for example I don't even have a google account logged in on my android phone.

View on HN

One issue is the limited support for resident keys on many hardware tokens. IIRC the limit on recent YubiKey 5 firmware versions is 25 resident keys. As Passkey adoption accelerates, people will hit that limit rather quickly.

Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser).

Finally, only a tiny part of the population uses dedicated hardware tokens, whereas pretty much all popular password managers supports or will support Passkeys (Apple Keychain, 1Password, whatever the Chrome password manager is called, Samsung Pass, etc.).

So, it’s not surprising that hardware tokens are tested less these days.

(I don’t think that is a good, just trying to speculate on the reasons.)

> Also the UI around managing resident keys is not great and uncoupled from where they are typically used (the browser).

Chrome allows you to see stored resident keys and delete individual resident keys on any hardware token which supports CTAP 2.1. (to be fair, it is a bit hidden: Settings -> Privacy and security -> Security -> Manage security keys -> Sign-in data).

There are fido2.1 keys with 300 resident key storage :

https://www.token2.com/shop/category/pin-release2-series

Interesting one, thanks!!

I'm kinda hoping Yubi come out with a version 6 with many more "passkey" CTAP2 slots too. Because I don't only use FIDO functionality but I heavily use the OpenPGP slots as well. Not for email but for other things (file encryption, password manager, SSH). Not planning to change any of that to fido any time soon either.

Small clarification: SSH functionality is a part of FIDO stack (if you meant ecdsa-sk & ed25519-sk )

Yeah, but without resident keys you’ll have to carry a file containing the key handle around with you from computer to computer (where you want to use the Yubikey-resident SSH key). And if you ever lose the file, your key is lost too!

This is because SSH doesn’t have a centralized RP model that’s kind of implied in FIDO and WebAuthN for non-resident keys.

I don't think discoverable credentials on hardware authenticators are a good default pattern (even though requiring(!) resident/discoverable keys is the suggested behavior [2] by the FIDO alliance!?)

They have their uses for special use cases for authentication against local or otherwise non-synchronized relying parties or as a component of authentication protocols that aren't a good fit for native WebaAuthN (like SSH), but a regular old website can just ask me for my user ID (which is my email address in 99% of all cases).

Unfortunately, there isn't [1] a way to say (in WebAuthN API terms) something like "give me a discoverable credential if you have unlimited storage, otherwise nevermind", so as far as I understand, a relying party can only say "preferred" (taking up a scarce slot on a HW authenticator) or "discouraged" (making a platform credential non-discoverable needlessly, except on platforms that ignore that flag anyway like Apple/iCloud Keychain).

As an aside, that issue [1] having been closed without any accomodation for that use case fits with my anecdotal observation of the WebAuthN working group having largely pivoted towards the "Passkey paradigm". Hardware authenticators somehow don't feel like a first-class API concern anymore.

[1] https://github.com/w3c/webauthn/issues/1822

[2] https://github.com/fido-alliance/how-to-fido/issues/16

My passkeys are kept in my password manager. Many support them now: 1Password, Keeper, Dashlane, BitWarden, and I know KeePassX is working on support.

Sure it's not as secure as a hardware token but it's a nice sweet spot between convenience and security.

However I wish more platforms let me use TOTP and passkeys together for MFA. That way I don't need to put all my trust in a single password manager company. 2FAS with it's browser plugin gives a really slick experience and it backups to Google/Apple storage with a separate password to encrypt your OTP secret keys.

I'm sure you mean KeePassXC? KeePassX has been dead for years.

Yes, my bad.

KeePassXC added support for passkeys in 2.7.7, released a week ago:

https://keepassxc.org/blog/2024-03-10-2.7.7-released/

This post prompted me to give it a try at webauthn.io.

Passkey support is disabled by default, so you have to enable it in the settings for the browser extension. After that, the UI seems reasonable enough. It creates an entry with a "Passkey" tag, where the Password field is empty, and the credentials are stored as additional attributes on the Advanced tab.

One thing I'm not sure about: although the extension has a setting to fall back to the browser's own passkey support, when I dismissed the KeePassXC prompt, I did not get a prompt from Firefox.

The fallback should be fixed in extension version 1.9.0.2.

> Passkey support is disabled by default

Thank, I hadn't noticed that, I thought I had to wait for the extension to be updated after the announcement from KeepassXC.

> After that, the UI seems reasonable enough.

I tried it on webauthn.io and I'm wondering if there's a point in showing a prompt on every login attempt, if passkeys are phishing proof. Why not just allow the login right away? Maybe show a notification that it happened, but why wait for user confirmation?

Bitwarden still doesn't support it on mobile, where it would probably the most useful, partially because Bitwardens auto fill on android is extremely unreliable, especially when dealing with two login pages (email then password).

Bitwarden doesn't have support in apps, but you can get passkey support in Firefox by installing the Bitwarden addon.

I would've preferred more integration here (because unlocking the app vault doesn't unlock the addon vault, for example) but I think this is just because of the lack of proper APIs for this kind of thing. Android's auto fill API is using the standard system API, but the system API clearly isn't designed for the "enter your username, hit next, then enter your password" flow.

KeePassXC supports them in their latest stable version as of last week [0].

[0]: https://keepassxc.org/blog/2024-03-10-2.7.7-released/

Unfortunately I've also seen that a few times. There seem to be two common ways to get it wrong:

One is too-rigid modeling. Some sites explicitly only want to support passkeys as a single-factor authentication method, and then they don't go the extra length of also supporting non-discoverable credentials. (The only thing that would take is to optionally prompt for a user name in their login form, which almost all sites do anyway for legacy login methods.)

I do have empathy for sites wanting to not complicate their backend model too much, i.e. they only want to support two-factor authenticators, but many hardware authenticators these days support a PIN or biometrics! Some sites, I suspect, even outright exclude roaming (i.e. non-platform) authenticators, even though they do support discoverable credentials and user verification, i.e. everything that passkeys can provide too (albeit with limited storage capabilities), which is just sad.

The other is just due to outright bad practices: Some sites gate their WebAuthN implementation behind a user agent flag. Then they inevitably lack behind actual browser support, and in many instances the user agent alone won't even tell the full support story (now that browser might be using the OS-provided credential API, which can then delegate to a third-party password manager).

As often, Amazon wins the award for the worst possible UX here by

- Implementing WebAuthN as an alternative to password entry, rather than as an alternative second factor (which is the sane thing to do), which means I have to still provide my TOTP after providing my (dual-factor!) passkey. (Bonus: I can't use my passkey for password reauthentication, I have to log back out to get back to the screen where I can select one.)

- Excluding Firefox via user-agent sniffing (with a completely incoherent error message of "If you want to add a passkey, use a different cloud service account (example: Apple ID or Google account)" as a reasoning for why I can't proceed on Firefox

- Calling my USB hardware authenticator "iCloud Keychain", because I registered it via Chrome on macOS (?!)

- Requiring a PIN entry on an authenticator that supports it, despite not using any two-factor functionality semantically

I use all the same things as you, but PayPal doesn't use WebAuthn (that I can see). It's just 2FA hardware tokens, which should work fine (and I do get a prompt to use a USB key on Firefox).

> PayPal doesn't use WebAuthn [...] It's just 2FA hardware tokens

That's WebAuthN too (if you mean USB-connected FIDO tokens).

Yes they do now! And it was firefox on mobile. Desktop firefox didn't support CTAP2 mode either except on Windows but it was fixed a few versions back (finally!)

Reply on news.ycombinator.com