"Strong Authentication for the masses"

I don’t think WikiD is very secure at all. It is subject to a simple replay attack.

Their description of the token is that it ” … is is encrypted with the WiKID Server’s public key - assuring that only that server can decrypt it with its private key.” This is subject to several attacks. On its face, it means anyone can copy this encoded message and replay it in an attack.

In a more sophisticated version of this attack, the super secure encoded message is intercepted in a MIDM. The authenticated message is forwarded to the server, which sends the bad guys the OTP.

Thanks for the nod. I'll talk about your points in a later comment (between teleconferences for work at the moment). Am working on the install at the moment - aside from a lack of documentation, nothing has broken at the moment. Note that I'm using Gentoo, which is not an RPM-based system, so I'm figuring things out as I go.

Drop me an email, as I do have some questions that I'd like to hash out outside of comment boxes.

Okay, focused now.


However, you describe there that the PIN is also encrypted with a single-use AES key. If that encryption happens before encrypting with the server public key, then fabulous - each encrypted PIN message is unique and can't be replayed. If the PIN is encrypted first with the server public key, then the single-use AES encryption is really acting like an SSL session and can be attacked by a MITM attack - recover the public key-encrypted PIN from the AES-encrypted traffic, open a new session to the WiKID server with new AES keys and replay. (I think, anyway. It depends on whether or not I can recover the AES key exchange from sitting in the middle or not. That may not be possible.)


"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."

This would imply that the OTP is returned encrypted by the device client public key, not a user's public key. Great example - my wife and I share the same laptop. I'll have the device client installed there. Do I need to have it installed a second time for her to use, or (as I expect) would she use the same device client, feed her username and PIN code, and get back a OTP for her? Then the device client isn't unique to the user, I can roam freely between device clients (that have been configured for my Domain), and the uniqueness is limited to the PIN.

First, this is AWESOME! This is far more analysis than we got at some F500 financial services companies - but that is for another blog post.

First, think of WiKID as a public key transaction with symmetric encryption at the transport layer. It is possible to get the OTP request and replay it to the server. The server responds with the OTP encrypted by the token client's public key and the attacker can do nothing with it unless they have the client's private key. The AES key is a chain block cipher. It is a variable length so it looks different each time, even if it happens to have the same data.

Second, the MITM attack described by Michael is valid for all forms of authentication. However, WiKID can be extended to thwart this attack. More on that later too.


i.The user selects the domain for which he or she needs a passcode.
ii.The user provides the PIN for the domain, created in the registration process.
iv.The payload (password request) is sent encrypted to the server.
v.The server receives the request and decrypts the request with its private server key.
vi.The server looks up the appropriate requesting client device (via the deviceID for the security domain) and verifies the PIN.
vii.If the PIN is correct for the security domain and client device, the server creates the passcode payload by creating a passcode (length is administratively configurable) for the client device and encrypting this payload with the client public key. The payload is then transport encrypted with the random AES key provided by the client.
viii.The passcode is then time-stamped and allowed to live based on the parameters of the security domain (from seconds to days, depending on sensitivity of asset).
ix.The WAS then returns the client request with the payload.


i.The response must be decrypted with the random AES key sent in the request.
ii.The payload must be decrypted with the client private key.
iii.If the payload is verified, the passcode is displayed on the device and the user can use the passcode for access to the network service.
iv.If the payload is not verified, an error is created and the process should be repeated.
v.Lastly, the WAS only allows passcodes to be valid for a specific time period and they may only be used one time.

The server responds with the OTP encrypted by the token client's public key and the attacker can do nothing with it unless they have the client's private key.

*smacks forehead* Ah, I get it now. You're not encrypting the response with the server's private key (to prove it came from the correct server), you're encrypting it with the client's public key (so only the correct client can understand it). You're doing two-way asymmetric encryption. That makes sense now.

As for the multiple clients, I get that now too - you're using the device client ID to represent the user identity, and the PIN for verification. That makes sense, and having multiple device clients on one computer allows for multiple users - one device, many users. I also have plurality in the other direction - many devices, one user - as I plan to have a client configured for me on my home computer, my work computer, et cetera. (If the J2ME client gets opensourced, then I may just put it on my cell phone and be done with it.) I assume there are ways to tie multiple devices to a single user account on the target system; I haven't gotten that deep into the configuration yet.

Well, we certainly can be better about explaining things and sometimes I can type faster than I think ("the PIN is encrypted with the one-time AES key" instead of "together with the one-time AES key").

Open sourcing the J2ME client will be tough. We tested RSA and ECC packages to see how long key generation took on a J2ME cell phone. The numbers looked to be about 14 days for RSA and 14 hours for ECC. With the Ntru packages, it isn't even noticeable.

Hm. Good point about the computational, er, limitations of J2ME devices. One approach might be to offload that task to a standard computer. Use a PC program as a builder/packager to generate the keys, wrap them up with the J2ME client, and make that a package to install on the device. It's an off-the-cuff suggestion, but the key generation only happens once, so there may be a way to offload that processing time (given a trusted network).

If someone copies the WiKID and the PIN from a system, isn’t the entire logon compromised?

You couldn’t really use this for banking could you?

If someone has the PIN and the private key, then they have both factors, the equivalent of having the ATM card and the ATM PIN.

What would I suggest? Well, for starters I would suggest we use a technology that can’t be readily exploited.

It is really not like getting my ATM card at all – far from it. Spyware regularly gets into the PCs of most users. If it isn’t some form of adware it’s a key logger. It isn’t a huge leap to steal the WiKID certificates as well. This ability to have your Wiki stolen and not know about it is indeed troubling.

There are a number of assertions you have made on your web site and in the above reply that are flat out not true. Lot’s of applications that use hardware tokens implemented over the Internet that are absolutely immune to MITM and sniffers. Companies like Cisco, Microsoft, Citibank, and many more do so.

The other assertion is the cost, which you have categorized as high - a highly imprecise term. Simple math could prove that it is lower than software tokens. Assuming that a hardware token is between US$20 - US$60, and that a corresponding software WiKID token is only US$1 (using numbers that maximize WiKID cost per unit) a deployment of 10,000 units would cost as much as US$600,000.

Since the potential for a stolen hardware token being used to exploit an account is very small, and the reverse being true for a software token, we must factor the potential exploit risk. Of 10,000 accounts, with an average of $1,000 (or $10M), times some none zero risk, meets a breakeven point at 6%.

That is to say, if 6% of WiKID accounts are exploited, you are at exactly breakeven mathematically, using best possible numbers. Using numbers less favorable to WiKID, breakeven could be at 2%. That is very risky.

WiKID may have application somewhere but I couldn’t recommend it to a Microsoft or anyone of my companies.

Finally, just so that no one feels that I have deflected any of your comments, separate accounts for sessions and transactions don’t help since for spyware, two accounts are as easy to steal as one.

If you are concerned about a compromised PC, just use the wireless client.

I agree that certain applications are not susceptible to MITM attacks - even without hardware tokens, but ones that rely on a user validating the SSL certificate are indeed susceptible to those attacks. I think you are missing the attack here. A real-time MITM phish where using a OTP does not help. The only way to stop it is by mutual authentication, which a hardware token cannot do.

As for our assertions regarding the cost of hardware token, I stand by them. The numbers we have used for items such as the cost of token distribution are from sources such as Gartner. We can always be less expensive than any type of hardware token.

We are not trying to sell snake oil here. I know that WiKID can be attacked, but we stack up very well against hardware tokens, particularly for consumer-oriented https-type applications.

Your answers were a bit too dismissive.

For starters, I can use my PC with a hardware token, thank you very much. It just doesn't much help your sale by sending me off with the comments "if you are concerned about a compromised PC, just use the wireless client."

My sole goal is to understand the value-added of WiKID. I am not sure it is worth continuing this discussion on this blog, so I will not try again, except to note this one last final set of comments. I am only voicing the opinions that I am sure others have when they read your web site.

I was using Gartner's numbers on the cost of a hardware token. This is a business I know a lot about and it would be extremely helpful if we quoted data and not terms like high, low, secure, and what not. Specificity is what I want.

We should at least be able to agree that the cost of deployment of hardware or software tokens include the cost of FTE's (full time Engineers), planning, server hardware, deployment costs (emails, announcements, distribution), support costs, replacement costs, and of course, for hardware, the cost of the tokens themselves.

There isn't a substantial case to be made that costs are lower for deployment except for the cost of the fobs themselves. Everything else is about the same cost. We'll also ignore completely the cost of installing the software token on a PC. This cost is not zero, but we'll just ignore it for now.

That leaves only the cost of the token as the differentiator. Gartner claims that the tokens themselves are between $25 and $45 each. Add all of the other deployment costs and the cost of a toke, hardware or software is more like $125 each.

We can do some math here, but at 10,000 tokens, the hardware totals at $450k, support and IT costs consume the remaining $800k.

With software tokens, 10,000 licenses may be $1 each, with support and IT costs adding up to $800k (if we agree that these costs are the same).

The difference is $450k, or $45 per token. In my earlier posting I quoted a figure even more favorable to WiKID at $60 per hardware token.

Using the same logic as the previous post, break even is at 4.5% (or at 6% if you use my previous numbers).

If you have a different set of numbers, I certainly would like to read about it.

Please don't take my excitement for our product as a dismissive attitude. Far from it, I appreciate your feedback and your continued debate. If you would like to take it offline, I'm more than happy to continue.


I think we disagree on two points. First, I think that the cost of shipping 10,000 hardware tokens is higher than the cost of distributing software. Gartner assigns a $15 cost of token distribution for hardware tokens in scale, as I mentioned. I agree that there will be a cost for distributing software, but it will not be anywhere close to $15 per user. So we do not agree that the support and IT costs are the same.

I'll give you my take on WiKID's numbers. If you take 10,000 users again, the price of WiKID is $16 per year. We offer a prepayment discount though of 10% per year, so if you pay for three years, the upfront cost is $33.60 or $336,000. Since we can automate the entire process of rolling out the WiKID tokens, I would estimate about $50,000 for IT and support costs. Let's call it $400,000 or $40 per person versus the $125 per person you quote.

Further, our costs will drop with scale. The cost of mailing a token will not, so we can be much cheaper as volumes increase - which will be the case for online banking.

The WiKID thread continues at Thinking WiKID Thoughts, the blog of the CEO of WiKID systems. Awesome stuff....