The explainer says:
Man in the middle attacks are detectable by the requesting server via validation of the device signature over session data.
I'm not convinced that's necessarily true. Eg. a successful MITM attack could modify the response to look like user cancellation when in fact the attacker has gained the credentials they wanted.
Might it be reasonable to require that decryption happens only on the server, not the client to prevent malicious JS from being able to MITM at all? One probably overly simplistic approach would be to require the browser to load the requester public key from a .well-known file on the server. Alternately perhaps the requester public key should be sent in the HTTP response headers for the page, or for some other resource fetch?
Or perhaps there are enough legitimate use-cases for client-side key determination and potentially even decryption that we should just accept the client-side MITM risk?
The explainer says:
Man in the middle attacks are detectable by the requesting server via validation of the device signature over session data.I'm not convinced that's necessarily true. Eg. a successful MITM attack could modify the response to look like user cancellation when in fact the attacker has gained the credentials they wanted.
Might it be reasonable to require that decryption happens only on the server, not the client to prevent malicious JS from being able to MITM at all? One probably overly simplistic approach would be to require the browser to load the requester public key from a
.well-knownfile on the server. Alternately perhaps the requester public key should be sent in the HTTP response headers for the page, or for some other resource fetch?Or perhaps there are enough legitimate use-cases for client-side key determination and potentially even decryption that we should just accept the client-side MITM risk?