3 ms·
This OP is a repost of an earlier post: https://news.ycombinator.com/item?id=33633773 https://news.ycombinator.com/item?id=33633773 So I reiterate here: "Thi
by egberts1 4y ago
This OP is a repost of an earlier post:
https://news.ycombinator.com/item?id=33633773 https://news.ycombinator.com/item?id=33633773
So I reiterate here:
"This challenge will be returned in the response and you must verify they are the same."
Ummm, "MUST"? (emphasis is mine).
Too bad that we cannot somehow make this requirement word a "SHALL" as this leg of the "ceremony" can easily be overridden by a malicious JavaScript function(s).
Unless these JavaScript scripts AND its references HTML pages are also:
- under the protection of nonce hash values,
- complex CSP properly scoped,
- older WebAuthn protocol made client-side rejectable,
- its server-supplied JavaScript logic gets pre-tested in its client browsers prior to the ceremony,
- CTAP1 properly rejected, AND
- the browser is also deemed provably secured from an nonce override.
Awful lot of conditions such that it reminds me of the children's game of "Jenga" (a tower of stacked rectangular blocks) ... reaching for the sky.
Surely, our large pool of esteemed and well-trained web ninjas can handle this seemingly "nuclear-safety" checklist with relative ease. /s
More must be done to streamline this before web integrity gets properly and safely restored in these days and ages.
reply
Shit. Disregard all that I said. I forgot about the malicious client-side nonce-disabling malware. That's a doable thing.
- mooreds 4y agoUnless I misunderstand you, I believe that the challenge is verified not by the JS running on the page, but by the RP (the website) server side. Here's more about the challenges from https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challenges https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challen... : As a cryptographic protocol, Web Authentication is dependent upon randomized challenges to avoid replay attacks. Therefore, the values of both PublicKeyCredentialCreationOptions.challenge and PublicKeyCredentialRequestOptions.challenge MUST be randomly generated by Relying Parties in an environment they trust (e.g., on the server-side), and the returned challenge value in the client’s response MUST match what was generated. This SHOULD be done in a fashion that does not rely upon a client’s behavior, e.g., the Relying Party SHOULD store the challenge temporarily until the operation is complete. Tolerating a mismatch will compromise the security of the protocol.