Comment by BoppreH
7 days ago
I admit that the 1+2 yubikey rotation mentioned elsewhere was clever and new to me, but I'd argue that none of the solutions in this thread were good enough.
> Nothing forces you to use a passkey provider that enforces attestation if that’s what your threat model worries about.
I'm very confused by this statement.
For starters, attestation is unrelated to the topic of offline backups discussed in this thread.
Second, the whole problem of attestation, as described in the original post, is that it's not you who decides when to use it. And it's not the passkey provider who enforces attestation, as you said. It's the Relying Party, like Netflix, who can unilaterally decide the minimum security features of my passkey scheme, with all their drawbacks, and attestation ensures that they're followed.
> It's the Relying Party, like Netflix
So the problem, then, is with Netflix, not with passkeys. Breaking passkeys to try to prevent some different harm from befalling you does not make sense. And the passkey provider can enforce the lack of attestation by refusing to support it.
Netflix could force you to use a chosen authentication provider to restrict that scenario. But, we already live in that world today, nothing in principle stops them from forcing you to use Okta Verify or Microsoft Authenticator in principle. Yet I do not see people using that as a reason to write articles about how OIDC 2.0 or TOTP is a trap.
> And the passkey provider can enforce the lack of attestation by refusing to support it.
Then you won't be able to use it with Netflix when they require attestation. How's that supposed to help?
> nothing in principle stops them from forcing you to use [...] Microsoft Authenticator
Did you read the article? The author explicitly compares passkeys with TOTP, and explains how relying parties cannot force you to use a specific TOTP provider, because TOTP providers are indistinguishable from the relying party perspective. You could do it with pen and paper and nobody could stop you.
> Yet I do not see people using that as a reason to write articles about how OIDC 2.0 [...] is a trap.
First, there's no such thing as OIDC "2.0". And yes, people do complain about the SSO "Log in with X" services, for precisely the same lock in problems:
https://jeangalea.com/hidden-cost-of-sign-in-with-google/
https://www.androidauthority.com/are-you-still-using-sign-in...
https://www.techlusive.in/features/i-used-sign-in-with-googl...
Sorry to be blunt, but if your account was not so old I would be reporting you as a possible bot or troll. In my 16 years on HN, this has been my most baffling conversation. I see your other comments on this same post, and you make good points there, I don't understand what's going wrong here.
> > And the passkey provider can enforce the lack of attestation by refusing to support it.
> Then you won't be able to use it with Netflix when they require attestation. How's that supposed to help?
That's my point. The issue is with Netflix forcing you to use passkeys + attestation, not with passkeys existing.
> The author explicitly compares passkeys with TOTP, and explains how relying parties cannot force you to use a specific TOTP provider, because TOTP providers are indistinguishable from the relying party perspective.
I used Okta Verify and MS Authenticator on purpose; they support “extensions” beyond their TOTP support which offer relying parties additional information about authentication events. If Netflix were willing to require atypical passkeys + attestation because passkeys were popular, they should logically be willing to require atypical TOTP + extensions because TOTP is popular. The apps to do this already exist.
I have government websites that already require me to use Okta Verify specifically, but I don’t go around saying this is the fault of TOTP for existing.
> In my 16 years on HN, this has been my most baffling conversation. I see your other comments on this same post, and you make good points there, I don't understand what's going wrong here.
We might just be talking past either other. I have been guilty of it before.