FAQs

Radius and LDAP are the main protocol modules. Novell support is provided through LDAP We also have custom interfaces for Steel Belted Radius and for Citrix Web Interface. We have added the ability to reset a LAN password via Samba too and we provide an SSL-encrypted API and sample scripts so that you can easily use WiKID for web-enabled applications via a COM object or Java Component.

WiKID Strong Authentication consists of two main elements, the WiKID Strong Authentication Server (WAS) and the WiKID Two-factor Client for user devices. The WAS 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 Two-factor 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.

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 a Win32 client for PCs, a J2ME client for cellphones, a Palm client, a PocketPC client and a J2SE client for Mac, Linux etc.

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 PIX VPN service. Remote access to the Cisco PIX 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.

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.

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.

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.

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.

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

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.

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.

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.

We suggest you use USB tokens or wireless tokens.

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.

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.

Currently, we do not. Additional packages are planned, but we have no time-line for them at this time.

UPDATE: Our next release should be very OS agnostic allowing us to easily port to other Linux flavors, Windows and any OS that will run a J2EE container. The timeline is still very soft. If you are interested in you would like to be notified of this release, please Contact Us and put in the comments that you are interested in additional OS support. Please indicate which distro you favor.

Update Update:Thanks to an impatient Ubuntu user, we now have instructions on how to run WiKID on Ubuntu. This directions will probably work on Debian too. We will be incorporating some of these changes in a future release so that it will be easier to convert the rpms using alien.

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.

If you want support, if you want the wireless clients, or you want RADIUS support (and can't wait for the coming OSS 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.

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

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. Wireless tokens support an offline challenge-response mode when out of network coverage.

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