So you’re curious about the backend processes for tokens that generate one-time-passwords (OTPs) such as the RSA token, or something like an authenticator app?
First, it’s important to note, that there’s a distinction between something like a Duo challenge and response and a code generator, like Microsoft authenticator and similar apps. An app like Duo, when used to press a button on our phones to allow login to websites or other systems is not simply a one-time-password generator, but is actually acting as an “out-of-band” authentication device. The distinction between that and something like entering a randomly generated code on an RSA token or similar, is that the out-of-band device actually establishes a secure channel with an authentication server, using the established secure channel to transmit an authentication challenge from the remote server to the device, like an OTP, or a check mark to press.
Devices like RSA tokens are single-factor OTP devices, which differ from out-of-band devices in a few important ways. First, instead of having an authentication challenge presented to the device, a secret (like the code on an RSA token) is cryptographically generated separate and apart from the verifying device, with the secret being independently generated by the token and compared by the verifier. There are also two values on a single factor OTP token which remain on the device for its lifetime: a symmetric key, shared with the remote server that verifies authentication, and a nonce which is typically either a calculated value, or is based on a real-time clock.
In the case of an RSA token, the value is based on a clock with time synched when the device is first deployed. There’s a level of sensitivity between the token and it’s verifying server (usually 5 seconds or less), to allow for some slight time drift over the life of the device, and the calculated value is changed at a regular interval. Once the value is transmitted, the remote verifier compares the value to its own calculated value and, if they match, the device is authenticated.
A device like a YubiKey differs a bit from an RSA token, as instead of generating a code to transmitted by user input, it’s directly connected to the user endpoint, where it uses an internal cryptographic mechanism to authenticate. It’s important to consider these devices not as standalone single-factor processes, but as part of a multi-factor authentication strategy, such as a combination of RSA token code and username/password for authentication, or a website logon/password and DUO.
Going even further with token authentication devices lands you in the area of multi-factor devices like smart cards, which require both possession of the card (something-you-have) and knowledge of a corresponding PIN code (something-you-know) and presence of a user account on the device being accessed (something-you-are). A familiar example of this is the DoD CAC card. To log on to a DoD system, you must have a smart card, the PIN to that card, and an account corresponding to the subject or subject alternate name of one of the certificates on the card.
Josh Lambert 