2

I'm thinking about the differences between physical authentication tokens such as RSA's synchronous physical tokens or asynchronous challenge/response, like Google's gmail direct-to-phone codes.

At the highest level of abstraction, are there reasons why a synchronous token will be better than an asynchronous token and/or vice-versa?

(The potential to introduce implementation-dependent security flaws may be a specific con to be considered at this high level of abstraction: maybe synchronous systems are harder to implement over asynchronous ones. For example, RSA tokens need to be physically secure to protect the seed as opposed to a phone, which doesn't necessarily have to be until the response arrives and then only while the response is still potentially useful.)

AviD
  • 72,138
  • 22
  • 136
  • 218
logicalscope
  • 6,344
  • 3
  • 25
  • 38
  • The question is too broad. You should be more specific what the usage case is and any other factors. – Bernie White Jan 09 '12 at 07:30
  • The question is broad on purpose because it questions security tokens as a group, not "a specific" security token. Somewhere, researchers decided that there were two ways to play this kind of thing. Whether there are specific advantages or not to one method over the other is a question that will trickle down into specific implementations – logicalscope Jan 09 '12 at 13:54
  • I think what @Bernie means is that without knowing your application we can't necessarily define which is strongest. Giving some more background info would let us comment on strength for your application – Rory Alsop Jan 13 '12 at 21:53
  • Fair enough, but there is no context for the question except that I read that there were two "categories" of tokens (async and sync) and felt there must be some reason for these two categories and not more, or even less. – logicalscope Jan 13 '12 at 22:11

2 Answers2

2

The advantage of an challenge/response system is the ability to prevent replay attacks. A challenge/response server sends the user a challenge which gets used in the authentication process together with the authentication credentials. The data which gets send during the authentication will never be the same although the authentication credentials are in most cases the same.

Your differentiation is somehow inaccurate, because even the RSA system is a challence/response system. The challenge is the time stamp the client and the server are sharing. By this the "almost"-one-time-password gets created.

The key difference of the both systems you are trying to compare is not the cryptographic weakness. The key difference is that the Google solution sends the authentication token via an insecure channel. So the RSA token is more secure, as long as they get their own company security managed. The RSA solution does not send anything necessary for the authentication over any channel. That is the advantage.

ceving
  • 462
  • 2
  • 7
1

Both one-time-password and second-channel challenge-response authentication can be thought of as synchronous. One-time-password generators such as tokens must use a key to hash a counter or timestamp, all of which must be known by the server. Second-channel challenge-reponses just require the user to verify receiving a one-time-password from the sever via the channel, such as entering a code from a SMS message or phone call. In both cases, the server and client must both know a shared secret.

A drawback of tokens is that the hash keys must be shared by both the server and the token; if the keys are stolen from the server, the token must be replaced. Second channels don't have this vulnerability, since the entered codes don't need to be generated beforehand, but they can be intercepted.

A smarter device than a token can use asymmetric cryptography. The server sends a one-time challenge to the device, the device signs it with the private key and sends it back, and the server verifies it with the public key. Since the server doesn't have the private key, they can't be stolen from the server to generate responses without the device.

I am a Duo Security engineer; this article by Jon Oberheide has more information and describes how we use this.

Karl Anderson
  • 386
  • 2
  • 3