OTP vs certificate based tokens

Question

I'm currently in the process of researching options for a two-factor authentication system for our company. I'm currently investigating the pros/cons of certificate-based tokens vs. one-time-password (OTP) based tokens (RSA SecurID being the most common). Initially it'll just secure our VPN, but may include other services at a later stage.

As I understand it so far, cert-based tokens seem to have many advantages over OTP tokens. They support other uses such as pre-boot authentication, full disk encryption, e-mail signing, etc. The cert-based tokens are configurable on-site and don't require someone like RSA to manufacture them to order. I appreciate that they require a PKI, which not everyone is willing to setup or maintain, whereas OTP tokens don't.

Despite the above suggesting that certificate based tokens seem like the better option these days, I get the impression - perhaps wrongly - that OTP tokens are still much more popular. Is it simply the case that they're cheaper and/or simpler to implement than cert-based tokens? Am I missing something? Is my assessment of the pros/cons largely correct? Why would you select one over the other and in what situation?

Answer 1

Certificate tokens and OTP tokens are similar to a degree, but in practice, their implementations are very different.

I would describe in summary as such:

OTP - light-weight, point solution, easier, proprietary integrations. Less secure, less interoperable, higher cost per authenticator

Certificate/PKI - heavy-duty, broad solution, extremely interoperable, multi-use, usable for physical and logical access

A more detailed description follows

OTP

• Standard basis: Proprietary generally, OSS solutions may exist
• OTP authenticator cost: 25 - 150 per unit + server software
• integration level of effort: low
• integration: limited to covered products (not many)
• OSS friendly: no
• Proprietary: yes
• interoperable with partners or govts: no
• usable for PACS: no
• usable for LACS: yes
• usable as an ID: no known token IDs.
• usable for file storage: no
• security level: moderate
• token duplication for backups: possible but never seen
• server tokens: believed not to exist
• usable by autonomous enterprise applications for machine to machine: no
• form factors: very limited
• easily usable with commandline apps: no
• hooks for applications: very limited, if any.
• software implementations: no
• hardware implementations: only
• customizing: little/none
• integration with air-gaps: no
• integration with stand-alone computers: no
• middleware required: no
• 3rd party validation client recommended/required: no
• reader driver needed: no
• control via Active Directory / GPOs: minimal
• interoperability with mobile devices: rarely, if supported

Certificate / PKI

• Standard basis: x509 PKI, along with published RFCs, commercial & OSS implementations
• OTP authenticator cost: 5 - 35 per unit + server software
• integration level of effort: low
• integration: almost unlimited; I count 200+ integration use cases in my agency.
• OSS friendly: yes
• Proprietary: no
• interoperable with partners or govts: yes
• usable for PACS: yes
• usable for LACS: yes
• usable as an ID: yes
• usable for file storage: yes
• security level: high
• token duplication for backups:: possible via secure means
• server tokens: exist in many form factors
• usability by autonomous enterprise applications for machine to machine: yes
• form factors: extremely scalable, a multitude of devices
• easily usable with commandline apps: yes
• hooks for applications: exist for many applications
• software implementations: yes
• hardware implementations: yes
• customizing: extensive
• integration with air-gaps: yes
• integration with stand-alone computers: yes
• middleware required: yes
• 3rd party validation client recommended/required: yes
• reader driver needed: occasionally, mainly for old operating systems
• control via Active Directory / GPOs: extensive
• interoperability with mobile devices: automatic rekeying supported with iOS & Android

OTP challenges:

I have seen many an OTP implementation where users are still required to use an OTP token for authentication events, but then have to drop to an additional software certificate system for encrypted email. This leads to insecure situations and an OTP is less user friendly. Because OTPs have so few integration points, they are usable mainly as a point solution when compared to a PKI.

Certificate/PKI challenges:

Much of this comes down to good planning, and a robust PKI implementation. When you are talking a full enterprise PKI, you are talking a large amount of infrastructure. See my post at https://serverfault.com/a/377230/40488 for good examples of the amount of infrastructure we are talking about. Although a PKI is thought of as expensive, there are companies that can run this for a business as an outsourced service cheaper than you can stand it up. Also, you are wedded to the x509 standard so it might be a good idea to read up Guttman's writings on the subject.

Conclusion:

I would recommend you make your decision for which authenticator based on the amount of integration points.

If you are heading towards just using it for VPN logon and Windows logon, and a few application authentications only, an OTP might be better.

If you are looking for VPN logon, Windows logon, secure email (SMIME), cloud based applications, full-disk encryption, usage with command line utilities, SSH, and extensive integration with OSS products, tie-ins to your MDM solution for mobiles, or potential re-use as an ID badge or physical access token, or regulated industries, or govt type of work where security is paramount, I'd go with the Certificate/PKI system in one of the many smartcard form factors.

Answer 2

I think your assessment is basically correct and I don't think there's much more to add. Maintaining a PKI is the deal killer for many people.

One other advantage of some OTP-based tokens is that they often don't require a driver. Tokens that display the OTP obviously don't need a driver. And some OTP tokens (like the Yubikey) emulate a keyboard and don't require a special driver. Certificate-based tokens s require access to a USB port and an installed driver.

The other use cases for PKI-based tokens don't really interest most people. Generally, whatever you need authentication for and whatever else you might do with the token aren't directly related. And generally companies don't want you using your authentication token for anything else. They get uncomfortable with the idea that you might be loading other things (such as email certificates) onto the token.

Also, some see the immutability and factory programming of OTP tokens as an advantage. They see it as less to go wrong and one less step they have to go through. For large companies, they just buy a batch of tokens, load one file into their computer, and they "just work".

Answer 3

OTP based tokens are usually easier to handle. For the administrator and for the user.

OTP based tokens unfortunately have one drawback: The do not work offline. This is why you can use smartcards for pre boot authentication and offline authentication with your notebook.

Some OTP solutions might try to do offline auth, but if you think about it deaply it is hard to really be two factor. I would call it one-and-a-half.

There are some solutions out there, that can manage otp tokens and smartcards.

Answer 4

Except for a very high level, I'm not sure how comparable they are.

Bingo cards and one time pads are very popular. This is literally the inverse of a smart card implementation. There isn't much appealing about that. A traditional smart card implementation is expensive and difficult, and the decision is academic for 99% of organizations that investigate it.

I don't consider any of those options that you listed as significant advantages. What an organization is after with a multi-factor solution is the ability to require it for all authentication. That prevents an attacker from (easily) using the account without the smart card. The downside however, is there seems to always be some application(s) that don't work if it is required, and there needs to be some kind of workaround. That would be essentially any application that prompts for Windows credentials (assuming you use Windows) and does not recognize or support smart cards. Custom web applications are fairly easy to smart-card enable. Proprietary vendor applications not so much.

That only covers the meat and potatoes topics. A significant consideration should be the vendor and product reputation and quality. A smart card requires a kernel driver and needs to be transparent and rock-solid. In practice it may not work so well. That probably varies between vendors though.