zlacker

A Tour of WebAuthn

submitted by caust1+(OP) on 2024-12-26 18:27:49 | 299 points 108 comments
[view article] [source] [go to bottom]

NOTE: showing posts with links only show all posts
◧◩
8. ylk+Js[view] [source] [discussion] 2024-12-26 23:07:42
>>lapcat+Vr
Just use a password manager that doesn't sync by itself then

https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys

◧◩◪◨
11. ylk+3u[view] [source] [discussion] 2024-12-26 23:24:33
>>g_p+bt
I agree that it's annoying that there's now a limit on the amount of credentials you can store on hardware keys. But while older Yubikeys only support 25 resident keys, models with firmware 5.7 onwards support 100. That probably makes it feasible to exclusively store passkeys in hardware. https://www.yubico.com/blog/empowering-enterprise-security-a...

However, I don't know whether it's possible to delete only a single resident key you no longer need.

◧◩◪
12. lapcat+Uu[view] [source] [discussion] 2024-12-26 23:33:46
>>ylk+Js
There's no browser extension available for Safari: https://keepassxc.org/docs/KeePassXC_GettingStarted#_setup_b...
16. arianv+Lx[view] [source] 2024-12-27 00:09:37
>>caust1+(OP)
There are some hairy edge cases during registration that many get wrong. (At least GitHub and google had this bug) that if create() returns but the passkey never reaches the server due to bad networking conditions that your password manager thinks it can log in but the server never recorded the passkey for the user. Basically there is no transactionality and you can get in a split brain situation where your password manager and your server don't agree and it's very confusing for end users.

https://github.com/w3c/webauthn/issues/2038

They apparently came up with a fix for this using something called Signals API but I don't think any browser implemented that yet.

Just wanted to highlight that this part of the UX is hairy and hard to get right

◧◩
21. arnarb+vC[view] [source] [discussion] 2024-12-27 01:16:34
>>arianv+Lx
Chrome on desktop did: https://developer.chrome.com/docs/identity/webauthn-signal-a...
◧◩
55. pas+sj1[view] [source] [discussion] 2024-12-27 13:21:31
>>Zamico+uR
Ah yes the closed doors of the world wide web consortium.

https://lists.w3.org/Archives/Public/public-webauthn/

(nb. I'm not saying the folks were easy to work with or super open to discussion, but it was not some clandestine black kitchen where it was cooked up.)

◧◩◪
64. lxgr+Qu1[view] [source] [discussion] 2024-12-27 14:59:15
>>pas+sj1
The working group is definitely quite corporate-driven – just look at who's most active in it! – and has made some bad decisions in the past (my favorite example being [1], which effectively either breaks the hardware authenticator experience for passkeys or helps Yubico sell more/higher capacity Yubikeys, depending on how you look at it).

But I agree that one thing you can't accuse them of is not operating in the open. While I don't agree with some of their decisions, discussing feedback in Github issues as well as on public mailing lists is probably as transparent as it gets.

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

◧◩◪◨
66. lxgr+Cv1[view] [source] [discussion] 2024-12-27 15:03:36
>>lapcat+Uu
For macOS/iOS, you could give Strongbox a try: https://strongboxsafe.com/

I haven't really looked into it myself, but it seems to be using the same database format as KeePass, and it hooks into macOS's "FIDO provider" API, which makes it accessible to not only Safari but all browsers that use it (which includes Firefox and Chrome on macOS, and probably everything on iOS), without requiring any browser-side extension.

◧◩◪◨
71. lxgr+Mw1[view] [source] [discussion] 2024-12-27 15:10:58
>>eadmun+xi1
> It doesn’t matter if other authenticators could work if a relying party refuses to allow its users to use them.

You keep repeating that, but that's not possible anymore, since both Apple and Google removed attestation from their respective passkey/WebAuthN implementations.

For details, see >>42522490 .

84. 1vuio0+KR1[view] [source] 2024-12-27 17:17:18
>>caust1+(OP)
No SNI: https://web.archive.org/web/20241223150914if_/https://www.im...
◧◩◪◨⬒⬓⬔
97. g_p+oH2[view] [source] [discussion] 2024-12-27 23:48:36
>>former+Ue1
Thanks - yeah it seems like this is supported in FIDO 2.1 (but not 2.0). I suspect this is only implemented in Yubikey 5.7 and above.

Once the technology is there to support it, hopefully the user experience part can be improved with time.

Ref in the standard - https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cl...

◧◩◪◨⬒
101. eadmun+323[view] [source] [discussion] 2024-12-28 04:06:30
>>lxgr+ku1
> Apple and Google discontinued attestation when they introduced passkeys. It's gone.

It would be great if you’re correct, but these references sure seem to indicate that attestation is still a thing.

Microsoft, November 2024: https://learn.microsoft.com/en-us/entra/identity/authenticat...

Yubico: https://developers.yubico.com/Passkeys/Passkey_relying_party...

Apple: https://developer.apple.com/documentation/devicemanagement/s...

Apple: https://support.apple.com/guide/deployment/managed-device-at...

Google, September 2024: https://android-developers.googleblog.com/2024/09/attestatio...

A Tour of WebAuthn, December 2024 (aka the fine article): https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...

◧◩◪◨⬒⬓⬔⧯
106. former+0S5[view] [source] [discussion] 2024-12-29 11:45:49
>>g_p+oH2
It's available since at least Yubikey 5.2 (~2020).

edit: Indeed, that's the firmware revision credential management was added, per this blog post: https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-...

I'm honestly very annoyed with Yubico that they just froze their product line-up circa 2018 and pretend the major changes in firmware (5.2, 5.7) don't matter at all and don't warrant a separate SKU.

[go to top]