in General 994 Words

Identicon-based Anti-Phishing Protection

I have come up with a couple of new, simple yet very effective, anti-phishing protection schemes using Identicon. One of them requires client-side support so I am interested in talking to browser vendors to build it into browsers ASAP.
It's main features are:
* dead simple user experience

* no certification infrastructure or black/whitelists used

* protection against DNS-based MITM attacks

* protection against keyloggers
Too good to be true? Well, I was surprised too when the idea hit me like a bullet. It's one of those obvious ideas that hides in the logical blindspots we all share. In a roundabout way, it's related to my idea of using DRM to protect one-time passwords but very different once it hatched.
Anyway, if you are a browser vendor, contact me.
Update:
Heck, I am just going to share the idea with the world because I want to see it implemented before yesterday.  

    <h4>Gemini </h4>
            The idea, which I am calling Gemini  for reasons explained below, is to: <em>Use the User&apos;s Password to Authenticate the Server.</em>
         A user&apos;s password is a shared secret which only the user and the server knows. So the server can use it to authenticate itself to the user, by sending a derivative of the password to the user. For example, if the server sent something like <strong>SHA1(password + host_ip + time)</strong> to the client where time is truncated to account for clock difference and the client did the same, two values must match if the server is authentic. <em>The crazy idea of sending the password to the user was the logical blindspot I mentioned. I walked into this idea when I started with the idea of broadcasting passwords. Yes, I am indeed crazy. LOL.</em>  
         The idea is called Gemini because, instead of comparing digested values, identicon images created from digested values are compared visually side-by-side by the user. If the identicons, one from the server and another rendered by the client, are placed either inside or near the password input box, users can easily compare the two before typing the password in. If the two identicons don&apos;t match, then either the server is a phishing site or there is a MITM (proxy will have the same effect).<br><br>Gemini identicons won&apos;t match if there is an intermediary, like a MITM or proxy, between the client and the server because host&apos;s IP address is used to build the identicon. DNS-tricks don&apos;t work because the MITM don&apos;t know the password.<br><br>The overriding assumption here is that the client is managing the passwords, each associated with a host name so the correct password can be selected and used to render the client version of the identicode. Since all popular browsers of today have this capability built-in, all they are missing is the Gemini functionality. For protection against keyloggers, I would add one-click keystroke-less password submission as well.<br><br>Gemini does change the user experience because, in order for the server to build its identicon, it needs the user&apos;s name. If Bank of America&apos;s SiteKey deployment is of any indication, this is not a significant issue.<br><br>Another gotcha is that browser&apos;s identicon has to be authenticated to the user. This can be done by rendering a randomly selected desktop-specific frame around the identicons being compared, like some of those exotic chinese seals have unique looking borders. Simple square or a circle drawn with unique line/gap pattern and color will look great I think.
   Although I was part of the team that built the technology behind SiteKey and feel that it is one of the best anti-phishing solutions out there, I frankly think Gemini is the superior solution. But if any of you see any holes or issues with Gemini, I would appreciate hearing about it. After all, I could be a butterfly hallucinating.
 
<hr>
<strong>Butterfly</strong>
 Speaking of hallucinating butterfly, the reverse of Gemini is interesting too although it appears to be only a slight variation of the usual hashed password method. The only difference is that client&apos;s IP is thrown in to stop the MITM. 
If it is the client that sends the user name and <strong>SHA1(password + client_ip + time)</strong> to the server then the server can check (using the same algorithm) to authenticate the user. This reduces the need for login UI to a single OK/Cancel box and both the phisite site and the MITM can&apos;t do much with the hashed password it captures because:
1. reversing hashed password into password is impractical.
2. hashed password can&apos;t be used because client IP address would differ.
3. replay becomes irrelevant. 
One weakness I can see is the client-based malware somehow getting at the passwords stored on the client, but that can be addressed if the OS uses proper access control.
                        Thinking more about this, this scheme can be reduced to using following three factors:
1. Something the user knows or has: password
2. Something the user uses to access: IP
3. Something no one has control over: time
Re phishing, note that there is no need to authenticate the server to the user in this Butterfly scheme. Although a phishing site can theoretically emulate a website&apos;s secured area to capture sensitive information at some later point, displaying information only the true site posseses can be used to implicitly authenticate the server. 
               <hr>