Client UI/UX in regards to using security keys.

[My1]

Hi again,

we REALLY gotta talk about how hard it has become to use FIDO2 Sticks even if you want to (or a service requires them) rather than platform or phones or password managers, or anything else I might have forgotten.

Several combination need you to go through a bunch of steps that are not immediately obvious that they exist without prior knowledge, and some even require you to actively make steps that are quite literally against what anyone would assume, like clicking CANCEL.

1) if you are on windows 10 and use a chromium-based browser, and have bluetooth if you cannot use windows hello (either due to restriction by the relying party or not having it set in the first place), it will show a dialog like this:

(ref: attachment chrome-passkey-phone.png)

just store the passkey on phone with NO INDICATION AT ALL that you even can use a FIDO2-Stick, here you have to click the "back" button at the bottom left to get a choice dialog between External or phone.

2) no preference set by the RP, Windows hello active on Windows 10, you get this absolute beauty

(ref: attachment W10-Winhello.png), where you need to click CANCEL

3) Macos, a Browser that is not Safari, you get this dialog if there is no specific preference, where you also need to click cancel

(ref: mac-passkey-altbrowser.png)

4) with safari it is ever so slightly better, offering a "more options" button, but still why doesnt it ask where to store directly?

These are just some of the worst that I aware of, there are easily more especially with password manager extension hijacking the request even if e.g. cross-platform has been set or Browsers' own password/passkey managers, such as chrome.

[Chad Spensky]

Unfortunately, I don't think there is much discussion to be had here. The consensus appears to be that synced passkeys, stored in insecure password managers, are the only passkeys that matter.  The more secure hardware tokens and device-bound keys appear to be considered deprecated. Pretty sad to see.

I thought it was clear that password managers were a dangerous temporary solution and that we needed to move away from them. However, we have succeeded in making them even more dangerous by storing private keys in them...

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNoh34r4zRq019AXfzm-Xef-irKG1jEE3cfRsJCUu97UMw%40mail.gmail.com.

--

www.allthenticate.com

Chad Spensky, Ph.D.  Founder and CEO M: (601) 80-31337 Houston, TX 77002

The content of this email was 100% human generated 🧑‍💻

[Tim Cappalli]

Hey Chad - Obviously everyone’s opinions are welcome but maybe don’t make general, misleading statements about an ecosystem that you clearly don’t understand and which you seek to profit off with your company. Very disappointing to see this FUD inducing rhetoric from a FIDO Alliance member company. 

@My1 there’s been significant work in this space recently, including preventing RPs from being able to completely exclude security keys. The reality is that most devices operate in a consumer context by default, the vast majority of consumers don’t use hardware security keys as their passkey credential manager, and  extensive user research shows that showing the security key option by default is very confusing to them causing them to abandon the ceremony. We’re working to best balance the needs of most users with the needs of those requiring device-bound passkeys in hardware authenticators.

Tim

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAPkAZdyS3Lz%2Bi_i%3DpsbdTeRq6SanUzoJ7L8BrAPp%3DGx6Z%3DxX9A%40mail.gmail.com.