https://portswigger.net/research/ublock-i-exfiltrate-exploiting-ad-blockers-with-css describes a scenario where Edge's "unmask password" feature can allow for a password to be read by a 3rd-party, if an attacker is allowed to provide a custom font for the input field.

Essentially: in this scenario, the attacker can use a web font which uses a different font-file for each character, so there's a distinct network request that gets made for each character in the user's password, if the user clicks the button to reveal the password.

This may be something that we'd like to mitigate before we ship our own reveal-password feature (via bug 1743046).

One potential mitigation would be to prevent web fonts (or at least, prevent cross-origin web-fonts) from being used to render the characters in an <input type="password"> field. I'm not sure how complex that would be, but it seems worth considering.

Bug 1749612 concerns with fonts on passwords as well. Many times |I1l or O0 or B8 are confused one for another. It would be best if we can figure out a good font to use for passwords.

Bug 1748065 concerns with password length leak on a concealed password. Perhaps <input type=password> should display some fixed number of **** when not focused or editable and concealed.

I don't think this is particularly problematic, other browsers have ways to reveal passwords (-webkit-input-security, etc), and at the point you have injected third-party fonts into the page you could've already injected * { -webkit-input-security: none !important }, right?

But you (the 3rd-party who's providing the fonts & maybe-sneaky/malicious styles via some imported CSS, and only CSS) still ideally shouldn't be able to detect what the characters in the password are (even if you can cause them to be displayed via -webkit-input-security).

The mitigation suggested here (forcing a particular font for displayed password fields) would prevent that potential leak.

Yeah, but that'd affect the baseline and sizing of the input, which doesn't sound great to me.

Hmm, that's a fair point; that inconsistency between password & text-fields would be worth avoiding.

Would it be complex to only prevent cross-origin webfonts from being used in a password field? (with some graceful fallback if a font is blocked for this reason, e.g. just using the next font in the font-family list) That would allow this to generally work for folks who are just using regular font-family names or who are hosting their own webfonts, with sizing/baseline mismatches only if someone explicitly asks for a cross-origin font to be used in their input fields (which we'd reject specifically for <input type="password"> and use their fallback font there).

(I suppose "cross-origin" isn't perfect here, since someone might host their static content at a domain that looks cross-origin but is still under their control, e.g. web content at www.example.com referencing fonts from static.example.com. So maybe that shoots a hole in this solution.)

FYI we override font when we show autocomplete preview, so baseline and sizing issue exists already.

(In reply to Sergey Galich from comment #6)

FYI we override font when we show autocomplete preview, so baseline and sizing issue exists already.

Hmm, you're right -- but it doesn't seem to be causing issues at this point, which is good/hopeful maybe.

Specifically: I do see the font being overridden (it's not the specified monospace) in autocomplete-preview-renderings when I interact with this data-URI testcase below. If I start typing my street address into the first field, and hover one of the suggested auto-completions, then the preview that's shown in the other fields uses a sans-serif font, but that doesn't impact the size or position of the textfields:

data:text/html,<style>input { font: 30px monospace }</style><input name="Address"><input name="City"><input name="State">

(For comparison: if I just manually add font-family: sans-serif to one of the fields in devtools, then its size does immediately change. So: I think this indicates that our autocomplete preview is successfully avoiding this layout issue, somehow.)

I don't know how that autocomplete preview is implemented (I imagine it might not actually be setting the .value on the textfield when showing the preview); but maybe we should use the same display mechanism when revealing passwords, to benefit from the same privacy guarantees?

(Depending on how it's implemented -- e.g. if it's literally just an overlay -- I can imagine it could be tricky to make it interactively editable, or to ensure that the textfield overflow mechanics work properly, but it's probably solvable?)