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.
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.
A client once had an issue where his account got compromised and everything pointed to having his actual login details leaked.
His password was something like his username plus an assortment of random characters. It turned out that the system his account was on basically ignored everything after the 8th character, so that you were able to login with the username as the password.
Also, during the early days of inline password generators, there were cases where the suggested password was incompatible with the associated system.
It's common when there's a web interface bridging directly into a legacy mainframe system built in the 70s.
That's how you see things like "your password can't contain Q or Z" (it was originally a rotary phone-dial interface and ancient US phones didn't have Q or Z[0] — to say nothing of special characters, this means the system may also map letters (case-insensitively) to numbers grouped by 3… think your password is "fido"? it's actually encoded as 3436)
> Also, during the early days of inline password generators, there were cases where the suggested password was incompatible with the associated system.
That still happens to this day. There are still a ton of password forms out there which only accept very short alphanumeric-only passwords.
I enjoy seeding a random password generator with a bunch of non-ascii characters [1]. Often it fails telling me that I'm using unsupported characters, other times the form just doesn't return (or returns with a 5xx error), and even worse sometimes it lets me create the account but I can't login because they did something weird with those characters. I'd say less than 70% of sites let me login with one of these in my password...
At the very least try to use one of them (generally a simple alt-code works, the first smiley face is just alt+1), it's a pretty good indicator of which sites are mucking with your passwords.
[1]•◘○◙►◄↕‼¶§▬↨↑↓
Edit: Turns out HN strips a bunch of them, so my smilies and a bunch of others didn't make the cut!
Try to create a password at Jet2.com. A Password like: "SuperSecretPassword!" gives you an error "Your password must be at least six characters or more and is case sensitive.". It's idiotic.
If you call in to your fidelity account, they ask you to type in your username and password with the keypad to authenticate yourself. I haven't given it much thought, so perhaps I'm wrong, but this struck me as probably based on some dicey insecure backend implementation.
VirginMedia (large ISP in the UK) won't accept passwords longer than 10 characters. No spaces or special characters allowed, must contain a number, must start with a letter etc.
Swedbank in Sweden have a feature where you can access an accounts entire balance by generating random CC#'s for online shopping and this service is protected by your social security number, a 6 character password, a-z, 0-9 and no special characters allowed.
They've had this for at least 6 years now, maybe longer. Early on when I e-mailed them about it they simply stated that it's not their service, in other words; out-sourced.
One of my neighbors when I was growing up worked in the FBI's cybercrime division. His wife always complained about how he never let her do any of their banking or serious financial transactions online. When I hear stuff like this, I get why.
Which makes you think - Schwab is keeping probably billions of dollars safe. I've never heard of a theft from them, including via online account compromise. Meanwhile, many other sites doing better jobs of following security best practices can't keep even email addresses secure.
Maybe we're the ones doing it wrong, and it's us that should be learning from them?
If you also can choose your account name, use it as sort-of additional password space.
I have accounts with several instances where I could give you my password without running much risk of you logging in; even if their phone support would give out my account name, chances are they or you would misspell the line noise that it looks like.
My bank (German "Sparkasse") only allows passwords with exactly 5 letters or numbers for their online banking. I asked why they're doing this, but didn't get a good response.
Would love it if there were some kind of markup standard that password managers could read to determine the site's password rules when generating strong passwords.
I have the problem now with sites that don't tell you their password policy - I'll try several times to generate a password in LastPass and then end up with several entries for the same site, which I now need to inspect to determine which one is the one I don't want to delete. Hugely annoying.
I would love it if there were FCC-mandated password handling standards, like a (long) minimum max length, a (wide) mimimum permissible charset, and forbidden plaintext storage. It's arguably an issue of national security.
There sort of is. In HTML5, text-based form elements have a new "pattern" attribute which takes a regular expression that matches valid input, so the browser can do client-side validation without using JavaScript to intercept the form before it's posted and such. Assuming the site developers have bothered to implement it on their site, then theoretically a password manager could use that to determine valid characters for generated passwords (or, at least, invalid ones). I don't know if any of them actually do this, though.
The thing is, how many sites are going to have developers clued-up enough to incorporate this markup, but not clued-up enough to avoid stupid password policies that break password managers?
We only run into trouble because sites incorporate silly requirements like "you must have at least one symbol, even if your password is 48 characters long." Fixing that really seems like the better and more attainable goal.
Solaris, an otherwise good quality enterprise operating system, had an 8-character limit just like that for decades. They only fixed it in the default configuration maybe five years ago. You can read about it here: http://blog.mc-thias.org/?title=solaris-10-password-length-l...
Such problems are the reason why I never use anything but ASCII letters as passwords (if the system doesn't enforce arbitrary password policies). I'd rather have a longer ASCII-only password than a shorter one I might not be able to input.
There's also the issue that often you are not sure what keyboard layout is current enabled and even such unsuspicious characters like ! or # are on completely different locations on different keyboard layouts (then there's the z-y swap on German derived keyboards and have you ever had a look at a French keyboard layout?).
You can never be sure if a system locks you out after failed attempts, so I want to be sure that there are as few error sources as possible.
I got bit one time at work by setting a password as "$foo", instead of "foo$" or "fo$o" ... turns out the password-setting script was written in perl and Strange Things happened where only some systems got updated but not others.
Honestly, probably exploitable now that I'm thinking about it... I'll have to stop by the security group and give them something to chew on over the holidays.
I had the same problem at the university with a password with '*' in it. It was actually some old bash script behind it which would update random things.
What don't you like about it? I'm slowly getting used to the layout as I learn Russian, and the position per letter frequency feels about right for me. That is, most of the time my slowness in typing in Russian is a result of poor vocabulary and having to think about word agreements rather than feeling like letters are out of the way.
Hmm. Not really related, but now that it seems to be fixed - I discovered that using an equals sign in your name was enough to be "locked out" of Airbnb - it wrecked the cookie & every page would return 403. No bug bounty though haha. Guess it wasn't enough of an "attack vector" to try and convince someone to change their name.
I know of an online store that if you use a + in your email address, will fail to charge you for any goods you order.
I'm assuming because something somewhere on their backend assumes that '+' is an invalid email character and refuses to process the job. This is unbelievably common.
I remember finding somewhere that let me sign up with a +, but not log in with it - unless I disabled client-side validation, at which point the server was happy to let me in.
I hope I get lucky with something like that one day!
It's more usual that the front end thinks '+' is invalid too. The usual result is that my signup attempt is blocked. And when I send them feedback about it, I'm roundly ignored.
I had all kinds of trouble trouble with my abc@firstname.lastname.name mailadress. Some did not recognize .name. Others had trouble with the third level domain. Sometimes the sign-up worked but something in the backend broke...
I have had something similar bite me, although mine was easily fixed. I used swedish (åäö) characters for my disk encryption password. This worked fine, until I did a dist-upgrade and had my boot keyboard reset to US QWERTY (using a custom swedish version of capewell-dvorak).
"NOTE: if you use a non-US keyboard and need to enter a passphrase during boot, this may be problematic if the keyboard mapping is US while Slackware runs from the initrd filesystem. In this case, add support for your keyboard to the initrd image using this additional parameter to the 'mkinitrd' command above: "-l <language>". The string <language> is the same as the one you select in the installer when your keyboard is non-US. Example for a dutch keyboard: "-l nl"."
Now I'm warned that other systems that use automated kernel updates may clobber the keyboard choice for the initrd.
A similar problem is having a UK pound sign (£) or double quotes (") in your password. These are mapped differently in UK and US keyboards, and £ is sometimes not easily available at all.
I'm pretty sure the standard US layout offers more than enough symbols to write an excellent password.
I tend to prefer extremely long passwords/phrases over things that require stupid characters (had trouble with WiFi keys using the French "é" back in 2008, all my passwords are ASCII since)
You only need access to two symbols to be able to write an excellent password. But that doesn't mean it would be reasonable to, for example, restrict a password to only allow 1 and 0.
Many Linux installers suffered for years the situation that you would enter you password in the setup process with a different keymap than the one you got once the system then loaded, e.g. y-z were mismatched cause I was using QWERTZ instead of QWERTY. I think I saw something similar lately with on of the OSX'es.
The Chrome password manager still crashes the entire browser when trying to save any password with emoji in it on Windows. Firefox works perfectly fine.
Reminds me of a time in France when someone at a customer site complained they were locked out of their laptop - his Win NT4 laptop had a QWERTY keyboard but he put his password in french using the keyboard switcher in the OS. Back then Windows didn't allow you to change keyboard type at the login screen - it kept what you were using when you logged off...
In college I worked at an Apple store. One day while on break in the back of the store, I changed my company account password to a lengthy sentence, something at least 30+ characters. The system accepted the change.
When I tried to log in to the timeclock application again using the password, it threw Null Pointer Exceptions (it was a Java app, incidentally). In order to get back on the clock and get paid again, I had to reset my password -- but entering my current password into the "old password" field caused the system to throw more Null Pointer Exceptions.
I called Apple IT to do a manual reset of my password, and after explaining my situation, the response a very cold, concise and condescending "why would you do this..."
Was really surprised to see such a great solution and walkthrough. I had no idea Mac's had "unicode text input" software on default machines. I wonder why Window's hasn't upgraded charmap.exe over the years?
Ok and hear me out on this: a startup idea based on emoji passwords that encodes/decodes emojis into their hex/binary equivalent. takers?
Well, "startup" is a poor choice of words, but he actually has a half-decent idea.
As someone who owns dozens of little "tool" sites (think less/scss converters, meme generators, JS beautifiers, etc), I can tell you each is probably 1-2 pages, took an hour to build and thankfully due to some domain squatting (kw in domain) and a low bounce rate I don't have to worry much about SEO.
As for the Adsense revenue, I think you'd be quite surprised.
One is an afternoon, not a startup idea.
50, on the other hand, could be passive income for a very long time.
Just something to consider before jumping to negativity. ;)
Sure it's a silly thing to try, but this is entirely an oversight on Apple's part and is squarely their fault. They had the power to make this situation impossible and they didn't.
I used ® as my password during (what Americans would call) middle school. Alt+numpad works on the Windows XP login screen. It never caused me any trouble.
You can use Emoji characters in Wifi network names. My network name is [POOP]. See what kind of fun you can have at the airport by making an ad-hoc network called [AIRPLANE][BOMB].
I had problems when I set my admin username on my windows laptop to when setting it up for the first time. It wouldn't let me do things which required admin, iirc.
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.
9 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.
2 replies →
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.
A client once had an issue where his account got compromised and everything pointed to having his actual login details leaked. His password was something like his username plus an assortment of random characters. It turned out that the system his account was on basically ignored everything after the 8th character, so that you were able to login with the username as the password.
Also, during the early days of inline password generators, there were cases where the suggested password was incompatible with the associated system.
There's a lot of crap out there: http://www.troyhunt.com/2011/01/whos-who-of-bad-password-pra...
It's common when there's a web interface bridging directly into a legacy mainframe system built in the 70s.
That's how you see things like "your password can't contain Q or Z" (it was originally a rotary phone-dial interface and ancient US phones didn't have Q or Z[0] — to say nothing of special characters, this means the system may also map letters (case-insensitively) to numbers grouped by 3… think your password is "fido"? it's actually encoded as 3436)
> Also, during the early days of inline password generators, there were cases where the suggested password was incompatible with the associated system.
That still happens to this day. There are still a ton of password forms out there which only accept very short alphanumeric-only passwords.
[0] https://upload.wikimedia.org/wikipedia/commons/7/7b/Rotarydi...
I enjoy seeding a random password generator with a bunch of non-ascii characters [1]. Often it fails telling me that I'm using unsupported characters, other times the form just doesn't return (or returns with a 5xx error), and even worse sometimes it lets me create the account but I can't login because they did something weird with those characters. I'd say less than 70% of sites let me login with one of these in my password...
At the very least try to use one of them (generally a simple alt-code works, the first smiley face is just alt+1), it's a pretty good indicator of which sites are mucking with your passwords.
[1]•◘○◙►◄↕‼¶§▬↨↑↓
Edit: Turns out HN strips a bunch of them, so my smilies and a bunch of others didn't make the cut!
3 replies →
Try to create a password at Jet2.com. A Password like: "SuperSecretPassword!" gives you an error "Your password must be at least six characters or more and is case sensitive.". It's idiotic.
3 replies →
If you call in to your fidelity account, they ask you to type in your username and password with the keypad to authenticate yourself. I haven't given it much thought, so perhaps I'm wrong, but this struck me as probably based on some dicey insecure backend implementation.
7 replies →
> think your password is "fido"? it's actually encoded as 3436)
A form of hashing... ⸮
VirginMedia (large ISP in the UK) won't accept passwords longer than 10 characters. No spaces or special characters allowed, must contain a number, must start with a letter etc.
5 replies →
That's how Schwab.com implements passwords. 8 characters max. For life savings brokerage accounts.
Swedbank in Sweden have a feature where you can access an accounts entire balance by generating random CC#'s for online shopping and this service is protected by your social security number, a 6 character password, a-z, 0-9 and no special characters allowed.
They've had this for at least 6 years now, maybe longer. Early on when I e-mailed them about it they simply stated that it's not their service, in other words; out-sourced.
8 replies →
One of my neighbors when I was growing up worked in the FBI's cybercrime division. His wife always complained about how he never let her do any of their banking or serious financial transactions online. When I hear stuff like this, I get why.
8 characters max
Ha. Even better, they're also CASE INSENSITIVE!!!
We discussed this here a year ago: https://news.ycombinator.com/item?id=8783790
Which makes you think - Schwab is keeping probably billions of dollars safe. I've never heard of a theft from them, including via online account compromise. Meanwhile, many other sites doing better jobs of following security best practices can't keep even email addresses secure.
Maybe we're the ones doing it wrong, and it's us that should be learning from them?
If you also can choose your account name, use it as sort-of additional password space.
I have accounts with several instances where I could give you my password without running much risk of you logging in; even if their phone support would give out my account name, chances are they or you would misspell the line noise that it looks like.
1 reply →
My bank (German "Sparkasse") only allows passwords with exactly 5 letters or numbers for their online banking. I asked why they're doing this, but didn't get a good response.
1 reply →
That used to be true, but Schwab has since removed their character limit. I just updated my password to one having more than sixty characters.
They fixed that recently. Change your password
*Handled
They now support 200+ character passwords.
Would love it if there were some kind of markup standard that password managers could read to determine the site's password rules when generating strong passwords.
I have the problem now with sites that don't tell you their password policy - I'll try several times to generate a password in LastPass and then end up with several entries for the same site, which I now need to inspect to determine which one is the one I don't want to delete. Hugely annoying.
I would love it if there were FCC-mandated password handling standards, like a (long) minimum max length, a (wide) mimimum permissible charset, and forbidden plaintext storage. It's arguably an issue of national security.
(Or some other appropriate regulatory agency).
1 reply →
There sort of is. In HTML5, text-based form elements have a new "pattern" attribute which takes a regular expression that matches valid input, so the browser can do client-side validation without using JavaScript to intercept the form before it's posted and such. Assuming the site developers have bothered to implement it on their site, then theoretically a password manager could use that to determine valid characters for generated passwords (or, at least, invalid ones). I don't know if any of them actually do this, though.
http://www.w3.org/wiki/HTML/Elements/input/password
The thing is, how many sites are going to have developers clued-up enough to incorporate this markup, but not clued-up enough to avoid stupid password policies that break password managers?
We only run into trouble because sites incorporate silly requirements like "you must have at least one symbol, even if your password is 48 characters long." Fixing that really seems like the better and more attainable goal.
Solaris, an otherwise good quality enterprise operating system, had an 8-character limit just like that for decades. They only fixed it in the default configuration maybe five years ago. You can read about it here: http://blog.mc-thias.org/?title=solaris-10-password-length-l...
Such problems are the reason why I never use anything but ASCII letters as passwords (if the system doesn't enforce arbitrary password policies). I'd rather have a longer ASCII-only password than a shorter one I might not be able to input.
There's also the issue that often you are not sure what keyboard layout is current enabled and even such unsuspicious characters like ! or # are on completely different locations on different keyboard layouts (then there's the z-y swap on German derived keyboards and have you ever had a look at a French keyboard layout?).
You can never be sure if a system locks you out after failed attempts, so I want to be sure that there are as few error sources as possible.
I got bit one time at work by setting a password as "$foo", instead of "foo$" or "fo$o" ... turns out the password-setting script was written in perl and Strange Things happened where only some systems got updated but not others.
Honestly, probably exploitable now that I'm thinking about it... I'll have to stop by the security group and give them something to chew on over the holidays.
I had the same problem at the university with a password with '*' in it. It was actually some old bash script behind it which would update random things.
I got bit by this problem before. I wrote a one liner to avoid generating passwords where the keyboard might be an issue [1].
1. http://www.tillett.info/2013/05/29/letters-to-avoid-in-creat...
As somebody who uses numerous keyboard layouts on a daily basis, this is an interesting idea!
I wonder how hard it'd be to make a script where you specify which keyboard layouts you're likely to encounter and it finds the common symbols...
Of course, if you specify dvorak it'd wreck everything :)
> ... have you ever had a look at a French keyboard layout?
My favorite one is Russian. I understand Cyrillic characters, but their positions are just completely messed up.
What don't you like about it? I'm slowly getting used to the layout as I learn Russian, and the position per letter frequency feels about right for me. That is, most of the time my slowness in typing in Russian is a result of poor vocabulary and having to think about word agreements rather than feeling like letters are out of the way.
Hmm. Not really related, but now that it seems to be fixed - I discovered that using an equals sign in your name was enough to be "locked out" of Airbnb - it wrecked the cookie & every page would return 403. No bug bounty though haha. Guess it wasn't enough of an "attack vector" to try and convince someone to change their name.
I know of an online store that if you use a + in your email address, will fail to charge you for any goods you order.
I'm assuming because something somewhere on their backend assumes that '+' is an invalid email character and refuses to process the job. This is unbelievably common.
I remember finding somewhere that let me sign up with a +, but not log in with it - unless I disabled client-side validation, at which point the server was happy to let me in.
5 replies →
I hope I get lucky with something like that one day!
It's more usual that the front end thinks '+' is invalid too. The usual result is that my signup attempt is blocked. And when I send them feedback about it, I'm roundly ignored.
I had all kinds of trouble trouble with my abc@firstname.lastname.name mailadress. Some did not recognize .name. Others had trouble with the third level domain. Sometimes the sign-up worked but something in the backend broke...
1 reply →
I have had something similar bite me, although mine was easily fixed. I used swedish (åäö) characters for my disk encryption password. This worked fine, until I did a dist-upgrade and had my boot keyboard reset to US QWERTY (using a custom swedish version of capewell-dvorak).
The solution for me was to stick on LTS distros.
A quote from the Slackware README_CTYPT.txt
"NOTE: if you use a non-US keyboard and need to enter a passphrase during boot, this may be problematic if the keyboard mapping is US while Slackware runs from the initrd filesystem. In this case, add support for your keyboard to the initrd image using this additional parameter to the 'mkinitrd' command above: "-l <language>". The string <language> is the same as the one you select in the installer when your keyboard is non-US. Example for a dutch keyboard: "-l nl"."
Now I'm warned that other systems that use automated kernel updates may clobber the keyboard choice for the initrd.
"May" as in "most certainly did", at least when you are lazy like me and use a GUI-centered distro.
I ended up plugging the harddrive into another computer and fixing it from there.
I never got that shit from slackware...
2 replies →
I have to input a different keyboard when logging in through sddm vs. when using sudo, due to sddm refusing to accept non-US locales.
2 replies →
A similar problem is having a UK pound sign (£) or double quotes (") in your password. These are mapped differently in UK and US keyboards, and £ is sometimes not easily available at all.
You can still write åäö with the numpad if your keyboard has one.
Alt + 134 = å
I tried that. The LUKS password screen did not support it.
3 replies →
Incorrect. Linux does not support alt codes.
https://en.wikipedia.org/wiki/Alt_code
I'm pretty sure the standard US layout offers more than enough symbols to write an excellent password.
I tend to prefer extremely long passwords/phrases over things that require stupid characters (had trouble with WiFi keys using the French "é" back in 2008, all my passwords are ASCII since)
Of course, characters that I use in my everyday language aren't "stupid" to me.
2 replies →
Every language that is not American English is "stupid"?
3 replies →
It was a long password phrase. One of the words just happened to be in my mother tongue.
I'm baffled that the standard US keyboard layout doesn't even have the ° character, something I use all the time.
4 replies →
You only need access to two symbols to be able to write an excellent password. But that doesn't mean it would be reasonable to, for example, restrict a password to only allow 1 and 0.
I had to use a system once that accepted the "stupid characters" ( and ) in the password on account creation, but not on login...
On one hand, I want to leave a witty comment in the line of "play stupid games, win stupid prizes".
On the other hand, I'm sad that I didn't try to do that myself.
Many Linux installers suffered for years the situation that you would enter you password in the setup process with a different keymap than the one you got once the system then loaded, e.g. y-z were mismatched cause I was using QWERTZ instead of QWERTY. I think I saw something similar lately with on of the OSX'es.
The Chrome password manager still crashes the entire browser when trying to save any password with emoji in it on Windows. Firefox works perfectly fine.
Well, the account is now secure. Objective achieved?
Reminds me of a time in France when someone at a customer site complained they were locked out of their laptop - his Win NT4 laptop had a QWERTY keyboard but he put his password in french using the keyboard switcher in the OS. Back then Windows didn't allow you to change keyboard type at the login screen - it kept what you were using when you logged off...
In college I worked at an Apple store. One day while on break in the back of the store, I changed my company account password to a lengthy sentence, something at least 30+ characters. The system accepted the change.
When I tried to log in to the timeclock application again using the password, it threw Null Pointer Exceptions (it was a Java app, incidentally). In order to get back on the clock and get paid again, I had to reset my password -- but entering my current password into the "old password" field caused the system to throw more Null Pointer Exceptions.
I called Apple IT to do a manual reset of my password, and after explaining my situation, the response a very cold, concise and condescending "why would you do this..."
Was really surprised to see such a great solution and walkthrough. I had no idea Mac's had "unicode text input" software on default machines. I wonder why Window's hasn't upgraded charmap.exe over the years?
Ok and hear me out on this: a startup idea based on emoji passwords that encodes/decodes emojis into their hex/binary equivalent. takers?
Is "startup" now synonymous with "thing that I built in 2 hours and have no ability to monetize"?
Well, "startup" is a poor choice of words, but he actually has a half-decent idea.
As someone who owns dozens of little "tool" sites (think less/scss converters, meme generators, JS beautifiers, etc), I can tell you each is probably 1-2 pages, took an hour to build and thankfully due to some domain squatting (kw in domain) and a low bounce rate I don't have to worry much about SEO.
As for the Adsense revenue, I think you'd be quite surprised.
One is an afternoon, not a startup idea.
50, on the other hand, could be passive income for a very long time.
Just something to consider before jumping to negativity. ;)
8 replies →
I'm not sure he was being 100% serious.
Wasn't it always?
You try to make things idiot-proof and they bring in better idiots.
1) The user tried to see if emoji can be used for the password.
2) Without checking on the web/forums/etc first.
3) On their main user account (not a disposable one).
4) With FileVault turned on.
I can't even...
Sure it's a silly thing to try, but this is entirely an oversight on Apple's part and is squarely their fault. They had the power to make this situation impossible and they didn't.
I used ® as my password during (what Americans would call) middle school. Alt+numpad works on the Windows XP login screen. It never caused me any trouble.
This is the funniest thing I've read in a while.
You can use Emoji characters in Wifi network names. My network name is [POOP]. See what kind of fun you can have at the airport by making an ad-hoc network called [AIRPLANE][BOMB].
Seems to be a good way to be exempted of business trip to/from the US for the rest of your life. Too bad it also affects leisure trips.
Shit at least have them cats work for it.
Can't wait till someone handles their own gf before they invoke me. Fun stuff this goes unpoorly undo only them poors
I had problems when I set my admin username on my windows laptop to when setting it up for the first time. It wouldn't let me do things which required admin, iirc.