Thread by @FakeUnicode, Because it keeps coming up, how about a thread on Emoji in [...]

Because it keeps coming up, how about a thread on Emoji in passwords. So we (and you) can link to it in the future.

Should they be allowed? For all practical purposes they can't not be. So, yes.

Should they be heavily warned against? Yes.

But why? Well...

First off, there are a lot of bad password policies out there. Mostly by services that probably store your password as plain text. The recent NIST recommendations suggest allowing Unicode, but normalized. https://pages.nist.gov/800-63-3/sp800-63b.html

This would normalize e + ¨ to ë, for example...

But there is no Emoji normalization:

Same emoji, on different platforms:

31-20e3 DIGIT ONE + COMBINING ENCLOSING KEYCAP
vs

31-fe0f-20e3 DIGIT ONE + COMBINING ENCLOSING KEYCAP

1f441-200d-1f5e8 EYE IN SPEECH BUBBLE
vs

‍

1f441-fe0f-200d-1f5e8-fe0f EYE IN SPEECH BUBBLE

Also, there are overlapping variant forms, that vary by vendor and version.

™ 2122 (default text)
™︎ 2122-FE0E (force text)

2122-FE0F (force emoji)

1f574 (default emoji)
🕴︎ 1f574-FE0E (force text)

1f574-FE0F (force emoji)

And the emoji definitions can change at any time (like the Emoji 12.1 rushed release this quarter).

And some vendors just do whatever they want.

Emoji only on Windows:

, 🖔

Emoji only on Samsung: ⚀⚁⚂⚃⚄⚅

"Emoji" are effectively impossible to disallow specifically.

And the emoji definitions can change at any time (like the Emoji 12.1 rushed release this quarter).And some vendors just do whatever they want.Emoji only on Windows: , 🖔Emoji only on Samsung: ⚀⚁⚂⚃⚄⚅"Emoji" are effectively impossible to disallow specifically.

It gets worse. Emoji have been removed. If you input

in a password, and then get a new phone, you no longer have it on your keyboard.

Multi-person skin tones removed from RGI:

https://emojipedia.org/wrestlers-type-3/
https://emojipedia.org/handshake-type-3/

http://unicode.org/Public/emoji/3.0/emoji-sequences.txt
http://unicode.org/Public/emoji/4.0/emoji-sequences.txt

It gets worse. Emoji have been removed. If you input in a password, and then get a new phone, you no longer have it on your keyboard.Multi-person skin tones removed from RGI: https://emojipedia.org/wrestlers-type-3/ https://emojipedia.org/handshake-type-3/ http://unicode.org/Public/emoji/3.0/emoji-sequences.txt http://unicode.org/Public/emoji/4.0/emoji-sequences.txt

Also, general to all Unicode (kaomoji for example), your input method may vary depending on situation: https://apple.stackexchange.com/questions/202143/i-included-emoji-in-my-password-and-now-i-cant-log-in-to-my-account-on-yosemite

Another fun one. "

1f937 SHRUG" was a female on practically all platforms until last week. https://emojipedia.org/shrug/

Going forward, it will be gender neutral. To get the female variant you have to use:

1f937-200d-2640-fe0f WOMAN SHRUGGING

You can't just throw that at NFKD

Another fun one. " 1f937 SHRUG" was a female on practically all platforms until last week. https://emojipedia.org/shrug/ Going forward, it will be gender neutral. To get the female variant you have to use: 1f937-200d-2640-fe0f WOMAN SHRUGGINGYou can't just throw that at NFKD

To summarize:

The same emoji on different devices varies in the codepoints used.

The same emoji on the /same/ device, over time, varies in the codepoints used.

What even is an emoji??? The server just sees codepoints.

Allow them? Yes

WARN against them? Probably. ¯\\_(ツ)_/¯

For some actual constructive advice, maybe something like roughly detecting emoji with the current data files [ http://unicode.org/Public/emoji/latest/] or with a maintained regex [ https://github.com/mathiasbynens/emoji-regex], and update as needed.

Obviously useless for blocking emoji for the reasons stated. But

Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords: https://tools.ietf.org/html/rfc8265 [via @ezzatron]. Tldr: NFC, fold spaces, forbid PUA.

Also see the Stability Policy (pretty useless for Emoji though).
https://unicode.org/policies/stability_policy.html

There are assumptions about Unicode you can make, that will never change, per the Stability Policy. Like the Private Use Area ranges.

But there are some things you can't take for granted.

Mongolian Vowel Separator has changed category twice.

Control > Space Separator > Control

Hmm, a discrepancy.

NIST [ https://pages.nist.gov/800-63-3/sp800-63b.html] says: the verifier SHOULD apply the Normalization ... using either the NFKC or NFKD

IETF [ https://tools.ietf.org/html/rfc8265 ] says:
4. Passwords > 4.2.2. Enforcement > Unicode Normalization Form C (NFC) MUST be applied to all strings.

Need more reasons to avoid emoji passwords? Random old Android phone. Swiftkey enters password mode on <input type="password">, but still allows emoji input.

Using a never-before used Emoji results in it being saved in the recently/frequently used list.

What does your phone do?

Addendum: Let's enumerate why flag emoji are spooky in passwords.

1. Flags are Regional Indicator Symbol pairs [ https://en.wikipedia.org/wiki/Regional_Indicator_Symbol], referencing ISO 3166-1 alpha 2 [ https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2]. Countries may later disappear if the United Nations decides they aren't countries.

2. Some are very similar:

ROMANIA

CHAD

INDONESIA

MONACO

2a. Some are canonically identical:

UNITED STATES

US MINOR OUTLYING ISLANDS

FRANCE

SAINT MARTIN

CLIPPERTON ISLAND

And most emoji pickers won't tell you which is which, unless you search them.

3. Flags can disappear regionally. Most phones in mainland China will not show the Taiwan flag:

And of late, iPhones in Hong Kong have started hiding it from input. [ https://www.theverge.com/2019/10/7/20903613/apple-hiding-taiwan-flag-emoji-hong-kong-macau-china]

https://twitter.com/thisboyuan/status/1179681769022353409

All these can make for input difficulties.

Latest Threads Unrolled: