I included emoji in my password and now I can't log in to my Account on Yosemite | Hacker News Reader

I included emoji in my password and now I can't log in to my Account on Yosemite

apple.stackexchange.com

392 pointsgdeglin144 comments

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.

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.

Users don't uniformly select ASCII characters but generally we accept 1 char of password length === 8 bits of entropy.

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.

> 1 char of password length === 8 bits of entropy

Oh hell no. https://xkcd.com/936/

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".

Technical users that had never heard of Diceware before, because it's obscure, don't use it :)

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.

The linked question states:

"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.

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!

The first "smiley face" on ALT-1 is actually the ASCII character SOH "start of heading"; many things that might otherwise accept Unicode will properly filter that out because ASCII control codes are illegal in a wide variety of otherwise-accepting contexts.

But it is a great QA check on any text field, which should either cleanly reject it in some manner [1] XOR accept it and process it "correctly" for whatever that means locally, but not something in between.

[1]: A lot of Unicode processing nowadays puts in the Unicode replacement character for unknown characters, but for the ASCII control codes I'd say you've often got a solid security case to say "Someone's just trying to screw with the system, we'll just filter it out entirely" for them. Excepting the ones we still use, basically \r \n \t, there's not much reason to keep them. (Think twice about \v "vertical tab" and think three times about letting \b "backspace"s through. Inconsistent behaviors by various layers of code are scary.)

It makes sense that control characters are removed (or replaced). I didn't know the ALT-1 was SOH, so that's good to know. (I guess I'm showing my age a bit there)

Thanks for the info!

> Turns out HN strips a bunch of them, so my smilies and a bunch of others didn't make the cut!

Which is exactly why I'd be wary of such clever password schemes on any account I cared about.

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.

Oh yes, I'd almost forgotten about the misleading, unhelpful or downright incorrect error messages. It's also fun when account creation and login form don't use the same validation rules, so you can create an account but then you can't log into it.

Even major sites suffer from this. Netflix web UI allows 60 character passwords, but their Roku app and I believe the Xbox One app only allow 50 character passwords.

I ran into that once with my credit card company. I used a generator to create a maximum length password, only to discover that the Javascript managing the login had an off-by-one error and wouldn't accept that length. I was able to work around it through judicious use of browser inspection tools -- the change password page accepted it just fine.

I sent in a complaint and got something to the effect of "well, no one else reported it."

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.

More likely it is to prevent your having to say your password to the person on the phone. This protects you from a malicious bank employee.

Right, but my point is the backend to make this work must be terribly insecure. I just did some reading, and apparently they take your password and just store the keypad equivalent (or more likely, a hash thereof). So you can login in to the website with your original password, the keypad mapping of that password, or any text password that maps to the same keypad digit mapping, and they all work.

> So you can login in to the website with your original password, the keypad mapping of that password, or any text password that maps to the same keypad digit mapping, and they all work.

I'd have to see this to believe it. I would hope that they would at least store it as two separate entries, and only use the phone one during the phone process. And the person on the phone will likely still ask you some less-sensitive verification questions.

I had googled just now and read that somewhere else, but you are right, I just tested it, and it does not work as I described on the website itself.

> they take your password and just store the keypad equivalent (or more likely, a hash thereof)

That's… not exactly more likely. These are commonly systems predating the internet, from a time when connected networks were trade-specific and Very Expensive, storage security was a lesser concern (and CPU-expensive) when the system could only be accessed on dedicated lines only accessible to employees.

That'd certainly make sense — a lot of what we see now are fossils like that, frozen in the amber of legacy systems.

That would be a reasonable precaution in the era before recording devices became cheap, tiny and ubiquitous (or capable of doing signal processing in real-time) – just as changing passwords monthly made more sense in the 1970s when shoulder-surfing was the major threat and lack of remote access throttled guessing rates even more than slow CPUs. (Repeat for plastic ID cards before you could buy a printer at Costco, etc.)

I don't know what Fidelity does, but I work at a bank and if we were to implement such a feature we handle it securely. When you set your password we store a hash of the password, but we also store a hash of the keypad version of your password.

So logins to the website still use the full character set -- only logins via the phone are verified against the keypad mapping. That one has less entropy (because of the reduced character set) but attempts to brute-force it will QUICKLY be recognized and stopped, since each attempt is visible to a human being who is handling the phone call.

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

What is really frustrating about this is when I asked them why they reply "we've chosen these limits to make sure your online password is secure"

I can imagine your facepalm.. Wondering how many of these "up to N characters" rules are actually there because there is a `password CHAR(N)` DDL declaration for storing plaintext passwords...

I tend to set password fields to varchar(400), though it's encoding info and base64 hashes.

    encoding\options\base64-salt\base64-hash-of-normalized-utf8

I keep the encoding/options so it can be backwards compatible on change... when an encoding/options isn't the current when the user logs in, it will be re-encoded/saved in the current... this is so that security can be upgraded over time.

Run normalization on composite unicode characters & look-a-likes before encoding.

I do one thing some consider bad, which is strip leading/trailing whitespace which is more often a copy-paste error, not actual password entry.

Additionally, if you contact their customer support via the form they used to provide they ask for your password, which is them presented back to you in plain text when they reply.

Quoting from a reply I had: "As there's no account password quoted on the form you’ve filled in I'm unable to go in to any account specifics."

"accountPassword: I'm not giving you my password"

Same with the Virgin Atlantic Flying Points site (usernames and passwords). Infuriating thing is the points are worth real money and can be transferred to other users so there is a real incentive to break in.

I guess it's a problem across the entire Virgin group of companies?

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.

Swedbank also requires two-factor authentication. You can bypasss this by calling them - they only ask for 1 thing to authenticate you. Two-factor authentication is rather useless if you can just bypass it like that.

>You can bypasss this by calling them - they only ask for 1 thing to authenticate you.

The domain for my personal site is shared with my family. My father registered the domain and all of the details in the account use his information. I had just created an AWS account and wanted to move the site's DNS to Route53.

I was able to call into the domain registrar and get exactly zero of the details correct, but they pointed the domain to Route53. It was hilarious how bad it was. I used my social, my name, my address, etc., none of which matched the info on file.

Even if I had used my father's info, it (except the social) would have been wrong because we lived overseas on a military base. When your system says Japan and someone from the US is calling, that should set off all sorts of alarm bells.

Yes, and I had no idea they were that easy to bypass on a social level.

Also this CC# generator falls outside of the 2FA scope, also something I asked them about several years ago and received the same reply "it's not our service".

It's scary.

Swedish social security numbers are public information btw, just to clarify the insanity - I can call in to the government register and ask for anyone's number, there isn't even any obfuscation or semi-privacy about it like US SSNs.

there isn't even any obfuscation or semi-privacy about it like US SSNs.

GOOD. The US "private" SSN system is completely messed up. You can't commit identity theft by just knowing a personnummer. Very, very much unlike the US...

But you can. People treat the full "personal numbers" as a secret and if you can recite one, nobody will think you're anyone different. It's not meant to be this way, but in my experience it is.

The Swedish personal numbers are not a secret, so that is not a protection in any kind. You can get the number for anyone by asking the tax agency.

reminds me of this story http://www.windytan.com/2015/04/trackers-and-bank-accounts.h...

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.

Yes, Schwab does let you choose your account name. I'm not sure how many chars it can have.

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.

When I asked, I got the answer that I could chose an arbitrary 16 character long user name, that the password may contain special characters, that the number of allowed failures for logging in is limited and that any actual money transfers are protected by a TAN. So it may not be that bad, given that the PIN for my EC card has only four numbers.

Still, I agree that this scheme is somewhat odd and no limitation on the password length would be preferable.

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).

Jurisdiction over which agency gets to do "cyber" stuff has been an open question for the last thirty years. You can make good arguments that it should be covered by the FBI, NSA, DHS, ATF, the secret service, etc etc.

(Yes, the Secret Service! The famous raid on Steve Jackson Games back in 1990 was actually carried out by Secret Service agents, who thought that GURPS Cyberpunk was an actual hacking manual.)

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.

If you ever order from HobbyKing (not the store I mentioned previously) do NOT have a plus in your email. It gets converted silently to a space in their internal systems and their customer support has absolutely 0 access or escalation.

They outsource everything, and ultimately it took me months to sort everything out.

That's insanely insecure. Can't believe client side validation would be used for a login system other than as a first check

I still needed the password (or so I assume). It was just a first check that was stricter than it should have been.

This is why backend and frontend need to share code!

I wouldn't be surprised if there were a significant number of bugs that have been fixed by deleting code.

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 can't even change my email adress to my .me domain on facebook because they keep telling me it's an invalid domain ending.

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

Slackware don't do shit.

In fact, Slackware don't do anything unless it's told, which is not as bad a thing as it may seem.

Took me some years to work it out but I have begun to appreciate Slackware since installing 14.1 summer before last.

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.

I have that one when running init 4 but the encryption pass phrase is before that stage of the boot up the way my laptop is set up. I'll remember that though...

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.

LUKS does not really have a password screen. It must have been your X-window session or terminal emulator that did not support it. LUKS can handle it!

It was actually neither, most probably. Rather, a prompt generated by https://wiki.freedesktop.org/www/Software/Plymouth/

Ah yes! Thanks for the correction.

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.

Even my name contains that "stupid" character :)

Although I have to agree with him I wouldn't use it in a Wifi password either.

That makes me wonder - how long before someone manages to put an emoji in their legal name?

Every language that is not American English is "stupid"?

No diacritics in Latin, either!

æ?

I believe that's a ligature not a diacritic [1]

[1] apologies, it appears to be the last pedantic Wednesday before Christmas

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.

I think we typically get around this by writing things like "122 degrees", "50C", "122F", etc. in informal settings.

It does have that character. Press Option-Shift-8.

The same Option key that isn't on the standard US layout either?

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?

  > a startup idea based on emoji passwords that encodes/decodes
  > emojis into their hex/binary equivalent.

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. ;)

Interesting. I would love to hear more details, like how much traffic you are bringing in total from these mini-apps and how much income from Adsense.

I have two books in my queue actually, and this is one of them.

There are parts of my content-property model I'm not ready to share, but most of it has been structured into a cohesive framework of how I:

1. find niches 2. automate site creation 3. optimize w/ gpt (google publisher tag)

I'm sorry to say I won't be releasing that first... The first is due within the next 12-14 days, after which it should take me 1-2 months to finish writing & editing the adsense-property-model guide.

To leave you with something tangible, it's very feasible to produce 5-figures per day with only hosting cost as your overhead ($300/mo).

[edit] without automation tools though, it would obviously be very tedious to produce the number of properties required to have that kind of income by hand. process flow & site generation/management is the crux of this strategy.

Thanks for the reply. Does site creation involve pure content sites as well as simple web apps? Or maybe some kind of hybrid for SEO purposes?

I would love to read more once you have something published. You should consider adding some contact info in your profile so that people won't go on a stalking expedition to find you (as i did) :)

Hah, the way you phrase that makes me wonder what you found.

Right now really just web apps. Content sites are doable, and I know people running networks, but it's not possible to do profitably without clickbaiting, low-quality mass-produced content, and other greyhat techniques I don't particularly like.

I think it's fair to show you an ad if I save you 30 seconds to a minute of time. Creating garbage content slideshows with writers from the 3rd world countries to rack up pageviews is one step over the line for me...

Simple apps are great because they have utility (so google always approves your tag), and honestly the doubleclick exchange isn't so bad -- with enough simple single-page apps, it accrues pretty quickly.

Automated site creation... what, you're taking some public domain content, loading it up with ads, then hoping it ends up higher in the SERP than the original source?

How is this different than filling amazon with autogenerated kindle "books" made from Wikipedia articles?

Not exactly, I think it was a poor choice of words as I was referring to my build/deployment tooling.

If I have an idea (e.g. a "ES2015 to ECMA6" converter), I'd look for a library to do this (if there isn't an open source one, I'd consider building my own as a learning experience).

Setting up the webpage up (converter/form) is trivial since it's really just one page and a few settings.

The really cool part is I've built laravel commands to do the hard work for me. They can:

- buy domains based on a keyword search with some common regex-like patterns

- set up a git hook to continuously deploy to an AWS micro instance via codedeploy/CircleCI

- manage different adsense codes across properties

So, if you're wondering these are things that have utility. I'm optimizing the pains of setting up each site, though.

I do build adservers for a living, but never once have I created a crappy content-farm click-baiting blog -- they are the scourge of the internet >:{

[edit] lastly, I'm not sure if you have a problem with google ads (doubleclick/google publisher network) but I think they're pretty sensible in what they allow... no reasonable person would take issue with that.

5 figures per day as in $10K+ every day? Impressive! How many of those tools require constant automation? Something like a CSS converter or JS beautifier should only need updating to fix bugs or due to updates of underlying libraries.

>5-figures per day

Where among them is the decimal point?

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.

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.

Reply on news.ycombinator.com