Michael,
A few comments. First, in response to:
>I propose to present the user with a dialog showing the text to be
>validated and an input field, into which the user has to type in the
given >text again. The user is told, if both texts match precisely and
what this >means: If the typed text's internal representation matches
the given text >bit-by-bit, trust can be established. If it does not
match, the user is >told to re-check for typing errors and not to
establish trust.
It's very difficult to get people to agree to security at the expense of
usability. The average user thinks of security as a commodity to be
bolted on. Those in the field know that this is never the case, but
they'll have a hard time convincing my mom to re-type what she sees in a
box each time she clicks on a hyperlink. There *must* be a better way.
A few such ways come to mind:
It's rather trivial to determine programatically that www.paypal.com is
different from www.paypa1.com, but look similar. One might argue to rest
the burden with DNS registries (why would anyone legitimately want
paypa1.com?), but that's not likely to fly. Could it rest within the
browser? ("Hey buddy, you're going to paypa1.com--did you mean Pay Pal?"
or "Enable Unicode in URLs"). Perhaps with an addon ("Hey buddy, you're
going to a restricted domain-- are you sure?"). Finally, it could rest
with the operating system (via a variety of mechanisms).
The danger of 'O' vs '0' isn't trivial, but it is much less dangerous
than ASCII 'a' vs Unicode 'a', where the two don't map to the same
Unicode value. At the most basic level, there's the trust that when I
see a picture of 'a', then that means, the first letter of the alphabet,
etc. It shouldn't mean, a modified Greek font representation of a
chinese glyph, or whatever. Perhaps this should rest with the font
designers. Perhaps the default fonts that come preloaded (Arial, Times,
Verdana, etc) shouldn't have multiple characters to map to the same
glyph? After all, I'm not going to paypal.com, I'm going to p<some
unicode character>ypal.com. Why should that look just like paypal.com to
me?
<plug>
I've released a "fix" for the IDN vulnerability
(www.scovettalabs.com/advisory/SCL-2005.002.txt) that basically prevents
you from going to *any* domain that has a non-[\-A-Z0-9] character in
it. For me, it's fine, since I'll likely never need to go to an IDN
domain.
</plug>
Michael Scovetta
Computer Associates
Senior Application Developer
-----Original Message-----
From: Michael Roitzsch [mailto:amalthea@xxxxxxxxxx]
Sent: Monday, March 07, 2005 12:26 PM
To: bugtraq@xxxxxxxxxxxxxxxxx
Subject: thoughts and a possible solution on homograph attacks
Hi security community,
this is my first publication I post on Bugtraq, so please be patient
with me.
Since the recent problems with IDN, I wanted to clear up my thoughts on
homograph attacks, so I sorted everything in an article which also
contains
what I believe to be an easy and general solution.
You can find it here:
http://www.amalthea.de/publications/homograph.pdf
Unfortunately, my free time is currently limited, so I may not be able
to
participate too much in any discussions on the subject. My appologies
for
that. But I will definitely read any feedback I receive.
Michael Roitzsch
