>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).
While not exactly a solution to homograph attacks, there is an entire class
of man-in-the middle attacks (DNS poisoning, wireless Evil twin, etc) that
make use of look alike domain names as well as just redirecting the IP data
stream to a different server.
Paypal - go to URL bar, type in 'www.paypal.com', put in your username and
password and log in
Bank - go to URL bar, type in 'www.mybank.com', put in your username and
password and log in.
Bank - go to URL bar, type in 'www.mybank.com', click on the SSL login
page, put in your username and password and log in.
BZZZT - wrong! You are vulnerable to a man in the middle attack (except if
you examined the SSL certificate and/or URL prior to login in the 3rd case).
This is particularly important on a laptop if you travel to multiple
locations and wireless access points. A simple rule of thumb for less
techie computer uses is to teach them how to examine SSL certificates for
validity. Then find and bookmark the secure login page. Then if the SSL
certificate name doesn't match the browser's bookmark name, they'll get a
warning popup that the name doesn't match.
The simple rule for everyone: bookmark the secure login page of sites
where you enter your username and password. In the real world, we don't
examine each SSL certificate at every login. ....How do you get to paypal
or your online banking?
