The biggest flaw I've heard with WebAuthn/other attempts to do security critical or zero-trust tasks in client-side JS: even if you're *theoretically* not trusting the server with your secrets, you're *still* trusting them not to be so thoroughly compromised/malicious that they send malicious JS (which of course gets re-downloaded on each visit). See e.g., https://github.com//bitwarden/web/issues/660#issue-705107304
But couldn't a site mitigate that by publishing a hash of the document HTML – basically like SSH's known_hosts?
1/n
> couldn't a site mitigate [the amount of trust in the server that client-side WebAuthn requires] by publishing a hash of the document HTML – basically like SSH's known_hosts?
To flesh that out, I'm imagining a site (eg, bitwarden) posting the hash of the HTML for their login page so that users can check the login page's actual hash against it (manually or maybe with an extension?)
Of course, the server hosting the hash could be compromised too, but it's a static page–a low surface area!
2/n
@codesections Hashes require things to be exactly identical. Bit for bit. If you have one server directly connected to the internet, maybe 2 page fetches are the same. But as soon as you introduce load balancers, CDNs, reverse proxies and the other ephemera that come with scaling up, getting a bit for bit identical fetch is trickier. Look at the complexity of XACML to see what it looks like when you hash and sign XML. Absurd complexity.
> Hashes require things to be exactly identical. Bit for bit.
Yeah, of course 😁
> as soon as you introduce load balancers, CDNs, reverse proxies and the other ephemera that come with scaling up, getting a bit for bit identical fetch is trickier
Hmm, I'm unconvinced.
I mean, sure scaling up would (like always) make it harder. But we're just hashing the html, not the headers – and CDNs/etc mostly don't mess with the content. Indeed, many use etags, so already depend on a content hash
@codesections Hashes can be made for specific assets / elements of a digital resource.
E.g., time blocks, different semantic segments, headers vs. body, etc., etc.
Much as filesystem full-disk encryption is typically done at a block level rather than the entire disk or per-file (though both may exist).
So you might lose a few blocks, but not the full resource.
Proxying and SSL/TLS is indeed a headache.
@paco@mastodon.org.uk
@codesections @paco so sri is a spec that lets you specify fixed hashes for resources like css and js, mainly for the 3rd party bit of things.. https://www.srihash.org/