Comment by Twisell
10 years ago
And this is a perfect reminder that you should never try some crazy things on your only administrator account on your production machine.
Had he test his point on a dummy account : delete account = problem solved
10 years ago
And this is a perfect reminder that you should never try some crazy things on your only administrator account on your production machine.
Had he test his point on a dummy account : delete account = problem solved
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.
Not trying to excuse OSX's behaviour, but non-technical users are the ones who use passwords like: abcdef, 123456, password123, etc.
In fact, using such characters (emojis, other unicode characters, etc.) in passwords should be considered a secure practice.
Technical users use Diceware because its the best way for the human mind to capture entropy.
https://en.wikipedia.org/wiki/Diceware
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.
8 replies →
If you read more of the answers, another poster says that this was fixed in El Cap by preventing the use of such characters in passwords.
And this is a perfect reminder that if you allow some crazy input in your system you will eventually get someone who inputs something crazy.
Had Apple properly validated the input and accounted for this case or disallowed it entirely they could have avoided this.
Don't mean to troll but there are two sides to every issue like this: blame the user or blame the developer.
Can't we do both?
Apple dropped the ball here by allowing a password to be set to something that could not be typed at the login screen.
The user was stupid for performing this experiment without an escape hatch.
Stating one does not exclude the other.
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.
1 reply →
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.