When using SMS tokens with an authentication policy option otppin set to userstore, when the user authenticates and is challenged to enter the SMS token, they only need to enter the token to successfully authenticate. Is it possible to force them to have to enter PIN+OTP?
Interesting question.
This depends on the plugin.
Usually a plugin will treat this as challenge response.
In the second authentication request a transaction_id is sent along with the username and the OTP value from the SMS. This indicates, that the PIN was already provided.
If the plugin would omit the transaction_id, the user would have to enter PIN+OTP in the second auth request.
If you can not modify the plugin, maybe you can use some preeventhandler to mangle the request data and invalidate the transaction_id.
If I’m understanding you right, testing this with calls directly to PrivacyIDEA’s API, it doesn’t seem to work that way. In the first call I’m providing the user store username/password. In the challenge response, I’m providing the username and PIN+OTP. I’ve verified that I am entering the correct token PIN. I assumed this was happening because of the auth policy that says to use userstore. The only way to get past this, as you said, was to provide the OTP for password and include the transaction_id parameter.
Initial Auth
Challenge Response
Unfortunately I can not read anything on the screenshots. I am old. I do not have the eyes of a hawk anymore.
If you have a policy otppin=userstore then your PIN will always be the userstore password.
So you can not/never do
- Auth request
- username
- ldap-password
- Auth request
- username
- PIN + OTP
This will never work. You could only do:
- Auth request
- username
- ldap-password (which is the “pin”)
- Auth request
- username
- ldap-password + OTP
If you are omitting the transaction_id.
The normal way to do it would be:
- Auth request
- username
- ldap-password
- Auth request
- username
- OTP
- transaction_id
For more information read:
https://privacyidea.readthedocs.io/en/latest/tokens/authentication_modes.html
https://privacyidea.readthedocs.io/en/latest/modules/api/validate.html#post--validate-check
1 Like
For the images, it might help if you right-click on it and open the image in a new window, you’ll get the full size image.
Your two posts seem to contradict each other, however, your second post makes it very clear that enforcing PIN+OTP on 2nd auth request will not work.
1 Like
They do not. The thing is: For me the “PIN” is always the static component that is used with the OTP value.
Depending on the configuration it is a password from the userstore and a specific token pin.
But after all, it is the PIN.
And - you can not have two different knowledge factors during one auth request.
1 Like
Ah, I see what you meant in your original reply, that makes sense. Given the system that’s performing authentication has access to multiple factors, would there be a reason not to give the application that capability?
The idea for this comes from trying to give users a consistent expectation/interaction. When using TOTP/HOTP tokens, the user enters their token pin and otp value in one step, while email/sms has two steps, the first being token pin or user store credentials followed by only the PIN. What if TOTP/HOTP were configured to use challenge based authentication? Then, regardless of token type, the user enters user store/token pin and then asked to enter the otp value.
I realize PI doesn’t work like that now, but it’d be neat if it could 
(Given, that I understand you correctly…)
It can work this way. This is a very old policy setting, which you can use to make non-c/r-tokens to behave like challenge-response, since privacyIDEA is a really neat piece of software 
https://privacyidea.readthedocs.io/en/latest/policies/authentication.html#challenge-response
1 Like
oh my…oh that’s good…
Yes, I would have to agree that PrivacyIDEA IS a neat piece of software.
1 Like