Wikid Token & OpenDNS

posted: December 9th, 2010

There is a lot to like about OpenDNS, my favourite features being protection from malware and being able to effectively and easily control what content my users / devices can access simply via DNS.

One of the things I dislike is they return their own IP ( or if the host or record you are looking up doesn’t exist. In this particular case using OpenDNS prevents Wikid 2-factor authentication tokens (only iPhone tokens) from being able to obtain a one time passcode.

Over the past year I have been unable to use my iPhone Wikid token when using wifi, which was quite odd. In October I switched to China Unicom as my mobile / 3G provider, since China Mobile’s 3G doesn’t work and ever since that I haven’t been able to use the token on wifi or 3G, which was making my work impossible!

If you attempt to use the token client on an iPhone that is using Opendns as a resolver you will get an error :

Error Unable to fetch passcode 

I ran a packet capture of the iPhone talking to the wikid server and discovered that the iPhone token client uses DNS to resolve the IP of the Wikid Server (IP addresses obfuscated) :

proto: UDP (17), length: 75) xxx.xx.88.126.59389 > 
[udp sum ok]  52734+ A? (47)

So looking at the capture above the iPhone token looks for a host which doesn’t exist and Opendns returns a bogus IP, which the token then tries to get a OTP from and fails!

Digging a little deeper I found does exist and is an alias for I summize that this a beta feature that only found it’s way into the iPhone client (fortunately).

This is a disappointing design decision because :

  1. It is intimated that the Wikid domain, which is a zero padded representation of the public IP of the Wikid server would preclude the need for any reliance on DNS, which is inherently insecure.
  2. Secondly it introduces another dependency or level of complexity and in a security context this is always a bad idea.
  3. The benefit of mutual authentication is weakend if a denial of service can performed simply by forging a dns reply

I hope that this can be fixed in the next revision of the iPhone token client.