It's probably better if it shouldn't. It's generally better to prevent passwords from containing characters that can't be entered on a decent proportion of devices you may encounter.
Emojis are particularly problematic because new ones keep being added which require OS upgrades, and you might find yourself needing to log in from another device that just doesn't support those emojis yet.
Also it's not like Unicode makes everything easy. For example, you have to remember to normalize the password before hashing. Otherwise something as simple as "ñ" may be a totally different byte sequence depending on which device you're using.
If a system cannot handle ñ in a password then it is completely broken. We are not talking about the latest emoji here but about a character which is part of one of the most common languages in the world, included in 8859-1 / Latin-1, etc.
It is no longer realistic to pretend that only ASCII exists and try to get away with that.
Even a lot of Unicode-aware code written by a developer aware of at least some Unicode issues often fails to normalize properly, most likely because they're not even aware it's an issue. Passwords are a case where you need to run a Unicode normalization pass on the password before hashing it, but, unfortunately, if you're already stored the wrong password hash fixing it is rather difficult. (You have to wait for the correctly-incorrect password to be input, then you can normalize and fix the password entry. This requires the users to input the correctly-incorrect password; if they only input an incorrectly-incorrect password you can't do anything.) I'd suspect storing a lot of unnormalized passwords before learning the hard way this is an issue is the majority case for homegrown password systems. You hear "don't roll your own crypto" and think reaching for a bcrypt or scrypt library solves it, but don't realize that there's some stuff that needs to be done before the call to those things still.
With built in emoji entry keywords in every modern OS how many devices are left that can't type emoji? Even if you plan to restrict to Unicode Version N - 1 or N - 2 where N is the current version to avoid "user can't type password on older hardware", the proportion of emoji you can reliably type today on just about any device is huge.
People are still using Windows 7 -- it's the third most popular Windows version after 10 and 11 -- and it only supports Unicode 5.1.
Emoji weren't officially supported until Unicode 6.0, though there are a subset of current emoji (less than a quarter) that work on Windows 7 in practice.
Meanwhile the current standard is 15.1.
There's no security or convenience necessity whatsoever for supporting emoji in passwords, but inconsistent OS support is an excellent reason against it.
Windows 7 market share is barely at 3% on the internet per statcounter.com. Third place doesn't mean "popular", especially not right now.
There's quite a bit of convenience, and some concomitant security, to using emoji in passwords. Emoji are high entropy code points that are easily visually distinguishable across most language boundaries. A "short" password of just emoji is going to have way higher entropy and be way harder to brute-force/rainbow table than any equivalent "length" (by visual character count) ASCII-only password. That should go without saying. The fact that huge boost in entropy also comes with a massive benefit in how quickly a user can glance at their password and know that they typed in right/wrong often faster than they could if forced to build a line-noise password is a huge bonus. (Related to why Windows 10 experimented with Picture Passwords and a lot of Android users use some form or another of Gesture PINs.)
That said, I think the real solution is of course to eliminate passwords altogether (and yes Passkeys are our best hope right now). But saying that we have to stick to ASCII for passwords because that's a lowest common denominator for keyboards is very much like saying that we should stick only to passwords that you can T-9 on flip phones or send in an SMS or that passwords shouldn't really be longer than 8 characters just in case some Unix system needs to use the old DES-based crypt() function or that passwords shouldn't contain quote marks, semicolons, or percentage signs because those might be SQL injection attacks and you might have some PHP apps that are vulnerable to those. You are letting silly technical lowest common denominator bugs stop you from increasing security for the median/mean user.
Sure? But what definition of "popular" does "large amount of people" meet? "Of or relating to the general public"? The general public is using Windows 10 and 11. "Suitable to the majority"? Again, the vast majority is 10 and 11. Same for "frequently encountered or accepted" and "commonly liked or approved": the most frequently encountered is Windows 10. So too is the most "commonly liked". 3% is still 3% and far and away a minority and definitely not in any way "popular", by any definition I can find.
It seems like a very good idea to not allow passwords that can't be input on 3% of commonly used Windows computers. 3% is still a very significant number when it comes to compatibility, customer support, etc.
I'm pretty sure that most of the on-screen keyboards for TV / streaming device platforms don't support emoji.
(I've spent about 6 years of my career running video streaming services... People watch a lot of video on TVs, it turns out, so you probably don't want to let them put these sorts of characters into their passwords when they sign up on mobile or computer devices.)
For better and a (lot) worse most of the TV / streaming device platforms are Android-derived and have access to emoji keyboards if not intentionally disabled, even on TV form factors. I realize it is a wide spectrum of users and a long tail of devices, but at some point again it isn't a technical reason that we are banning emoji from passwords but a political and lowest common denominator reason.
I'm not trying to invalidate your personal experience. You've seen a lot of good social reasons users probably "can't" be trusted with emoji passwords. but at a purely technical level the number of OSes in 2023 that can't pop up an emoji keyboard if asked is incredibly slim and the number that can't have an emoji keyboard in user space as a software addon is even slimmer. If a device doesn't support at least UTF-8 encodings in 2024 that's an entirely different can of worms (and probably a bad sign for the security of the device itself).
Both the Xbox and PS4+ have emoji keyboards. Apple TV has an emoji keyboard. Almost every version of Android TV and Samsung Tizen and Roku and Fire OS and ….
Go ahead, tell me you have a lot of customer support problems that you don't want to support emoji in passwords. That I can believe. I can't believe it's a technical problem in 2023. Emoji are universal enough now in 2024 that OSes are broken if they can't send/receive emoji and don't have some sort of keyboard to input them. Even if we are still turning off the emoji buttons on password fields because we don't trust users to do it for social reasons rather than technical ones.
> I can't believe it's a technical problem in 2023. Emoji are universal enough now in 2024 that OSes are broken if they can't send/receive emoji
As I said, it's not about support for emoji as a class.
It's about support for specific emoji. Different OS's are on different versions of Unicode that support different sets of emoji. The older versions don't support the newer emoji.
So yes, in 2024, it would be incredibly easy to create a password using an emoji on your up-to-date Mac that simply can't be entered on your Android-based TV you purchased 3 years ago, because it doesn't have that emoji even though in supports emoji in general.
So no -- it's not for social reasons, it's very much for technical ones.
And trying to implement a rule like "emoji are allowed but only the ones that were present in Unicode 6.0" is incredibly confusing and opaque for end-users, so it's a better experience just to not allow emoji at all.
I'm sure that's true - but, as an application developer and service operator, we don't really have the option to access the keyboards that are hidden by the TV OSs that we are running on.
Additionally, I'm not sure that supporting full Unicode access (or even just the hundreds (?) of emoji) using a D-pad as an input device would be a good UX.
It's probably better if it shouldn't. It's generally better to prevent passwords from containing characters that can't be entered on a decent proportion of devices you may encounter.
Emojis are particularly problematic because new ones keep being added which require OS upgrades, and you might find yourself needing to log in from another device that just doesn't support those emojis yet.
Also it's not like Unicode makes everything easy. For example, you have to remember to normalize the password before hashing. Otherwise something as simple as "ñ" may be a totally different byte sequence depending on which device you're using.