This begs the question of whether a token, a password/PIN and a certificate constitute multifactor authentication. The old definition — “something you have, something you know and something you are” — starts to fall apart here. Is an X.509 certificate something you possess in the classic sense? Or, arguably, is it something that the computer possesses? That being the case, we’re back to only something you know: the password/PIN to access the computer/certificate.
How, then, is this different from a PIN and a token? The answer is that the token is under your control. If the token is not in the physical possession of the user, there is no way to match the known and the possessed. If, on the other hand, the certificate is on a laptop that is stolen, and the password to the computer is easily guessed, the certificate is in jeopardy. Bottom line? Multifactor may not always be what it seems.
One thing that we noticed this year was the variety of authentication methods supported. There were several products for which multifactor meant that you have a choice of several methods of authentication, not necessarily used in combination with each other. This adds lots of flexibility for large distributed enterprises.
Cost always has traditionally been a show stopper for multifactor authentication, especially where hardware tokens are involved. If this month’s batch of products was any example, though, that problem is rapidly being reined in. We saw per user costs of under a dollar. However, these low cost options are also quite innovative.
Tokens now come in all types, as well. Key fobs, hard cards and USB tokens all are available and all are competent and easy-to-use. One major challenge for multifactor authentication, regardless of how simple to use the tokens are, is enrollment. Distribution of tokens across a geographically disbursed enterprise can be challenging. Somehow those tokens need to match up with their users, get into the system, and the user needs to enroll. Questions arise as to how we know that the user enrolling the token is the user for which it is intended.
How we tested
We began by installing any specialized software that was needed in our test bed. That included such things as LDAP (Lightweight Directory Access Protocol), Active Directory or SQL. Then we installed the server software and, finally, clients. Once the software or hardware (as appropriate) was in place we began enrollment. We were concerned about ease of use, especially in the enrollment process. Finally, we attempted to bypass the security for the token or token-less service.
Generally, we found that these products are good solutions to the challenge of strong authentication. However, not all are as easy to use or administer as we’d have liked. We were unable to bypass security on any of the products, and user spoofing was unsuccessful too.
What to look for
Start by looking for true multifactor authentication. Are the factors strongly connected through the user, for example? What is the authentication method being used? Is it a one-time pass code being generated by the token or is it something built into the token? One-time pass codes tend to be more secure than things built into the token.
Next, look for ease of deployment, especially self-enrollment, and administration. Self-enrollment needs to be robust and secure. Consider the problem of user spoofing. This is far easier to accomplish at enrollment time.
The final consideration is cost. One thing we saw clearly in these products is that there is a wide range of cost for a wide range of products. Cost is a bit elusive in some cases, however. A few of these products do a lot more than authenticate a user to a computer. Some have the basis of single sign-on as part of their functionality. Some include other advanced features. Be sure that you need these because they all add to the price you’ll pay.
Mike Stephenson and John Aitken contributed to this review.
The StoneGate FW-5000 from Stonesoft, reviewed in the November issue on page 57, should read that it provides 22 Ethernet interfaces. Stonesoft provides other offerings designed for SMEs.
In the December issue, we misprinted the price of Archer Technologies’ product in the chart. It should read $45,000, as in the article.
Our apologies for these errors.
Also, in the Archer Technologies review we should have accounted for earlier acquisitions by Cisco and Verisign. So in the middle of the review where it mentions iDefense, it can be updated to read Verisign, while TruSecure should read Cisco.