Hacker News Reader

Comment by notlukesky | Hacker News Reader

The likelihood of such a “hack” happening using the Turkish dotless “I” is ZERO as all Turkish email addresses and website domains are formatted WITHOUT using Turkish characters which include examples like: ç, ı, ü, ğ, ö, ş, İ, Ğ, Ü, Ö, Ş, Ç

If you are at interested in Turkish characters:

https://en.wikipedia.org/wiki/Wikipedia:Turkish_characters

https://www.turkcebilgi.com/türkçe_karakter

This should be called the Turkish character hack: A hack only possible in the theoretical realm.

These characters are rendered in HTML and supported by OSes. They are just not used for emails AND website domains.

So the password reset “hack” with an email containing Turkish characters in not a possibility from the get go.

The whole attack vector hinges on emails that exist with Turkish characters in the first place.

View on HN

This was a very real and demonstrated vulnerability. Perhaps I've misunderstood your comment.

There are no emails with Turkish characters. The whole attack vector hinges on emails that exist with Turkish characters in the first place.

That’s incorrect. The attack vector hinges on the ability to create email addresses with Turkish characters. There is nothing stopping an attacker from creating addresses with Turkish characters to attack existing addresses without Turkish characters.

https://en.wikipedia.org/wiki/Email_address#Internationaliza...

Turkish emails are not supported in the first place.

Internationalization examples[edit] The example addresses below would not be handled by RFC 5322 based servers, but are permitted by RFC 6530. Servers compliant with this will be able to handle these:

Latin alphabet with diacritics: Pelé@example.com

Greek alphabet: δοκιμή@παράδειγμα.δοκιμή

Traditional Chinese characters: 我買@屋企.香港

Japanese characters: 二ノ宮@黒川.日本

Cyrillic characters: медведь@с-балалайкой.рф

Devanagari characters: संपर्क@डाटामेल.भारत

RFC 6530 doesn't mention those character sets explicitly. It proposes allowing all Unicode characters, apart from some control characters.

It is true that the RFC recommends mailbox providers take normalization into account. A mailbox provider that allows i and dotless-i addresses to be routed to different mailboxes is careless, if not actually uncompliant. I don't know if any popular provider does this: I'm guessing the authors created their own to demonstrate this attack.

Unicode is such a disaster for data processing that it's unfair to call anyone careless for getting it wrong.

Turkish characters are not part of RFC 6530.

There are no email addresses with Turkish characters at all. They all use Latin characters.

It just does not exist - yet at least.

Yes, they are part of RFC 6530, via its references to RFC 3629 (UTF-8) and the Unicode standard.

EAI email addresses are legal email addresses, even if it's not guaranteed that all servers are capable of delivering to them.

You seem very confused. The hack did happen, therefore the probability of it happening is 100%.

Reply on news.ycombinator.com