Following Adam's Advice

Posted by:

admin 14 years, 1 month ago

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
• A world without static passwords →