bugtraq - Re: Thoughts and a possible solution on homograph attacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 15 Mar 2005 19:10:16 -0500 (EST)
From: khockenb <khockenb@...vens.edu>
To: Riccardo Murri <murri@...m.uniroma1.it>
Cc: bugtraq@...urityfocus.com, Paul Smith <paullocal@...s.co.uk>
Subject: Re: Thoughts and a possible solution on homograph attacks

On Tue, 15 Mar 2005, Riccardo Murri wrote:

> I would rather suggest that the string comparison function used in IDN
> takes "homograph caracters"[1] into account: just like the current DNS
> considers 'a' == 'A', the IDN DNS should consider "LATIN SMALL LETTER
> a" == "CYRILLIC SMALL LETTER a" == "CYRILLIC CAPITAL LETTER A" ==
> "GREEK CAPITAL LETTER A"[2], and similarly for the other homograph chars.

But that breaks case insensitivity for Greek, for instance (other
languages, too, I am sure).

Consider Greek letters eta and nu.

A upper case eta looks like an upper case Latin "H", but a lower
case eta looks like a lower case Latin "n".

Similarly, an uppercase nu looks like a upper case Latin "N", but a lower
case nu looks like a lower case Latin "v".

If such a system as you suggest is in place, and someone in Greece wants
the site (Greek nu).gr, they would have to have control of both N.gr and
v.gr, otherwise people who type in the wrong case would go to the wrong
site.  Now let's say a competitor comes along, and wants (Greek eta).gr.
They can get H.gr, but n.gr is already take, since N=n.

I suppose we could get around that by making H=n=N=v(=V=H), but that would
get cohfusivg.