9. Challenge Response

Starting with version 2.6 all tokens have the possibility to do challenge response.

In detail this can be a token specific behaviour. The usual steps are as follows:

1. The user does a first authentication step,
2. the LinOTP server sends some kind of a challenge and,
3. then the user needs to do a second authentication step.

The OCRA token is a real challenge response token, where the OTP value is calculated based on a challenge. But the challenge response mechnism is also used for the SMS and the e-mail token and can be used for ordinary push button tokens like HOTP and TOTP.

Note

For tokens like HOTP and TOTP that are not challenge response token by design, you need to set a policy (Challenge Response) to activate the challenge response behaviour.

9.1. HOTP and TOTP tokens

Also other tokens like the HMAC/HOTP and TOTP support challenge response.

In this case the challenge is triggered by providing only the OTP PIN to the /validate/check API:

/validate/check?user=frank&pass=mypin

LinOTP verifies that this is the valid PIN for frank’s token and response with addition information:

"detail": {
    "transactionid": "041621212047",
    "message": "Please enter your otp value: "
},

The second in the authentication would be to pass the requested information (the OTP value) to the LinOTP server. This will be done this way:

/validate/check?user=frank&transactionid=041621212047&pass=698432

LinOTP will grant access, if the correct OTP value was provided.

Note

The second authentication step does not provide the OTP PIN anymore. But the transactionid from the first response is needed to proof, that the correct OTP PIN was presented earlier - in the first step.

9.2. SMS and e-mail

The workflow for the SMS and e-mail token are the same as described in HOTP and TOTP tokens.

The interesting thing is, that the LinOTP server can send an SMS or an e-mail, if the OTP PIN provided in the first step, was correct.

The user then can receive the SMS or the e-mail and provide the sent OTP value in the second authentication step.

9.3. RADIUS

If you are using a RADIUS client, that is capable of interpreting the ACCESS_CHALLENGE packet, this work completely transparent.

The user would enter his username and OTP PIN in the first step. These values are sent to the LinOTP server. The LinOTP server responds with a transactionid and a message “Please enter your otp value”. The rlm_linotp FreeRADIUS module sends an ACCESS_CHALLENGE packet back to the client and the RADIUS client displays the message and asks for the OTP value.

The user only has to enter the OTP received value during the second step.

Note

Please note that challenge response needs to be activated for tokens other than OCRA, SMS and e-mail. See Challenge Response for how to do this.