Various guides for Linux, WiKID and information security.
Frequently Asked Questions about the WiKID Strong Authentication Server.
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 8388Just 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
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 radiusACCEPT 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@c272bcThe 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: 160The 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.
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: 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:
If you get any response to this commmand, it may be that you didn't run this command: Or that you did not reboot or run this command:
netstat -anp | grep 5432
diff /opt/WiKID/conf/templates/pg_hba.conf and /var/lib/pgsql/data/pg_hba.conf
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:
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.
Check that the pg_hba.conf file copied properly:
If you get any response to this commmand, it may be that you didn't run this command:
Or that you did not reboot or run this command:
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.
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
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:
You need to install the You will also need to delete the intCAKeys.p12 in /opt/WiKID/private:
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
If you get this error:
You need to install the.
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.
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.
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.
# 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.
First edit the file /etc/WiKID/security and add a line that says: WAUTH_PASSPHRASE="your_passphrase_to_start_the_server".
# chmod +x /etc/init.d/wikid
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:
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
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+
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:
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 into 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:
killall -9 java
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.
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, , 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
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 Also, if you would like to embed WiKID support into a proprietary software package, you should
If you want support, if you want one of, 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.
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
And copy them to the correct directory:
cp UnlimitedJCEPolicyJDK8/* /usr/java/jdk1.8.0_51/jre/lib/security/
and make sure it says 8. If not run:
alternatives --config java
And select 8.