Skip to main content

The WiKID Blog

Viewing posts from September, 2010

Following Adam's Advice

OK, it's been about 2 weeks since Adam Shostack posted his excellent analysis of his own tweet "Use crypto. Not too confusing. Mostly asymmetric.".  Please read the entire post. 

Starting from the bottom: Obviously, we see big benefits in the use of asymmetric encryption.  In addition to the benefits Adam lists, using public keys allows WiKID users to have more than one token without a reduction in security, allows WiKID tokens to support multiple WiKID server and permits low-cost user validation after the keypair exchange. 

The more interesting thing that asymmetric encryption allows us to do is mutual https authentication.  Adam points to Eve Maler's TOFU/POP aka "Trust on First Use/Persistence of Pseudonym", or as he prefers "key persistence" as a key mechanism of reducing user confusion while providing mutual authentication.  Our system goes one better. The WiKID server stores a hash of the targeted site's SSL certificate.  Each time the user gets an OTP (which are generated on the WiKID server) that hash goes to the client too. Before the WiKID token displays the OTP, the token goes to the targeted site, grabs the cert, hashes it and compares it to the one from the WiKID server. If they hashes match, the OTP is presented, copied to the clipboard and the default browser is launched to the site.  If they don't match, an error/warning is presented.  Obviously, the first download of the cert to the WiKID server must be trusted.  After that, the user does not have to check the pseudonym, the WiKID token does it for them.

I also equate Adam's "not too confusing" with our mantra for ease of use.  In fact, we recently chose ease of use over total world domination (TWD) in a small way. The ability for a token client to work across multiple WiKID servers creates the possibility of viral growth rates for WiKID leading to TWD.  However, the process of adding a domain is more complex if users can add more than one. So, we made specifying a dedicated domain an option in our PC software tokens, reducing the confusion for the end user. Now, when they start a dedicated token for the first time, all they have to do is double-enter their PIN and return their registration code in some secure manner to the server (for example, by first logging in to a web site with their AD creds).

As for Adam's first point, use crypto, it should be obvious that we believe.  I would add that we would like to see more things be passed through the WiKID token the way we pass the SSL certificate hash - or in the other direction.  Once WiKID is deployed, you essentially have a flat, public key infrastructure (a la GPG/PGP and a single key server, not certificate authorities).  There's no reason why tokenization of personal information can't be done through this setup. 

For the record, all features discussed here are available in the open source version.

Product improvements, prospect relations and Bsides

These past few weeks, we released 3 minor updates to our PC software token client.  These were all in response to a single prospect that is rolling out WiKID using the Web Start version of the WiKID PC Software token.  (The Web Start version or JNLP is an easy way to distribute the software token especially if you don't have a software management system that can push software out to corporate laptops.)

Based on feedback from this prospect, we now do a better job of specifying the location of the private key storage on Windows and Linux, we allow for a single, dedicated domain to be specified in advance for ease-of-use, and you can specify a custom file for the Web Start software token.  Taken together, these changes have created an easy-to-use, highly customize-able, cost-effective solution for two-factor authentication.

More importantly, they show how vendors and prospects working together can create better solutions.  WiKID and $prospect benefit, but so do future prospects.  Competitors respond, improving their product, forcing us to improve in a virtuous circle.  I've been concerned for a long time that the prospect-vendor relationship is strained at best, mostly broken, slowing down this process.  I'm sure that most of us have given fake emails or hotmail accounts to vendors.  It is also noticeable at industry conferences where vendors play a form of laser tag with the prospects as the targets. 

I'm not sure how to re-build a level of trust between these two parties. I think events like SecurityBsides which a sponsored by vendors, run by volunteers and lack vendor booths or excessive sales pushiness are a good start. BSides is still clearly feeling its way.  The volunteers are mostly from vendors and I don't really see a way around that.  The sponsors seem to understand that it's a community engagement platform and not a lead-gen opportunity.  (WiKID has sponsored the first Bsides in Las Vegas and one in San Francisco during RSA and we are co-organizing/Sponsoring the BSidesAtlanta.) 

We got a long way to go though.  The attack mentality of many companies is stiffling feedback and hurting product development.  I believe this especially affects small companies, such as WiKID, which are taking on existing, entrenched competitors. Our best asset is our ability to convert feedback into product improvements quickly.  Without feedback, we're potentially wasting our resources.  That's why we love tough prospects that tell us what they need and why we support BSides.

Google's "Two-Step Verification"

Kudos to Google for putting more security around their authentication for Google Apps. Apparently, two-step authentication will be coming to Gmail as well once they feel comfortable.

Software Tokens: Less expensive, easier to use.

So it has been quite a while since my post about the Security of Software Tokens.  In that post, I pointed out that using public key encryption eliminates the problem of securing the seed.  There is no seed.  I also pointed out that if you're concerned about malware, fight malware. 

Recent Posts







RSS / Atom