Skip to main content

The WiKID Blog

Viewing posts tagged Mutual Authentication


Much of the discussion of the need for strong mutual authentication has focused on consumer applications - in particular the failings of non-cryptographic, image-based solutions. However, there is also a risk for corporate VPN access where SSL-based VPNs are deployed. Creating a man-in-the-middle attack that thwarts SSL-based VPNs is trivial with the proliferation of WiFi networks.


Securology has a post about RSA's software tokens. In it, two key issues with are raised, one is specific to tokens that use symmetric encryption such as the RSA software tokens:

Distributing the seed record requires a confidential channel to ensure that it is not perfectly duplicated in transit. Distributing seed records to many of the supported platforms of soft token vendors involves plaintext transmission, such as sending the seed record as an email attachment to a Blackberry client. An administrator may provision the seed record encrypted using an initial passphrase that is distributed out-of-band, but it is common practice for seed records and initial passphrases to be distributed side-by-side. Whereas a physical token can only be in one place at a time, a soft token could be perfectly duplicated by an eavesdropper, even complete with its initial passphrase (especially when it isn't distributed out of band). If Alice receives her soft token and changes its passphrase, Eve could keep her perfect copy with the intial passphrase or choose to change the passphrase-- either way, the back end of the one-time-password authentication system will receive a valid token code (time value encrypted with the seed record).
Note that this is not an issue with WiKID's software tokens as we use public key encryption. The private key remains on the device and only the public key is transmitted. It is the out-of-band method of verifying the user's registration code that matters for WiKID. This could be done over the phone or via an application which uses some existing trusted information or credentials. (We protect against a man-in-the-middle attack in this process by hashing the registration code with the WiKID server's public key before presenting it to the user. Thus, if someone is trying to impersonate the server, the registration with the real server will fail.)


The Washington Post Security Fix points out how phishers are exploiting weakness in the certificate granting process to fool users.


Today I receieved a phish that is targeting commercial accounts of BB&T. It's interesting because it will be much harder to do transaction analysis fraud prevention on commercial accounts (same for brokerage accounts) and the email used a pending 'security device' roll-out as the premise for needing the information.


PingID released today, which looks like a great addition to the consumer-oriented SSO services available. I take some exception to this quote from PingID CEO Andre Durand about InfoCards

After a user creates an information card on their desktop, they can access and link the card to their account on the site. On subsequent visits, the card is needed for the user to authentication to
“It’s a form of strong authentication,” says Andre Durand, CEO of Ping Identity.
Now, I don't know as much about InfoCards as I should, but I know it's not strong authentication. What these services need is strong mutual authentication, so that the user is assured that they are going to the correct SSO service. Then, the SSO service needs to get the user to the correct targeted site.

Recent Posts







RSS / Atom