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.

This would normalize e + ¨ to ë, for example...
But there is no Emoji normalization:

Same emoji, on different platforms:

👁‍🗨 1f441-200d-1f5e8 EYE IN SPEECH BUBBLE
👁️🗨️ 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.
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:
Also, general to all Unicode (kaomoji for example), your input method may vary depending on situation:
Another fun one. "🤷 1f937 SHRUG" was a female on practically all platforms until last week. 

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
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 [] or with a maintained 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:  [via @ezzatron]. Tldr: NFC, fold spaces, forbid PUA.

Also see the Stability Policy (pretty useless for Emoji though).
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 [] says: the verifier SHOULD apply the Normalization ... using either the NFKC or NFKD

IETF [ ] 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 [], referencing ISO 3166-1 alpha 2 []. Countries may later disappear if the United Nations decides they aren't countries.
2. Some are very similar:



2a. Some are canonically identical:



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. []

All these can make for input difficulties.
You can follow @FakeUnicode.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: