Otp with pin does not work if challenge-response is enabled (needed for other token types)

Hi,

I have a problem similar to Require PIN+OTP With Challenge Response - #9 by wwalker but the solution mentioned there does not seem to work in my case.

I’m using privacyidea 3.6 with keycloak. I have keycloak configured to use triggerchallenge.

When a user with a TOTP token that has a PIN tries to authenticate through keycloak they have to provide only the OTP without the PIN for authentication to succeed.

I’ve opened TOTP token with pin only works with keycloak if the pin is omitted · Issue #70 · privacyidea/keycloak-provider · GitHub for this where I was told this is caused by enabling triggerchallenge. When I disable that setting in the keycloak plugin it works, but then I lose the ability to authenticate with my webauthn token.

I tried to create an authentication policy that sets challenge_response to “totp webauthn” but that doesn’t make any difference.

Is there a solution for this, where I can keep the triggerchallenge enabled in keycloak and allow users to have a pin on their TOTP tokens?

Regards,
Rik

No. Triggerchallenge does not work with PINs. This is the sense of triggerchallenge, to get rid of PINs.

But being able to set a policy requiring PIN+OTP with challenge would be great :wink:

After the user authenticated with a userpassword?

Why?

Versatility: Adds additional capabilities to an already capable system. Security professionals can further tailor their authentication to the organizations wants/needs.

Meeting definition of MFA: MFA is defining as using two or more factors to authenticate a user. PI obviously meets that now. Adding the ability to also require the token’s assigned PIN furthers meeting the definition.

Additional hardening: Security professionals are sometimes paranoid folk. The potential exists that someone’s user store credentials and physical device are compromised. Adding the need to know the token’s assigned PIN can mitigate that possibility.

Still why? Being more versatile? How is this? Would like to know. Why is this use case? What is the use case requirement behind this technical requirement?
(For German speaking readers, please listen to 009 Features oder Konzepte? - LOGIN Success - Podcast

Au contraire: Having a password, a PIN and an OTP value are still two factors. A password and a PIN are not two factors. These are only one factor - only longer.

Thank you.
However, you could still do this, if you would not trigger the challenge, which is by definition used to skip the PIN.
Thus you would need to disable the triggerchallenge setting in keycloak and have keycloak verify the LDAP password, and have privacyIDEA verify a PIN and the OTP/PUSH.

The use case would be a two step authentication utilizing more than a single instance of two factors.
1st Step: User initiates authentication using user store credentials
2nd Step: User is challenged to provide their PIN+OTP.

In the event that a user’s user store credentials and OTP device are compromised, requiring the PIN with OTP can possibly mitigate unauthorized access.

A password and a PIN are the same type of factor, ‘something you know’, but that doesn’t mean having one cancels the need/want for the other.

Yes, but then we don’t have the 2-step challenge that integrates the use of user store credentials in the first step.

Hi,

We configure keycloak to use triggerchallenges so that we can use TOTP and webauthn tokens concurrently. The triggerchallenge is triggered by a dedicated account and not by sending the user credentials to privacyidea. Before all this, keycloak has verified the username/password of the user in some other way (LDAP bind, kerberos, …).

I don’t fully understand why there is a difference between validating a TOTP token in a single step vs 2-step.

Giving the user the option to add a small additional protection by configuring a PIN for his/her TOTP token sound like a good idea. It would be an additional barrier to overcome for an attacker.

Regards,
Rik

I am really wondering, why any of you is using triggerchallenge in the first place, since you actually can do what you so desperately want - without using triggerchallenge.

How does authentication at keycloak work

Obviously authentication at keycloaks works like this:

  1. The user is authenticated with username and ldap password in the first step by keycloaks own ldap component.

  2. If the ldap password was correct, the privacyIDEA plugin is called. By default this plugin does nothing, simply waiting for a user input.

  3. The user inputs his OTP-PIN (static).

  4. The PIN is sent to privacyIDEA. A challenge is created and sent back to the keycloak privacyIDEA plugin.

  5. The user answers the challenge - e.g. with his Webauthn token. If you configured TOTP into this policy the workflow for TOTP-Tokens is completely the same.

Er voila: A user authenticates with LDAP-Password, PIN and OTP-Value or WebAuthn.

Now, ordinary people do not like this. They do not want to use LDAP-Password and PIN. But there is this nasty step #3, which is necessary, since otherwise no webauthn challenge would be triggered. Since privacyIDEA can not know, that a user is about to log in. So what to do now?

Only use triggerchallenge if you know what you are doing

This is where triggerchallenge comes into play. It is only to avoid the step #3! This is the only original reason for triggerchallenge! Really. Honestly.

So the authentication at the keycloak will look like this:

  1. The user is authenticated with username and ldap password in the first step by keycloaks own ldap component.

  2. If the ldap password was correct, the privacyIDEA plugin is called.

  3. Before asking the user for an input, the plugin sends a triggerchallenge request to privacyIDEA for the user, who is about to log in.

  4. A challenge is created and sent back to the keycloak privacyIDEA plugin.

  5. The user answers the challenge - e.g. with his Webauthn token. If you configured TOTP into this policy the workflow for TOTP-Tokens is completely the same.

So you see: No PIN! Because it was the intention to get rid of the PIN.

Consider these rule of thumb privacyidea is following

  1. Try to keep all plugins easy - or should I say dumb. So if you come up with any kind of special use case, which you think is quite logical, but honestly is special, it will most probably be turned down, because maintaining a lot of plugins with all quirks and switches sucks.

  2. All logics should be in the backend.

  3. Enrolling tokens in a plugin is a bad idea.

  4. Read the complete documentation and suggest very concrete improvements. Only telling the documentation is not precise enough, does not count. Which information would be missing at which point?

  5. Consider getting professional help.

Further readings