hsivonen
commented
2 years ago The key aspect of the proposal appears to be cryptographically mixing the origin and password on the browser side in a way that's opaque to JS so that phishing sites get bits that are not replayable on the real origin.
That's what WebAuthentication with CTAP1/U2F and CTAP2/FIDO2 already support. The paper ignores CTAP2/FIDO2 altogether and dismisses CTAP1/U2F as a solution due to current installed base size.
In order to maintain opacity of password entry to the page, the paper says the field's appearance should not be spoofable via CSS. That's not really realistic with UI that participates in in-page CSS layout. If you want unspoofable UI, you need to make it start from above the line of death.
What the paper says about clear-text submission is obsolete with present-day TLS practices.
AFAICT, the core of this proposal is not being convinced of WebAuthn being the way forward and instead trying to take the cryptographic origin mixing aspect of WebAuthn while still using passwords instead of CTAP1/CTAP2 tokens. I'm not particularly convinced that it would be worthwhile to engineer something new and password-oriented instead of continuing to pursue WebAuthn.
hi, The current <input type=password ..> password field only provides protection against physical shoulder-surfing adversaries who attempt to read the values entered into the password field. It is insufficient to protect values entered into the field against many other types of attacks including phishing sites, man-in-the-middle, session sniffing, etc. I would like to propose that we consider deprecating the existing field, and replacing it with a new input field that provides end-to-end encryption and authentication for any values entered into the field. A possible construction, "Securing Password Authentication for Web-based Applications", was presented at IEEE DSC 2022 (https://attend.ieee.org/dsc-2022/). You may read an earlier pre-print (with slight modifications) at https://arxiv.org/abs/2011.06257