Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

eng.getwisdom.io

Post reply on HN
Print view View original

81–90 of 231 posts

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#81

Post by tim333 »

Iv wrote: post #59
BoppreH wrote: post #36

I love Unicode, but I'm more and more coming to the conclusion that strings are evil and should be treated as opaque byte arrays, whose only available operation is rendering into a bounded area. I now see any other string operation as code smell. It's scary how much of our infrastructure relies on strings, given how few guarantees string operations actually give. Take files names, for example. Two visually identical…

Disclaimer: as a heavy user of unicode, using it for both French and Japanese, I love it and see how important it is in the world. I just ranted about why ASCII is important to programmers: https://news.ycombinator.com/item?id=21760540 and this is a perfect example. ASCII has almost a 1-to-1 mapping between screen representation and byte representation. Once you know your font will differentiate between 1 i L | l and…

I was thinking that. Unicode is great for presenting text to users but for file names, email addresses, code and the like ASCII has a lot going for it.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#82

Post by scythe »

BoppreH wrote: post #36

I love Unicode, but I'm more and more coming to the conclusion that strings are evil and should be treated as opaque byte arrays, whose only available operation is rendering into a bounded area. I now see any other string operation as code smell. It's scary how much of our infrastructure relies on strings, given how few guarantees string operations actually give. Take files names, for example. Two visually identical…

So here's the thing. When you display a word written entirely in Cyrillic characters, it would be wrong for it not to display as normal text.

But when you display a word that contains eight Latin characters and one Cyrillic character, couldn't the display create some sort of warning? Highlight the section-mismatched character with a box? It's not normal in any language to mix alphabets.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#83

Post by BoppreH »

mc3 wrote: post #70
BoppreH wrote: post #60

Earlier quoted context omitted.

There are exceptions, of course. Fuzzy search is one of them. Image editing software and programming language parsers are another two. And what's the problem of letting the user type a URL? You take the resulting string (given to you by the OS subsystem responsible for keyboard input), and stuff that into your favorite HTTP library. Don't get me wrong, strings are absolutely necessary. I'm not suggesting we switch to…

I just write a lot of code that looks inside strings, in simple 'crud' apps, so I can't imagine avoiding these kinds of operations. Of course if you can use highly trusted libraries and just pass 'em around it's OK. But the Github issue was sort of subtle. In hindsight it seems like an obvious one, but it's a mistake I typically see in a lot of code reviews I've done where people just reach for the convenient variabl…

String matching is inherently fuzzy. I haven't tested it, but I think a dropdown box to select your account would be best. This would also help with other normalizations (accents, spaces), and even typos if user enumeration is not a problem.

I put abuse detection system in the same category as tests, it gets a free pass on most cleanliness requirements.

The typed strings pattern is a great one. In this case you could go as far as having a RegisteredEmail types, and requiring that in your MailerHelper.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#85

Post by asveikau »

microcolonel wrote: post #23
kevin_thibedeau wrote: post #22

Earlier quoted context omitted.

You can't assume that '+' has special meaning that can be stripped away.

Why not? On most major hosts it has a special meaning, and otherwise it is a relatively ridiculous thing to just add willy-nilly to your email address. We keep your verified mailbox address, the one you gave us, for sending mail. I doubt we'll ever turn away a customer by preventing registration of a new account sharing the prefix to a plus sign in their email address with an existing customer.

> Why not? On most major hosts it has a special meaning

So at best you can special case for those "major hosts" and not apply such treatment to any other domain.

The RFCs for email don't say "uhh dude whatever, just check what gmail does and maybe hotmail too lol". You are playing fast and loose with these things.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#86

Post by jkaptur »

BoppreH wrote: post #36

I love Unicode, but I'm more and more coming to the conclusion that strings are evil and should be treated as opaque byte arrays, whose only available operation is rendering into a bounded area. I now see any other string operation as code smell. It's scary how much of our infrastructure relies on strings, given how few guarantees string operations actually give. Take files names, for example. Two visually identical…

You’ve read my mind! I’ve been meaning to give a talk where I just go down the list of string methods and point out how each one is a hideous source of bugs.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#87

Post by hashStuff »

Would this not have been solved if the email addresses were stored as hashes? Besides this it would be an extra layer of security in the even of a breach. Why addresses aren't stored as hashes seems silly. Especially when stored in true databases that can be queried quickly.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#88

Post by iudqnolq »

Avamander wrote: post #79
iudqnolq wrote: post #77

Earlier quoted context omitted.

I agree completely. I might do .+@.+\..+ on the frontend to catch people mixing up usernames and emails, but that's it. You might not be surprised that regex comes from a Perl module :)

To be honest, login forms should take both username and e-mail as the user identifier, far too often they don't. I personally think that the only place where such a regex should exist is during sign-up.

Fair enough, although you could I suppose run into issues doing that retroactively if you allowed `@` in usernames...

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#89

Post by camgunz »

BoppreH wrote: post #58
kortex wrote: post #43

Earlier quoted context omitted.

How do you do the rendering? Who (process-wise) is responsible for converting bytes to pixels? How do users on social media put in their name? How is it stored? How do users get urls with specific usernames? Now take all that and multiply by the complexity of world languages, many which don't even map to one glyph == one morpheme. The ol' apple message crash bug was due to the property of some Arabic not being monoto…

The problem is now deeply entrenched, so I don't have perfect answers. But here are my guesses: > Who (process-wise) is responsible for converting bytes to pixels? The operating system, with minor exceptions (word processors, for example). Rendering logic is too complicated to be embedded into every application. And you get better accessibility and consistency. > How do users on social media put in their name? How is…

UTF-16 is way better for many Asian languages. You know, languages billions of people use.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#90

Post by fizx »

iudqnolq wrote: post #65
deathanatos wrote: post #3

This blog sets opacity: 0 (fully invisible) on the entire content, then fails to unset that CSS with JS, b/c the JS crashes if you block cookies. > because the system lowercased the provided email address and compared it to the email address stored in the user database. While sending the email to the attack-provided email, instead of the one in the database, is bad… lowercasing emails is also not valid. The lookup sh…

A few tiny nitpicks: The local part MUST be treated as case-sensitive, servers are discouraged from doing so (as Gmail does): https://tools.ietf.org/html/rfc5321#section-2.4 Github shouldn't have normized case, but it's not insane to require lowercase in the first place I think so long as you don't convert silently. I wouldn't call +extensions and ignoring dots weird because Gmail does that and fairly or unfairly the…

That's more of a proof that regexes can't do everything, than a proof email is bad.
Post reply on HN