Synchronous VS. Asynchronous Tokens

Chassidic1 · July 2013

B"H

JD, I could use your help better clarifying the definition of Synchronous VS. Asynchronous Tokens.

For synchronous tokens, Conrad seems to say that this means time synchronization between the authentication server and the token is used as part of the authentication method. He writes: "the authentication server knows the serial number of each authorized token, the user it is associated with, and the time." "It can predict the dynamic code on each token using these three pieces of information." Here his example is an RSA token, which I actually use at work... this much I "get".

My confusion comes into play about the next option - asynchronous tokens. Conrad states that "Asynchronous tokens are not synchronized with a central server" and that "the most common variety is challenge-response tokens." Does this imply that when I receive a "challenge" that I am not required to provide the corresponding "response" within a given period of time? For example, can I receive the challenge now in the morning and provide the response at night, and assuming the correct reply, be authenticated?

I did some research online and did not find an example. Instead I found a post that made me think RSA key fobs use challenge/response. Here is the link: authentication - Synchronous and Asynchronous physical security tokens: which is stronger? pros/cons? - IT Security Stack Exchange

I feel confused; what's the deal, and you got some actual examples of technologies used in the real world for both?

Thanks in advance,
Dovid

JDMurray · July 2013

"Synchronous" means with time and "asynchronous" means without time.

Synchronous tokens are time-synchronized to an authentication server for the purpose of creating a One-Time Password. The token and the server each have independent clocks that must be synchronized to the same timebase. The OTP created is only valid for a short amount of time. If there is too much difference between the token and authenticator clocks (drift) the password authentication will never be correct.

An asynchronous token also generates an OTP, but do not use time synchronization between token and authentication server. Instead, a random challenge is generated and sent to the user who enters the challenge into the token. The token displays a result that the user sends back to the authenticator. The challenge is only valid for a short time, and only the authenticator need to keep track of how much time has elapsed since it issued the challenge.

I will admit that I had to do some page-flipping to get this straight myself.

Chassidic1 · July 2013

Thanks JD; that helped. A friend of mine in security was like "synchronous is OTP, asynchronous is static; mostly asynchronous uses username/password form." But, for some reason, I think you may be right...maybe both are OTP and the sole difference is whether the supplicant and authenticator are synched...although, to be honest with you...if that is so, then, what gain is there in forcing time synchronization? isnt that a limitation? namely, it is another factor that could go wrong...whereas without that need, I get the same level of security at no additional risk...??

Thanks again in advance!
Dovid

JDMurray · July 2013

The time synchronization is an additional security factor. The time is not the time of day, but whatever secret timebase is being used between the token the the authenticator. If something goes wrong with the logon, the system fails closed and doesn't allow potentially unauthorized access. Time synchronization also removes the need to manually enter a challenge into a token, so it could be cosidered a usability factor as well.

Chassidic1 · July 2013

Thanks JD - useful and informative, as usual

jonwinterburn · July 2014

Just came across this thread when searching for sync/async tokens. I'd like to say thanks to JD too, as your answer has helped clear up the confusion in my mind with these tokens too

One additional thing you may be able to clarify - in Darril Gibson's SSCP book, he states "Hardware tokens are synchronous, not asynchronous". That seems incorrect to me. Example: I have an RSA SecurID fob which is synchronous (time-based) and I also have a bank card reader which is asynchronous (challenge-response). Both are hardware. Or am I missing something? Just want to make sure I get this right, so I don't make a silly mistake on the exam.

JDMurray · July 2014

Are you running a plastic card through a card reader? If so, the card itself is not considered to be "hardware."

jonwinterburn · July 2014

I see your point that although the reader itself is hardware, the card would be considered a soft token. Presumably this is because the card is not self-contained as such, but merely a passive container of software (in the chip).

JDMurray · July 2014

The smart chip in the plastic card is a passive, digital information storage container. It contains you identification credentials used for authentication and also proves that you (or someone) is in possession of the card itself. That would be an example of a low-security, asynchronous (without time) hardware token. A more sophisticated example would be a YubiKey.

teancum144 · July 2014

jonwinterburn wrote: »

... in Darril Gibson's SSCP book, he states "Hardware tokens are synchronous, not asynchronous". That seems incorrect to me. Example: I have an RSA SecurID fob which is synchronous (time-based) and I also have a bank card reader which is asynchronous (challenge-response). Both are hardware. Or am I missing something? Just want to make sure I get this right, so I don't make a silly mistake on the exam.

According to the OG:

There are two basic authentication-by-possession methods: asynchronous and synchronous. An asynchronous token device is a challenge–response technology. A dialogue is established between the authentication service and the remote entity trying to authenticate. Without possession of the asynchronous token device, a correct answer to the challenge cannot be generated.

Source: Hernandez CISSP, Steven (2012-12-21). Official (ISC)2 Guide to the CISSP CBK, Third Edition ((ISC)2 Press) (Kindle Locations 2472-2475). Auerbach Publications. Kindle Edition.

This sounds like it could be a hardware device to me.

Spin Lock · July 2014

JD's response was excellent.

The only thing I'd add to this discussion would be to ask the question "How might the CISSP exam test my understanding of synchronous vs. asynchronous tokens?"

That is the question I always ask myself as I prepare for the exam and encounter new topics.

And as anyone who is read this forum for any length of time will tell you, the exam is less likely to test your knowledge of protocol details, bit widths, or other purely technical details and is far more likely to test your understanding of fundamental concepts.

Going on that assumption, I could imagine seeing a question that might be very difficult to answer if you were not clear on both the similarities and differences in sync vs async tokens.

I don't claim to be any kind of expert on this subject. I'm just another bloke studying for the CISSP, so it could be I'm wrong about some of the information below, but based on what I've read, I'd summarize the similarities and differences as follows:

Sync & Async Tokens - How they are similar
=================================
1. Both are physical, digital devices that contain non-volatile memory, a microcontroller and some amount of embedded software (i.e. encryption algorithm and a shared secret key)

2. Both are used as part of "token-based" user authentication systems. An authentication system ensures a user is who he says he is. The most common form of authentication is "single factor" authentication - which is the username and static, reusable passwords we all use. Token based authentication systems are stronger (more secure) because they require two-factor authentication. The factors in a token based system are something the user knows (a PIN) and something a user has (the token). In other words, with a token based system, the user must provide a PIN *AND* the output from the token. Only when both match what the authentication server requires will the user be authenticated.

3. The "output" from the token is a one-time password (OTP). Both sync and async tokens generate this OTP. It is *HOW* this OTP is generated that differentiates a sync token from an async token (more on this below).

Sync vs. Async Tokens - How they are different
====================================
1. As stated above, both tokens will generate (output) a one-time password. But the process by which that OTP is generated is different.
2. Asynchronous token generate an OTP as part of the "challenge/response" procedure, which works as follows. The user initiates the login process, which causes the authentication server to generate a challenge code to the user. The code is entered into the token which then causes the OTP to be generated. The user enters the OTP (along with his PIN) and the server validates the information. From a concept perspective - what is important to note is, the OTP is only generated in response to the user entering the challenge code. If no challenge code is entered, no OTP is generated.

3. Synchronous tokens also generate an OTP, but NO CHALLENGE CODE OR OTHER USER INPUT IS REQUIRED. Instead of the user entering a challenge code, the sync token uses an internally-generated timestamp as input. That timestamp and a shared secret key are fed into an encryption algorithm to generate the OTP. IMPORTANT: the timestamp is automatically generated in regular intervals (say, once every 60 seconds). This means the OTP will change every 60 seconds regardless of whether the user needs the OTP or not.

Why is one method called "synchronous" and the other "asynchronous"?
=====================================================
When a timestamp is used to generate the OTP, the authenticating server needs to generate the exact same timestamp value as the token. If their timestamp values are different, the OTPs they calculate will be different and this method won't work. Thus, it's critical that the token's clock and the server's clock are SYNCHRONIZED. Thus, this method is called a "synchronous token". An second explanation is that, in general, when a system generates an output in response to a clock input, it's called a synchronous system because it's time-dependent (think of synchronous state machines vs. async state machines in logic design).

When the OTP is generated only after a challenge code is first input into the token, this is called an "asynchronous token" because the OTP is not being generated on any regularly basis. It is only generated when the user enters the challenge code. This means the user might enter 1 challenge code per day, then not use the token for a week, and then enter 10 codes another day, then not use it for a month, then enter 20 codes in a day. This behavior is asynchronous - the OTPs are not generated on a regular time interval, they are generated asynchronously.

Back to the CISSP exam - if I came across a question mentioning sync and async tokens, I would pay close attention to the details. If the question mentions the server issued a challenge, then I'm probably dealing with an async token. If the question clearly states no challenge/response interaction was required, then it's likely synchronous.

I seriously doubt the ISC2 would give a you question that said the token is "hardware". That's way too vague.

They might try to trip you up by saying "the user waited too long to enter the OTP and the login session timed-out. This means the authentication system is synchronous, correct?" - Both systems use timeouts. But a timeout does not imply synchrnous vs asychronous behavior. Those terms deal with how the OTP is generated. What was the input or stimulus that caused the OTP to be output.

Again, I'm not claiming to be an expert. If there's a flaw in my logic, I'd welcome other's feedback.

nawanis · November 2014

One-time passwords with token - InfoSec Institute

Synchronous VS. Asynchronous Tokens

Comments