I have been reading about IDN homograph attacks, and I cannot think of any better way to deal with them than

  1. Tell my users not to trust emails asking for passwords, etc
  2. Buy all domains similar to mine (expensive and difficult)

Is there really nothing else I can do?

  1. Tell my users not to trust emails asking for passwords, etc

That is a good move. You could reinforce this message by never sending any sort of email containing links. The only difficulty is that many email clients will automatically convert strings that look like web addresses to clickable links. You could reiterate that users should type the address in their browser to access your site and should not click the link.

  1. Buy all domains similar to mine (expensive and difficult)

Is there really nothing else I can do?

The Wikipedia article contains a section on Defending against the attack. These are all browser based. You could encourage users to only use browsers that protect against IDNs. For example, Chrome's approach is:

Google Chrome displays an IDN only if all of its characters belong to one (and only one) of the user's preferred languages.

Two factor authentication can protect against the risk of an attacker successfully phishing a username and password and then using those to log in herself. However, if the user thinks they have successfully authenticated with your site then this does nothing to mitigate the risk of the user divulging further details in their logged in session with the attacker's site. Also, an attacker could get their phishing site to ask for the second factor of authentication and simply enter those into the original site when the user enters those on the phishing site (providing the attacker is phishing in real time rather than checking their server logs at a later time).

Asking for only certain letters from the password is also easily circumvented. Phishing sites usually will just say that the two letters entered were incorrect and then ask for another two until the full password is discovered. Also this means that you cannot save the password hashed, and password managers usually have trouble filling dynamic fields like these.

Another solution to mitigate phishing in general is to encourage the usage of browser based password managers. These check that the URL matches the one stored in the password manager so it will not complete the password if there are any homograph attacks in progress.


My suggestion would be to use two-factor authentication. If you chose not to use two-factor auth I would suggest getting out of the authentication game and using "login in with *" where * is facebook/google/yahoo etc, this moves the burden of preventing fishing attacks to companies that have the money and resources to do it well.

See https://stackoverflow.com/questions/5087005/google-authenticator-available-as-a-public-service for an example of an easy and cheap second factor to use.

As a last resort you can use a two password scheme, also known as password plus secret question. Where the second password you only collect certain letters of the password, and which letters you collect change on each login e.g.:

Username: ......
Password: ......
3rd, 6th and 7th letter of secret word:
          3rd .. 6th .. 7th ..

This will increase the chances of the user noticing a fishing attack before the attacker has found enough information to login as the user.

  • Just be sure to consider usability when considering switching to logging in with a third party service. There are still users out there who don't have Google/Facebook accounts and other users, like me, who don't want to sign in using those accounts.
    – Roy
    Jan 14 '15 at 13:51
  • @SilverlightFox RickyDemer has only 241 rep, not enough to suggest single-character edits.
    – user
    Jan 14 '15 at 13:55
  • In what way would a second factor prevent homograph attacks?
    – Arminius
    Apr 18 '17 at 3:16
  • 1
    @Arminius U2F keys prevent homograph attacks, because the authentication key that they create is unique to the hostname they're sending it to. Most (all?) other second factors do not.
    – Mike Scott
    May 3 '17 at 9:16
  • A very basic, but effective solution is to make people aware never entering credentials without typing the URL themselves: this is what lots of banks do, some even don't put any links at all in their mails.
  • Password managers (also passwords stored in browsers), that automatically fill-in for specific domains, are invulnerable to such attacks; at least they can help protecting against password theft.

    They don't care about how a domain is displayed and whether it looks similar, they look up the actual string in their database.

  • Certificate based login is generally invulnerable to this attack; while a user might be "successfully" logged in to an attacking site, it would not get hold of any credentials and could also not perform a man-in-the-middle attack.

  • 1
    I'd advise against browser stored passwords on anything. You're essentially putting all your eggs in one basket. Not a good idea. This depends on your threat posture and how you view the cost of a breach.
    – munchkin
    Jan 15 '15 at 1:43

Primarily this is a user training issue. The advice I favor is:

Save the URL for the site in your bookmarks. When logging in, open 
the bookmark, then enter your login details.

Another thing you can do is get an Extended Validation (EV) certificate. It is likely that a spoofed domain would not have an EV certificate, which gives a visible difference for users to look for.

One approach for advanced users to is use a browser-integrated password manager that ties credentials to a particular domain. Because the password manager is doing a programmatic compare of domains, it is not vulnerable to spoofing by homograph.


Unfortunately homographic attacks and it's predecessor the fatfinger url attacks are one of those things that is very much dependent on the user. You could push the responsibility towards the domain name registrars, the certificate issuers or the ietf ( what's wrong with ascii :), but you'll need a 2 prong approach to this.

  1. Circulars that warn users against .... i.e. have a coherent policy please
  2. Ways to mitigate the inevitable ....

Depending on your budget outlay, these could become expensive really fast.

The 2FA solution is great since you now have an out of band comms channel to do corroboration, but then you'd have to trust the provider as well. It all boils down to risk management and whether any data loss is a show stopper.


I've just discovered the following plugin for chrome that encodes urls as phunycode at all time to protect against this new form of exploitation. If anyone has time to check the extension for malware that would be nice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.