Well, really, it should just work or OSX should prevent this from happening in the first place.
Emoji are common among non-technical users---exactly the market that Apple supposedly caters to---and why would anyone expect a non-technical user to know that using emoji in a password would be considered "crazy", without knowing the extensive legacy of pre-Unicode systems, the location of many emoji outside the Basic Multilingual Plane, their relatively recent inclusion in Unicode 8.0, etc etc.?
It is a mistake to blame the user for something like this.
Its the non-technical users who try the silly stuff. A diceware password with 4 words is 51-bits of entropy. 5 Words gets you 64-bits of entropy.
For example, if you remember that "U+2708" is the Airplane emoji, why not just type the string "U2708" on the end of the password (ex: MyPasswordU2708). The longer password is going to add provably the same amount of entropy, and will work with virtually any system.
The old bits of entropy count is based on extended ASCII. In reality we could count UFT-8 code points, with each code point having 1/#code_point entropy.
As a brute force guesser can throw UTF-8 chars instead of attempting to rebuild emoji from their underlying ASCII string.
"with each code point having 1/#code_point entropy."
That requires that users be uniformly-randomly selecting Unicode characters. There's a number of problems with this idea, most notably that the resulting password would have an insanely high "difficulty to type"/"bit of entropy" ratio. By the time you're through your third keyboard mode switch or third character typed in via generic Unicode hex entry, a 4-word passphrase user already has logged in and opened their browser.
Mixing in a single Unicode character into your password might be sorta clever, but you probably shouldn't rely on getting a lot more "bits" out of it.
No, we do not. Six is a much better estimate (26 times 2+10 = 62, close to 64), and that's still for a uniformly-random selection, which many passwords are not even close to.
The "little obscure tricks" to increase the entropy of a password do NOT work well with human memory. If your template is "Uncommon Word + Emoji + 5 tweaks", your entropy is 50,000 (the uncommon word) x (number of Emojis) x 5 * 8 (there are roughly 8 ways to "tweak" a word).
There are no more than 500 Emojis that people use. You're not getting much entropy by choosing one. Now if you start choosing obscure Chinese words and Arabic symbols, maybe you'd be getting somewhere (It requires mastery of multiple languages to really exercise that UTF-8 dataset).
But honestly, an English-speaker will get far more entropy by just adding two more common words (top 5000) to their password. A new common word is worth a hell of a lot more than an Emoji. A phrase of 8 words (ie a sentence) is also very easy to memorize and contains a ton of entropy as well.
Even a simple sentence is impossible to brute force. The following sentence has probably never been said in the history of humanity:
"My long password to gmail.com is a passphrase, the current sentence that I just typed, lulz!"
That sentence is virtually unhackable and easy as heck to memorize. Sure, the entropy is only a few bits per character, but the length makes it better. And since it uses common letters, it is extremely quick to type.
So unless you plan on learning a new language to hit those obscure Unicode symbols, I think its best to just stick with what your brain is already wired to memorize: Words. Common English Words.
The only down side to that, is when you're trying to enter it on your phone. I do use sentences, but generally not that long... usually wind up with 15-20 characters, which is long enough. LastPass helps with some instances.
"F34r is the mind killer." as an example, does use replacement, but only in one of the words, it's short enough that phone entry isn't too bad, and is easy enough to remember. Given it's a phrase from a movie/book, but probably good enough.
That said, I probably wouldn't have thought to use an emoji, I know some people hate it, but I do filter whitespace at the beginning/end of protected entry (reset codes, etc), as copy-paste + whitespace errors are more common than leading/trailing whitespace in a password.
'"F34r is the mind killer." as an example, does use replacement,'
This is the sort of thing I mean, though, when I say we don't usually use fully random replacement. 3 for e, 4 for a, $ for s, these things add very little entropy overall because they are so common. We don't really use "symbols" in our passphrases; we use only !@$& probably overall, and those in highly stereotyped situations.
Suppose you know the first four characters of someone's password are "hous"; what's the next character? Big, big spikes around e and 3, maybe a smaller one on E and i/I, then "everything else".
You're assuming the user thinks they are performing an "experiment". When I use core OS functionality I don't think I'm "experimenting", I'm using the system.
I don't backup my C:\ drive before I "experiment" with the cut & paste tool.
If you saw an emoji keyboard pop-up on your change password screen it would be natural to just assume that the OS was now accepting emojis in passwords.
"I wanted to check if it's possible to use emoji in a password for my Account on OS Yosemite."
You're correct in general, but in this particular case they clearly saw this as something that might not work. They just didn't anticipate how badly "not work" could go.
Why not blame both parties here? I don't see it as a mutually exclusive "blame x or y" scenario.
This is clearly an input validation issue first and foremost, and we can blame Apple for that, but it's also a completely weird use case and obviously a non-standard path to password input given you don't have emoji keys on keyboards.
I don't expect average end users to know that unicode support in software is still iffy, but I would expect them to realize that having to bring up an alternate input dialog is deviating from computing norms. Doing weird things should trigger a red flag in everyone's heads that "maybe I shouldn't try this first on something I value". Doesn't even matter if it's a computer, you wouldn't try refueling your primary car with wine, despite it containing a plausibly similar sounding percentage of ethanol.
While you are technically correct, as someone who has published software to the general public for decades now I can assure you that users will do far worse things almost daily and it's always the developers fault if they allow that to break things.
Sometimes it's not a crazy thing to do. I'm writing in ASCII not, but my input format isn't always set to this.
Depending on combination of input method and storage method, especially when the screen doesn't display the number of characters being inputted, it is a mild pain. One to learn from, but a pain.
Working with colleagues don't use English regularly and that have a variety of IMEs (that in most cases display an identical result) and don't expect to hit Ctrl+Space, or whatever shortkey is being used for every input form... input tools that expect ASCII but don't return feedback are huge levels of pain.
Had he test his point on a dummy account : delete account = problem solved