pkose.blogg.se - Yubikey with google

Something that is still bothering me is that I couldn't repro the bug or nail down the conditions that make it happen - I can interact with it in the wild, as in Steven's cluster, but couldn't yet conjure it at will. If it indeed is a bug, I also suspect the answer might be "upgrade to WebAuthn", hence my earlier comments. This seem to happen in the depths of the CryptoTokenExtension, far away from code that we can directly influence. Digging further down into Chrome I am led to believe that it is, for some unfathomable reason, failing origin validation - in other words, it is deciding that is not allowed to use the app ID, even before reaching the U2F device. (The above error happens without any user interaction, another interesting data point.)Ī comparison of Firefox and Chrome challenge payloads shows that they are receiving essentially identical data (in particular, a correct app ID). If you were to login in the cluster above using Chrome (or any Chrome-based browsers) you'd fail login right away with the following error, which is also characteristic of an App ID mismatch:

a particular node role has require_session_mfa=true, allowing us to hit the bug.

authentication.u2f is sensibly configured and looks correct to me - no low-hanging fruit on App ID or Facets.

authentication.type is set to oidc, which means most users clear login sidestepping U2F issues.

Now, onto the scenario of the bug itself, while talking to and looking at his cluster, I found the configurations below interesting: Incidentally, I suspect WebAuthn might be a good answer to the entire bug, but let's try to get a better answer before we yield. The best answer for this is to move to WebAuthn, a work that I've undertaken myself and that should land in the next major. This seems to have always been the case and is an issue bigger than this particular bug.

Safari doesn't seem to support U2F out of the box ( a fact the code seems acutely aware of).

Firefox, thankfully, seems to work for all relevant scenarios.tsh is not a factor in this particular bug - as we'll see below, it seems tied to browser appId/origin validation.It's been a couple days since I've been looking into this one, so let me try to unpack the initial ticket and summarize what I've found out so far.