1613560 - Password field discloses presence of multi-character code points

Status: NEW

(Core :: DOM: Editor, defect, P5)

Description

[Simon Welsh]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.2 Safari/605.1.15

Steps to reproduce:

1. Load a page with a password field in it
2. Enter a multi-character code point (or a single glyph that's built from multiple code points)
3. Use the arrow keys to navigate the rendered dots in the password field, or the delete key to remove rendered dots

Actual results:

The cursor moves between code points in the password field, not individual characters.

Example:
The emoji 🤦🏼‍♀️ (woman facepalming, white skin tone, blonde hair tone) causes 7 dots to appear in the password field. Using the arrow keys, you can see that there's two two-character code points followed by a one-character code point followed by a final two-character code point.

Expected results:

Using the arrow keys in a password field should navigate between individual dots, not code points. Likewise, the delete key should delete an individual dot.

Comment 1

[:Gijs (he/him)]

Not sure this really warrants being a security issue - if people have key input to the machine, they might as well use devtools or similar to inspect the actual value. Plus most websites have a "show password" toggle, and there have been suggestions weshould implement one in-browser.

Comment 2

[Daniel Veditz [:dveditz] out until Nov 10]

Not a security problem that needs to be hidden: the user filled in the password, or else it's someone malicious who can retrieve the actual value more easily than guessing by backspacing. Emoji passwords aren't even all that common.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Currently, this is by design. Grapheme clusters depend on font. Therefore, Gecko can consider which range is a glapheme cluster is in layout code. However, while the password is shown as masked character, we cannot test it. Ideally, we should follow UWP apps behavior, that is,

1. Can move everywhere even between a surrogate pair (since it hides whether where is a non-BMP character or not).
2. But when trying to delete a character, editor removes per grapheme cluster for avoiding to send odd and/or invalid Unicode string.

However, this is not important since on any platforms, you need to copy & paste to use emoji etc in passoword fields.

Comment 4

[Simon Welsh]

However, this is not important since on any platforms, you need to copy & paste to use emoji etc in passoword fields

This isn't true for desktop platforms. macOS (cmd-ctrl-space) and Windows (windows-period) both have methods that allow for direct entering of emoji using an on-screen keyboard.

I do agree that this isn't that important of an issue, but more because multi-codepoint passwords are uncommon rather than being hard to enter.