Prevent Phishing with Mutual Authentication

Phishing is essentially a man-in-the-middle attack. The user is mis-directed, for example by social engineering or DNS-cache poisoning, to a fraudulent site. Because the user doesn't understand how to validate SSL certificates (and who does?), the trick works far too often. Efforts such as Extended Validation certificates are bound to fail in many cases because they rely on inconsistent visual aids and not strong cryptography. One-time passwords alone have also proven to be vulnerable to real-time MITM attacks. To prevent phishing consistently requires strong mutual authentication - validating the host to the user and the user to the host.

In this document, we will configure a JSP application to work with WiKID's open-source one-time password and mutual authentication system. Here's how it will work: when a user wants to login to the target site, they start the WiKID token client and enter their PIN. The PIN is encrypted by the server's public key and sent to the server. If the PIN is correct, the encryption valid and the account active, a package of the OTP, the target site URL and a hash of the target site's SSL certificate are sent to the token client. The token client goes out over the user's internet connection to the target site URL and gets the SSL certificate, hashes it and compares it to the validated certificate hash. If the two hashes match, the token client presents the OTP and (on supported platforms) launches the default browser to the site for the user.

First, we will add a domain on the WiKID server for the application, then we will create a network client for JSP page. We will add the login code for WiKID to the JSP page, then we'll test it from a token client.

Adding a domain to the WiKID server

This is fairly easy. From the WiKID server web administration interface, click on the the Domains tab and Create New Domain. Enter a domain name for the gateway and a device name. The device name will show up on the WiKID token. In the Registered URL box put the URL of the JSP page for the target server. When the domain is created, the WiKID server will fetch the certificate from the webserver, so make sure that you enter 'https:'. The server code will be the routable, zero-padded IP Address of the WiKID server (e.g. = 010001001001). Set the other parameters as you see fit. While a longer PIN may increase security mathematically, a four digit PIN may be better: if a user uses their ATM PIN, they are more likely to protect it.

Create Mutual Authentication domain

Create a network client

After saving the domain information, click on the Network Client tab and Create New Network Client. Enter a name for this client and the IP Address of the target server on the internal network. Select wAuth as the protocol and then choose the domain you created above.

Create Mutual Authentication NC

Click Add to get the next page and enter the information for the p12 certificate for the target server. Communications between the JSP server and WiKID server will be encrypted with SSL using this p12 file. Enter a passphrase for this p12 file twice and the passphrase you used for the server's certificate during the configuration process. When you return to the Network Client page, you will see the new network client listed and a link to download the p12 file. Download the p12 file and put on your JSP server in the same directory as your JSP code.

Create Mutual Authentication NC_p12

Configuring your JSP pages

On your JSP server, you need the p12 file created on the WiKID server, the WiKID java network client jar (Wikid.jar) file, which is available on our website or from our Sourceforge site, and your JSP page. Additionally, you need to be running Java version 1.4.2_06 or later. Each network client package includes an example page. Here, we will be editing the example.jsp page. This page also includes code for programmatically adding new users.

Open your JSP page in your favorite editor:

First, import the WiKID client:

<%@ page contentType="text/html; charset=UTF-8" %> 
<%@ page import="com.wikidsystems.client.*" %>

This section instantiates the connection between the network client application and the WiKID server. For this to succeed, the network client must have been issued a certificate from the WiKID server. The certificate is contained withing a PKCS12 certificate store and requires a passphrase to access. The caStore is a Java Keystore that contains the certificates of the WiKID servers you will connect to with this client. You can copy this from WAS as the /opt/WiKID/private/CACertStore. The caStorePass is the passphrase to open the caStore.

When the wClient object is instantiated it will load the cert and establish a persistent authenticated SSL connection. This is normally done once per server or application and shared by multiple threads. In this example the object is created and destroyed each page request. This greatly (1000 times) increases overhead of the process but allows all the functions to be shown in this single example page.

Parameters are:

  • wClient(String host, int port, String keyfile, String pass)
  • host = IP address of WIKID server
  • port = TCP port number to connect to (default 8388)
  • keyfile = Path to the PKCS12 certificate file
  • pass = Passphrase to open the PKCS12 file
  • caStore - The certificate authority store for validating the WAS server certificate, download this from the WiKID server (opt/WiKID/private/CACertStore <-- DO NOT USE Java's cacerts file
  • caStorePass - The passphrase securing the caStore file
<%  String status="";
String chall="";
wClient wc = new wClient("",
Login Online

This function is the normal-state login for users. This is called when the users device is connected to the network and able to directly request a passcode for access.

Parameters are:

  • CheckCredentials(String user, String passcode, String servercode)
  • user = userid to validate credentials
  • passcode = time-bounded, 1 use passcode
  • servercode = 12-digit code created on the WiKID server, in this case 333344445555
This method returns a boolean representing successful or unsuccessful authentication
boolean isValid = false;
if(request.getParameter("action") != null && request.getParameter("action").equalsIgnoreCase("Check Online")){
isValid = wc.CheckCredentials(request.getParameter("user"), request.getParameter("passcode"), request.getParameter("servercode"));
if (isValid){
} else {
status="Authentication Failed";

And here is the HTML for the form:

<!-- Online Login -->
<h2>Online Login:</h2><form action="./example.jsp" method="POST" >
UserID: <input type="text" size="25" name="user" value=""/><br />
Passcode: <input type="text" size="12" name="passcode" value=""/><br />
Domain code: <input type="text" size="16" name="servercode" value="127000000001"/><p></p>
<input type="submit" name="action" value="Check Online"><br />

Testing with the Token Client

If you haven't already, you can download a copy of the WiKID open-source token client. Start the token with '' or 'run.bat' depending on your platform. The first time you launch the token client, you need to create a passphrase. Once started, select Actions and Create New Domain

Mutual Authentication Token - Add domain

Enter the 12 digit domain identifier and the public key will be sent to the WiKID server. You will be prompted for a PIN.

Mutual Authentication Token - Enter PIN

The WiKID server will store the PIN and return a registration code.

Mutual Authentication Token - reg code

At this point, the account has been created on the WiKID server, but it is not active. You can create self-service registration pages for users based on existing trusted credentials or out-of-bounds mechanisms, but in the case, we will manually validate the user on the WiKID server. From the WiKIDAdmin web interface, click on Users and Manually Validate A User. Click on the Registration Code and enter a user name.

Mutual Authentication Token - validate

Now, from the token client, select the domain you created and enter your PIN. You should get the one-time passcode back (and it should be copied into your clipboard) and your browser should launch to the Registered URL.

By combining one-time passcodes for user authentication with built-in validation of the host certificate and automatically launching of the browser, we have created a system that is easy for the user, yet cryptographically sound. The token client is capable of handling multiple domain relationships without a reduction of security thanks to the use of public key cryptography and the server is capable of managing multiple network client relationships. Additional network client examples are available for Ruby, PHP, Python and ASP/COM/.NET. Apache or IIS can be configured using Radius or LDAP as well.

You can test this process (anonymously) at

Share this page:

1 Comment(s)

Add comment


From: Chris

This does not work.  Almost all companies and schools use deep-packet-insepction firewalls; so you will never be able to log in from work or school with this, because the certificates will be wrong (which is a correct operation).

Look at CryptoPhoto - it's 100x faster than this idea, and works everywhere.