WiKID is a two-factor authentication system. WiKID Strong Authentication System project consists of: a PIN, stored in the user's head; a small, lightweight client that encapsulates the private/public keys; and a server that stores the public keys of the client's and the user's PIN.
When the user wants to login to a service, they start the client and enter their PIN, which is encrypted and sent to the server. If the PIN is correct, the account active and the encryption valid, the user is sent a one-time passcode to use instead of a static password.
You can think of WiKID as 'certificates on steroids'. It is more secure than certificates because the required PIN is only stored on the server, so it is not susceptible to offline passive attacks.
It is easier because user enrollment is automated and you don't have to deal with a full certiticate infrastructure. You can also compare WiKID to hardware tokens: it is much easier to implement, more extensible, yet just as secure. Stealing either the token or the PIN does you no good. You must steal both, just like a hardware token.
The WiKID Strong Authentication System consists of three parts: the WiKID server, the WiKID token client and a network client (such as a VPN, website or other service requesting authentication). The WiKID server is written in Java, as is the open source J2SE PC client. As part of this release, we are also releasing the following under the GPL:
- ASP code for end-user self validation. New users can provision their own WiKID token clients based on trusted LAN credentials, in this case, Active Directory credentials. This code can easily be modified for other types of credentials.
- The WiKID Citrix Web Interface plug-in. If you're using Citrix Web Interface for remote access, now you can add two-factor authentication quickly and easily.
- The wAuth COM object and Java component. Network clients talk to the WiKID server using an SSL encrypted protocol - wAuth. These objects can be used to integrate WiKID into any application. The file example.jsp shows how easily this is done for Java-based web applications. The Citrix Web Interface and the ASP code for end-user validation show how simple this is for ASP applications.
- The J2SE WiKID token client. The token client is responsible for key generation, domain management and one-time password requests. It can run on your PC, a suitable PDA or on a device such as a USB token.
When the user wants to log in, they select the domain they want to log into (yes, WiKID is capable of handling multiple domains with a single client unlike hardware tokens) and enter their PIN. The PIN and a single-use AES symmetric key is encrypted by the client's private key.
The server decrypts the OTP request. If the PIN is correct and the account active, the server generates the OTP and encrypts it with the token client's public key and the single-use AES key. The user gets the OTP and uses it to log in. Whatever service the user is trying to log into passes the OTP and username back to the WiKID server for validation via a network client connection.
If you manage multiple accounts and boxes across multiple entities, WiKID can help you reduce your password overload. One WiKID token can work with multiple WiKID servers, so, if you want to get rid of your static passwords, deploy WiKID in as many places as you can.
WiKID is great for:
· Strong authentication for remote access via a VPN
· Strong Authentication for remote access via Citrix
· Two-factor Authentication for extranet applications
· Locking down internet-exposed intranets
· Secure Online Banking - fight phishing and other attacks
· Lock down SSH and other admin access
· Any place you might have used certificates or token, but couldn't because of cost, hassle, etc.
Here are some key features of "WiKID Strong Authentication System":
· Easy to use Web Interface
· Automated initial validation of users
· Fault tolerance via replication
· Highly scalable - each transaction is 300 bits /-
· Simple user disablement
· Support for a number of network protocols
· No need for time synchronization - Request-response architecture
· Each client can support multiple relationships across multiple servers
· Extensible across enterprises
What's New in This Release: [ read full changelog ]
· Long overdue LDAP fixes were made.
· The default regcode TTL was set to 1 day.