The token client uses port 80. Because we use asymmetric encryption, there is no need for SSL. If you are behind a proxy, your token client won't connect to the WiKID server. Proxy support is coming in version 3.0. The WiKIDAdmin web interface uses port 443.

Network clients use a variety of ports. Radius is typically 1812, LDAP 389, wAuth is 8388 and TACACS+ is 49. To see if the listener is running on the WiKID server, enter the following command at the WiKID server terminal:

# netstat -anp | grep 8388

Just change the port to the service you are looking to check. The output for wAuth looks like this:

netstat -anp | grep 8388
tcp        0      0 0.0.0.0:8388            0.0.0.0:*               LISTEN      11955/java          
tcp        0      0 127.0.0.1:8388          127.0.0.1:34817         ESTABLISHED 11955/java          
tcp        0      0 127.0.0.1:8388          127.0.0.1:34826         ESTABLISHED 11955/java          
tcp        0      0 127.0.0.1:34826         127.0.0.1:8388          ESTABLISHED 12044/java          
tcp        0      0 127.0.0.1:34817         127.0.0.1:8388          ESTABLISHED 12066/java    

We suggest you use USB tokens or wireless tokens.

Yes, you can.  On the WiKIDAdmin interface, go to Configuration > Set Parameters > Create a New Parameter.  Call it "reEnableHours" and set the number of hours you would like.  Disabled users will automatically be re-enabled after that time.  Be careful though, you do not want to automatically re-enable two-factor authentication for a user that has been disabled for a valid reason.

To help with troubleshooting and to demonstrate wAuth, we have included example.jsp in /opt/WiKID/tomcat/webapps/WiKIDAdmin/. If you edit line 47 and change defaultservercode to your server code and line 52 changing the localhost "passphrase" to your passphrase, you can browse to the page logged in as WiKIDAdmin.

Look for this line:

wc = new wClient("127.0.0.1", 8388, Config.getValue("BASEPATH") + "private/localhost.p12", "passphrase",
        Config.getValue("BASEPATH") + "private/CACertStore", "changeit");

And change "passphrase" to the passphrase for your localhost certificate.

NB: The passphrase for CACertStore on line 53 is, misleadingly, "changeit". However, it does not need to be changed.  Also, line numbers may change slightly.

If you get a tomcat error, check the passphrase you entered. If you still get an error, check that your clock is accurate. If your clock is not accurate, you may have created certificates that are no longer valid. You can delete them in /opt/WiKID/private. Just don't delete WiKID.cer.

This page demonstrates how easy it is to configure a JSP-based web-application for two-factor authentication with WiKID using wAuth. Each wAuth network client includes an example file.

If you get the error "The wClient connection to the server was NOT successfully established." Please double-check your passphrase. You might also make sure your certificates are valid.

Most Linux services use PAM, so 'Yes'. Just configure /etc/pam.d/login to use Radius and you should be good to go.

Run the following command (all on one line):

keytool -list -v -keystore /opt/WiKID/private/intCAKeys.p12 -storetype pkcs12 -storepass yourpassphrase

and

keytool -list -v -keystore /opt/WiKID/private/localhost.p12 -storetype pkcs12 -storepass yourpassphrase

for the localhost certificate.

If you created the certificates and then discovered that the clock was not correct, your certificates might be expired. You can simply re-create them via the WiKIDAdmin.

To see if the WiKID server's firewall is allowing connections from your network client (VPN or web application, e.g.), you can run this command using grep to limit the request to a specific protocol:

iptables -L | grep radius


ACCEPT     udp  --  localhost.localdomain  anywhere            state NEW udp dpt:radius 
ACCEPT     tcp  --  localhost.localdomain  anywhere            state NEW tcp dpt:radius 



But instead of localhost you will see your IP address.

 

Yes. That is why we asymmetrically encrypt all the transmissions. Each communication between the device and server is atomic as well, increasing security.

If you are able to connect to the server using some clients but not all, you can troubleshoot issues by running the token in debug mode.

• Download this file to the token directory: http://www.wikidsystems.com/webdemo/tokens/j2se/jw.properties
  
• Edit the file setting debug=true
• Run the token from the command line:  java -jar wikidtoken.jar (or perhaps wikidtoken-x.x.x.jar)

Here's what the file looks like:

domainSuffix=wikidsystems.net
useIpBeforeDns=true
debug=true

You can also find it and copy it on your computer.  The domainSuffix is used to change the default DNS.  The default is to use wikidsystems.net. UsIpBeforeDns tells the token to check to see if the domain is a zero-padded ip address before checking for a dns entry.  Debug=true turns on debug mode. 

Now, run the software token client from the command line:

$ java -jar jWiKID.jar

This is what the output from the software token should look like for adding a new domain:

devPub.length: 
162
Sending 178 bytes of post data from pullConfig
wComms.connectInternal(): connecting to http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
Opening http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
wComms.connectInternal(): connecting to http://333344445555.wikidsystems.net/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
Opening http://333344445555.wikidsystems.net/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1
POST /wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=0&S=333344445555&CT=1 HTTP/1.1
Wrote 178 bytes.
Reading response iteratively ...
Returning data ... (296 bytes)
Read 296 bytes from the server
Reading 128 of ciphertext.
Reading 160 of server pub key data.
Recieved and Parsed Domain Configuration
serverCode:333344445555
name:Token client test
minPIN:4
PINLifetime:60
deviceID:-767379240169441339
registeredURL:https%3a%2f%2fwww.wikidsystems.com%2fsignup%2ftestclient.jsp
pubKey:[B@c272bc

The token first tries http://333.344.445.555, which doesn't exist, so it then tries http://333344445555.wikidsystems.net, which succeeds. The token gets the domain configuration information such as the registered URL and minium PIN and the user is asked to set their PIN.

Making connection to server.
wComms.connectInternal(): connecting to http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
Opening http://333.344.445.555/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
wComms.connectInternal(): connecting to http://333344445555.wikidsystems.net/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
Opening http://333344445555.wikidsystems.net/wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1
POST /wikid/servlet/com.wikidsystems.server.InitDevice4AES?a=1&D=-767379240169441339&S=333344445555&CT=1 HTTP/1.1
Wrote 128 bytes.
Reading response iteratively ...
Returning data ... (272 bytes)
Recieved 256 bytes from server.
regcode length: 19
public key length: 160
Offline key size: 160

The PIN is encrypted and sent to the server. The server responds with the registration code, which is a 19 digit number. The number is hashed by the server's public key (to prevent a MITM attack during this process) and presented to the user as an 8 digit alphanumeric.

 

If you see an issue during this process, think about where it is occurring? Can the token write the WiKIDToken.wkd file (which has the public/private keys and domain information) to the file system? Can the token reach the server at http://333.344.445.555 or a DNS entry such as http://333344445555.wikidsystems.net? Does the DNS resolve? Do you see an attempt to connect to the WiKID Server in the WiKIDAdmin logs?

No. Only one passcode can be valid at one time. Most time-synchronous token solutions allow more than one passcode to be valid at one time so that the login window is long enough or to account for clock drift. With only a 6 digit passcode, this can reduce security.

If you would like to  see how big the database is before cleaning up run:

# su - postgres  
-bash-3.2$  psql -d wikid 
wikid=# select pg_size_pretty(pg_database_size('wikid')) As fulldbsize;

That will tell you the size.

In the WiKIDAdmin, go to the Logs link in the top right corner.  Click on the button on the right that says "Archive Logs".  Select Zip to save or delete the logs and click the archive button.

Now on the terminal run:

# su - postgres
-bash-3.2$ vacuumdb -afvz

You can re-run the commands above to see the improvement. Note the if you are running in replication, then you need to a '-p 5434' to  the postgres user commands.

 

Yes and Yes.

Online Banking Solutions has already done this.  Additionally, the network clients can be used to create custom application with segmented authorization just for their users.  Please contact us if you would like more information. 

If you can't login to the WiKIDAdmin site due to a bad username and password, there is probably an issue with database connectivity. Check that postgres is running on the proper port:

netstat -anp | grep 5432

Check that 127.0.0.1 is the first item in /etc/hosts and not the IPv6 ::1 listing. (Though this seems to be less of an issue with 3.0)

Make sure that postgresql-jdbc is installed.

Disable SELinux.

Check that the pg_hba.conf file copied properly:

diff /opt/WiKID/conf/templates/pg_hba.conf and /var/lib/pgsql/data/pg_hba.conf

If you get any response to this commmand, it may be that you didn't run this command:

/opt/WiKID/sbin/wikidserver_config.sh

Or that you did not reboot or run this command:

/opt/WiKID/conf/templates/wikid-firstboot.sh

Yes. Unlike most two-factor authentication systems, WiKID uses public key crypotgraphy instead of shared secrets. This means that a single WiKID token can support an unlimited number of relationships with WiKID servers without a reduction in security.

You have installed the WiKID two-factor software token on your Blackberry and you are connected on your mobile network, but when you try to add a domain, you get a message saying you are offline and need to be online to create a WiKID Domain.

Try rebooting the Blackberry, check your firewall settings and make sure that you can access the internet via the browser.

No, we don't have any hardware-based tokens. Our software tokens communicate with the WiKID Strong Authentication server over the internet, so they require an internet connection of some kind - at least for the initial validation process.

The software token can be run on USB drive - and that drive can, of course, be encrypted.

 

General FAQ about the WiKID Server.

You've logged in with the correct username and password for the WiKIDAdmin web interface, but you get a 404 error from Tomcat:

HTTP Status 404 - /WiKIDAdmin/login.jsp

type Status report

message /WiKIDAdmin/login.jsp

description The requested resource (/WiKIDAdmin/login.jsp) is not available.

This happens occasionally if your browser has cached the session. In the URL bar, remove the login.jsp file name so the URL is just https://wikidservername/WiKIDAdmin/ and hit enter. The WiKIDAdmin page should come up.

Yes.  Please go to the Downloads page.

 

If you get this error:

Error: There is a problem with your certificate request
java.io.IOException: exception encrypting data - java.security.InvalidKeyException: Illegal key size

Please go back and try again

You need to install the JCE Unlimited Strength Jurisdiction Policy Files.

You will also need to delete the intCAKeys.p12 in /opt/WiKID/private:

# rm /opt/WiKID/private/intCAKeys.p12

Then restart WiKID. 

A big problem with hardware-based tokens and traditional soft-tokens is the need to get the token or data file to the end user securely and to associate it with the user on the server. Typically, there is a big box of tokens in a secure location, the security administrator grabs a token, enters the serial number into the user’s account on the server, and overnights the token to the user. The next day, he overnights a new PIN number for use with that token. Obviously, this process is an expensive waste of time for a highly paid security professional. WiKID Systems’ elegant architecture allows for a fully automated initial validation when our system is combined with a trusted network or existing trusted relationship.

First, the end-user installs the client on the device (over-the-air download or via the Internet installer) and logs into a web site, over a trusted LAN or using an existing hardware token or some other trusted mechanism. The web site provides the user with a 12-digit code that represents the IP address of the authentication server. The user selects ‘New Domain” to create a new trust relationship and enters the 12-digit number.

The WiKID client generates its own public/private key pair and sends a request to the server along with it’s public key. The server responds with a configuration file and its public key, encrypted with the client’s public key. Already, we have asymmetric encryption! The user enters his chosen PIN, which is stored on the server and the server responds with a registration code. The user enters the registration code into the web site and he is finished. If the administrator allows automated initial validation, the user can start generating valid passcodes and can throw away their token (or, more likely, they can return it for recycling to a non-WiKID user). An administrator can easily add a user manually as well.

Simple, really.

There are two factors: possession of the private key and knowledge of the PIN. The private key is stored on the client. Our PC client, for example, this key is in a password-protected PKS12 encrypted file. If someone steals this file and brute-force attacks it and gets the passcode, they are only half-way there.

They still need the PIN. The PIN is stored encrypted on the WiKID server. Losing the private key is the equivalent of losing a hardware token. You're only half-way there.

Typical software tokens store the PIN, the secret and the algorythm all in the client. Clearly this is not the way to do it.

If you are using IE, you may need to add your WiKID server into the list of trusted sites. Go to Tools --> Internet options --> Security --> Trust sites and add your WiKID server.

If you can telnet to port 443 on your WiKID server (ping is blocked by the WiKID server firewall) and if you run 'netstat -anp | grep 443' on the WiKID server to see that the listener is up and the URL shows but there is no error or any content at all on the web page, then your browser probably doesn't like the WiKIDAdmin certificate.

Typically, this means that for some reason, the java.security files in the WiKID packages did not get copied to your java location. 

Run:

# locate java.security

You will see one in /opt/WiKID/conf/templates/java.security and one or more in your java directories.  Copy the one from the WiKID directory to the one in your working java directory.   BouncyCastle needs to be set as the second provider as in the WiKID copy:

security.provider.1=sun.security.provider.Sun
security.provider.6=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider

 

If you are running a WiKID server with a few thousand users or if you want to keep your logs on debug for some reason, then archiving your logs is a good idea. And automation is always a good idea. Here's how to do it:

Download the LogExporter.jar.

On the command line run 'java -jar LogExporter.jar 2 hours' to archive all but the last two hours of logging. The usage is <value> <period> where period can be one of minutes|hours|days|weeks|months|years.

Set up a chron job to do this as frequently as you like.

Yes.

First edit the file /etc/WiKID/security and add a line that says: WAUTH_PASSPHRASE="your_passphrase_to_start_the_server".

Then:

 

This problem is typically a networking problem.  Double-check that you can get out to the Internet from the server.  Check that your gateway setting is correct. If there is a firewall between the WiKID server and the Internet, make sure it is not blocking out-bound port 80 traffic.

For example, on a SonicWall you may need to uncheck the box that says: Enforce Host Tag Search for CFS and hit apply.

 

 

 

If you are using the ISO or the VMWare image and you are having trouble starting the server because the passphrase is bad, it might be because the keyboard for the terminal is set to the US. The passphrase is created in the browser, which is more than likely set to your local key map. If when you enter that passphrase into the terminal, you get an error, it is probably the keyboard mapping - especially if you are using non-alphanumeric characters.

To change the keyboard mapping on the terminal, run the loadkeys command with the appropriate keyboard map as the only argument:

# loadkeys uk.map.gz

To see the complete list of keymaps run:

# ls /lib/kbd/keymaps/i386/qwerty

The server can be started without a passphrase by creating a file called /etc/WiKID/security and entering "WAUTH_PASSPHRASE=passphrase" on the first line. This allows a restart without manual intervention.  If your passphrase has spaces, put it in single quotes:  "WAUTH_PASSPHRASE='pass phrase'

In addition, we have added a script you can use to create a linux service in /opt/WiKID/cont/templates called wikid.

Are you behind a proxy? Proxy support is available on the J2SE tokens.  Under Actions, Set Preferences you can enter your proxy information.  Please contact your network administrator for your proxy information if you don't know it.

Simply download the latest WiKID ISO and burn it to a disc.  Mount it on your machine and run:

# yum localupdate --nogpgcheck /yourCDdrive/Centos/*.rpm

 

 

Mutual HTTPS Authentication can add a lot of security to your two-factor authentication setup by thwarting most network-based MiTM attacks.  Here are somethings to consider:

• You must decide to implement mutual https authentication before rolling out tokens to your users.
• It is only used for SSL-based websites and SSL-VPNs where the browser is used.
• When you add an https url in the Registered URL box on the domain configuration page, the server grabs the cert, hashes is and stores it.  Any token registered AFTER this will fetch the cert over the user's connection, hash it and compare it to the hash delivered with the OTP.  If they don't match, an error is thrown. If they do, the OTP is presented and the browser is launched to the Registered URL.
• If you change the URL on the domain page, you have to re-register all the tokens!
• If a user is getting an error, there is a possibility of a MiTM attack.

First, check the logs in the WiKIDAdmin. The link is in the upper right hand corner. When the one-time passcode is sent to the token client, the log reads "Passcode Request Successful (128)". After that, you should see entries on your two-factor authentication attempt. If you don't see any, then the WiKID server is not getting the request from the network client to authenticate the user.  

• Make sure that the network client has the correct IP address of the WiKID server and that it can route to it.
• Set the log level to debug to see more information. 
  
• Make sure that the shared-secrets are correct, if you're using radius.
• Did you run 'wikidctl restart' on the server after creating the network client? If not, the firewall on the WiKID server might be blocking the authentications.
• Does your setup work without WiKID? 
  
• Have you tested WiKID using the example.jsp page?
  

 

A password-reset domain is configured on the server with Administrator rights to reset users' passwords. When a user forgets their password, they choose the password reset domain on the WiKID client and enter their PIN. If PIN is correct, the encryption valid and the WiKID account is active, the WiKID server resets the Active Directory password to the one-time passcode and forces the user to change their password at the next login.

NB:  This feature is currently disabled, but can be re-enabled.  Just ask.

You will need to re-generate an intermediate CA. You will need to do this on the command line of the WiKID server. Log in as root and change to the cert directory:

cd /opt/WiKID/private

The directory will look something like this:

# ls -all
-rw-r--r--   1 root root 2718 Jul  6  2006 CACertStore
-rw-r--r--   1 root root 2237 Jun 21  2007 extranet.p12
-rw-r--r--   1 root root 2984 Jul  6  2006 intCAKeys.p12
-rw-r--r--   1 root root 2271 Jul  6  2006 localhost.p12
-rw-r--r--   1 root root  387 Oct 16 15:09 tacacs.conf
-rw-r--r--   1 root root 1752 Mar 19  2006 WiKIDCA.cer

You will need to remove or move CACertStore and the .p12 files.

# rm CACertStore

and:

rm *.p12

The localhost cert and any wAuth p12 files will also need to be recreated and redeployed if necessary. You should not have to recreate any network clients that use radius, ldap or tacacs+

The WiKIDToken.wkd file includes the domain information and the public/private key pairs for the software token. If you delete this file, it will be re-generated by the application with new keys, so you will need to delete the user in WiKIDAdmin and re-validate the user.

WiKID works with Active Directory in two ways: initial validation of users and in the authentication process. Both are optional.

If you use Active Directory, you can use the the built in scripts on the WiKID Strong Authentication Server for self-service token validation to add your Active Directory users to WiKID. Feel free to change these scripts as needed.

Second if you want to check that your users are valid in Active Directory as well as in WiKID, you can use the Microsoft Radius server NPS (which is free).  It can be configured to check that a user is valid in AD and then proxy the username and one-time password to WiKID for validation. In this way, deleting a user in AD is all you should need to do when de-provisioning. More information on configuring NPS with two-factor authentication from WiKID can be found here in our  eGuide to adding two-factor authentication to your network.

 

When first integrating WiKID and your VPN using radius, it can be difficult to troubleshoot without detailed logging.

Remember: you must restart the WiKID service after creating a new network client! This opens the firewall and caches the radius information. 

NB:  There may be a bug in the system currently. The stop command fails to fully stop the radius server.  Use this instead:

wikidctl stop
killall -9 java
wikidctl start

If you need to better understand how the flow and architecture works, please see our short pdf on adding two-factor authentication to your network.

Is the server getting the request?

Start by getting an OTP from your WiKID token. We assume you have register your username to that token.   Login with your username and the OTP.  Once you get your OTP, check the WiKIDAdmin logs. Set the log level to debug and hit Filter.  You will see:

Now, enter the username and OTP and try to login.    Return to the WiKIDAdmin logs and hit Filter to refresh.  If you see nothing above your OTP issuance, then the server is most likely not getting the RADIUS request at all.  Check your VPN or radius server settings.  If you are using NPS, check Event Viewer or whatever you use for Windows logging.

Unknown NAS Error

Radius will reject packets from unknown IPs.   This error looks like:

In this instance, the IP 192.168.56.1 is not the same IP as the one used in the Network Clients on the WiKID server.  Update the IP and restart the WiKID service.

Using TCPDump

TCPDump can also provide valuable troubleshooting information. 

yum install tcpdump

tcpdump -vvv port radius

Now you can see what requests, if any, are coming to your WiKID server.  Check to make sure that they are coming from the same IP address as listed in the Network Client's tab.  Make sure that the NAS IP that is requesting the authentication is exactly the same as entered in the Network Client.  Hit ctrl-C to cancel tcpdump.

 Run 'iptables -L -n' on the server - make sure the IP address of the NAS IP is listed too.  WiKID should open up ports for network clients.

Very. We have tested the WiKID server running on a low-end 1.4 ghz server with 256 meg of ram and IDE drive and have documented 50 transactions per second. The WiKID Server is a software appliance available as an ISO or a VMWare image that you put on your hardware platform of choice, so the scalability will depend on the hardware you choose.

If you are running the PC token, simply type in  a wrong passphrase 5 times and you will be prompted to delete the token.  Various smartphone tokens may require re-installing.

The lifetime of an unregistered token is set for 60 minutes by default. This value can be set to a longer time by going to Configuration > Set Parameters > RegCodeTTL, and changing 60 to whatever you feel is appropriate.

This error indicates that the software token client cannot get to the WiKID Strong Authentication server. The software token client communicates with the server over port 80. Check to see if you can reach the IP address of the server/WiKID domain using telnet or traceroute. It could also be that the domain is mis-configured. If no client can create a domain, then it is probably the networking on the WiKID Strong Authentication server or perhaps the zero-padded domain identifier is incorrect.   Be sure to enter your proxy information under Actions, Set Parameters if you are behind a proxy.

You can also download the jw.properties file from the src directory and edit it to set debug to true.  Then if you run WiKID from the command line with "java -jar jWiKID.jar" you may see helpful information on the command line.

Or "I need to reset my token passphrase. How do I do it?"

No. Sorry. For security reasons, that is not possible. You will need to delete the WiKIDToken.wkd file and restart the WiKID token. All the domains will need to be re-configured.

Since most of the security is really on the WiKID server, the WiKID Two-factor Client itself is fairly simple and we are able to support a broad number of device types. We have java software tokens  Windows, Mac and Linux and tokens for Windows Mobile, iPhone/iPad, Android, and Blackberry.

A WiKID Strong Authentication Server is capable of managing multiple domains. A domain segregates users with respect to access and security. For example, remote office users would be associated with a VPN domain that granted access through a Cisco ASA service. Remote access to the Cisco ASA itself could be granted to administrators using a separate domain. Each domain can have different security elements such as PIN length, passcode lifetime, maximum bad PIN attempts, etc.

The WiKID client is capable of working with domains across multiple authentication servers, even from different enterprises, with no reduction in security. Thus WiKID is ideally suited for the Internet age.

The WiKID System falls back to a challenge-response mechanism, which is part of the Radius standard. After the user enters their PIN, if the device is out of wireless network coverage, the WiKID Two-factor Client will prompt the user for a Challenge.

If the user is logging in to a VPN service, for example, the user enters their username, but leaves the passcode box empty. The VPN service responds with the Challenge, which the user enters into the WiKID client.

The challenge is encrypted with the user’s PIN and an offline-challenge secret and presented to the user Base-62 encoded (to keep the length manageable). The user enters this response for a passcode. The VPN service sends the Username, the Challenge and the Response to the WiKID server. If the WiKID Server can decrypt the Response can get the Challenge, the user is granted access.

WiKID Strong Authentication consists of two main elements, the WiKID Strong Authentication Server  and the WiKID Two-factor Client for user devices. The WiKID Strong Authentication Server interfaces with various Network Clients, such as firewalls, VPN services, Citrix, directories or applications via Protocol Modules, such as RADIUS, LDAP, SMB or the WiKID Authentication Protocol, an SSL-encapsulated API for web-enabled application integration.

When a user wants to login,say to a VPN service, they enter a PIN into the WiKID Software token client, it is encrypted by the public key of the WiKID server and sent to the server. If the encryption is valid, the PIN is correct and the account is active, the server returns the one-time passcode encrypted by the Client's public key. The user then enter their username and one-time passcode into the VPN client. The VPN service forwards the credentials to the WiKID server via a protocol such as Radius for validation.

Radius (Enterprise version only), LDAP, TACACS+, and support for Google Apps for your Domain through SAML.  We also have an API you can use to add two-factor authentication to  custom apps.  They are LGPL-licensed and available for download.  

The Enterprise version contains some proprietary software licensed from 3rd parties that we cannot release under the GPL. Additionally, the automated update system is part of the paid support package not needed with the Community release.

The main difference in the Enterprise version is the use of the Ntru encryption libraries for use in the wireless/smart phone clients. We believe that the private/public key pairs need to be generated on the device. The key gen times for open source RSA and ECC algorithms were unbearable. RSA key gen on a J2ME phone was estimated to be 14 days and ECC was 14 hours! For Ntru, the key gen time is closer to 4 seconds.

The Enterprise server also includes a built-in radius server which we licensed. The main attraction was that it is written in java.

Finally, the Enterprise version is an ISO/Virtual Appliance that requires no knowledge of Linux and is offers a very simple installation procedure. If you're interested in testing the Enterprise, we offer a 30 day evaluation license. You can quickly test the ISO software appliance on your virtual server platform of choice.

If you want support, if you want one of the wireless software tokens clients, or if you want RADIUS support, you should get the Enterprise version. In general, for enterprise deployments, we recommend the Enterprise version.  Or, if you like the project and just want to support us, buy the Enterprise version.

Also, if you would like to embed WiKID support into a proprietary software package, you should contact us about an appropriate license.

We want people to use our software.

We benefit from feedback from users whether they pay or not.

We want to partner, not just with proprietary software developers, but also open source projects and other 'dual source' companies.

We hope that evaluators will actually look at the code for weaknesses and help us make the product better. It ain't fixed until you've broken it.

We use open source software everyday and wanted to give something back.

Yes. It can run on any USB drive and because we use asymmetric keys and the key pairs will be generated on the USB drive, the distribution of tokens is much easier. Any user can get any fresh USB drive and use it.

The short answer is 'yes'. Chances are that your network devices, whether they are Cisco switches or Nortel VPN concentrators, a custom web-application or a home-baked Linux firewalls, WiKID will work out of the box. Additionally, we can add network protocols with relative ease, if you're not covered by Radius, LDAP or the other major protocols. Finally, we offer a simple API and implementations in a number of languages - Java, COM, Python, PHP and Ruby - so you can easily add two-factor authentication to your custom applications.

Note that you can install openjdk 8:

yum install java-1.8.0-openjdk

However, our earlier ISO is based on Centos 5 and it's not available for that version so installing the Oracle JDK is an option. You can go to the Oracle website and download it or you can use the commands below.

Note that these commands are for jdk-8u51. Check to see of there's a newer version and use that file name instead.

If you are on our pre-4.0.1-b1903 ISO or 32 bit linux use this:

curl -v -j -k -L -H "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u51-b16/jdk-8u51-linux-i586.rpm > jdk-8u51-linux-i586.rpm

For 64 bit:

curl -v -j -k -L -H "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u51-b16/jdk-8u51-linux-x64.rpm > jdk-8u51-linux-x64.rpm

Install the rpm:

rpm -ivh  jdk-8u51-linux-i586.rpm

At this point you should upgrade your WiKID rpms. (There's a bug in release 4.0.3-b1903 that over-writes the JCE policy with older ones.)

If you need to upgrade or install WiKID, do so now. (There's a known-issue, our RPM overwrites the JCE Policy file.)

Now, install the JAVA encryption files:

curl -v -j -k -L -H "Cookie:oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jce/8/jce_policy-8.zip  > jce_policy-8.zip 

Unzip them:

unzip jce_policy-8.zip

And copy them to the correct directory:

cp UnlimitedJCEPolicyJDK8/* /usr/java/jdk1.8.0_51/jre/lib/security/

Run

java -version

and make sure it says 8. If not run:

alternatives --config java

And select 8.