Title: PrivacyIDEA Requests OTP Even When the Windows Password Is Incorrect
Problem Description
I am using PrivacyIDEA for two-factor authentication (2FA) at Windows sign-in. The current authentication flow prompts the user to enter their username and password, followed by a one-time password (OTP).
However, I have noticed a security-related issue: even when the user enters an incorrect Windows password, PrivacyIDEA still prompts them to enter the OTP.
Expected Behaviour
The authentication process should validate the primary password first. If the password is incorrect, the login attempt should be rejected immediately, with an appropriate error message such as “Incorrect username or password.” The user should not be prompted to enter an OTP.
Only after the primary credentials have been successfully validated should the system proceed to the OTP verification stage.
Actual Behaviour
The user enters their username and password at the Windows sign-in screen.
Even if the password is incorrect, the system proceeds to the OTP prompt.
The user is asked to enter the OTP despite the primary authentication having failed.
Security Concern
This behaviour may cause confusion about the authentication flow and could expose unnecessary information about the configured authentication mechanism. I would like to ensure that the authentication process follows the intended sequence and that the second-factor prompt is presented only after successful primary authentication, where supported by the Windows integration and authentication configuration.
Questions
Is this expected behaviour with the PrivacyIDEA Windows Credential Provider?
Is there a configuration option to validate the Windows password before displaying the OTP prompt?
Could this behaviour be related to the Windows Credential Provider configuration, the authentication backend, or the selected authentication mode?
What is the recommended configuration to achieve this authentication flow securely?
Any guidance or documentation on how to configure this correctly would be appreciated.
yes, it is. There are many ways how the credential provider can communicate with the privacyIDEA server and how the privacyIDEA server handles the authentication flow.
You are probably looking for “challenge response”.
Either two_step_send_password or two_step_send_empty_password.
However, you also need to set C/R for your HOTP or TOTP tokens in the backend.
Well, some people might argue that verifying the windows password in the first step and failing in case of a wrong windows password is less secure, since it allows brute force on the passwort (or account locking) without the knowledge/possession of the second factor.
But this is nothing I am here to discuss.
Just configure it the way you like.
Thank you for the clarification and for pointing me toward the challenge-response configuration.
In our use case, we want the Windows sign-in process to validate the user’s primary Windows credentials first. If the username or password is incorrect, authentication should fail immediately with an appropriate error message, and the user should not be prompted to enter an OTP. Only after successful primary authentication should the process proceed to the second-factor verification.
I understand the concern that validating the password first could allow password-only brute-force attempts or trigger account lockouts without requiring the second factor. However, our objective is to ensure that an invalid primary password is rejected before the OTP stage, so that the authentication flow behaves as intended and provides clear feedback to the user.
Could you please provide the recommended configuration for the privacyIDEA Credential Provider and the privacyIDEA server to achieve this behaviour? Specifically, it would be helpful to know how to configure two_step_send_password or two_step_send_empty_password, along with the required challenge-response settings for HOTP/TOTP tokens.
If there are any additional Windows Credential Provider settings or authentication policies required, please share those as well.