[BUG] Wrong shared secret will not impact OTP authentication (cache issue ?)

[yankaiqian]

I tried with a wrong shared secret in windows credentialProvider, it still work, checked the logs, there are additional 3 lines error log.
is it by design?

2026-01-28 14:03:16 error Client-Server Error: Host answers with the following error code: 70 (INFO: Requested operation successfully done) 0 ComputerName
2026-01-28 14:03:16 error Client-Server Error: Host answers with the following error code: 70 (INFO: Requested operation successfully done) 0 ComputerName
2026-01-28 14:03:16 error Client-Server Error: Host answers with the following error code: 70 (INFO: Requested operation successfully done) 0 ComputerName
2026-01-28 14:03:16 notice simba User OK: User simba successfully logged in with TOTP token 0 ComputerName

[multiOTP]

Hello @yankaiqian,
If you have already logged successfully on the machine and you have authorized local cache, you have an internal cache on the machine.
If now you change the shared secret, the credential Provider cannot connect to the multiOTP server anymore, but the local cache is still working.
If you don't want offer cache, you can disable it on server side (directly in the multiotp.ini file server_cache_level=0, or with the commande line multiotp -config server-cache-level=0
Regards,

[yankaiqian]

Got it, but I also found the auth OK logs in server when I tried it with wrong secret, so even it is authenticated with internal cache, it will also trigger logs in server end, right?

I know the cache auth, and I think the cache auth function is a very good feature, forgot this when I did debugging.
But I'm a little confused, why can I see the successful authentication logs on the server side when performing cache authentication (with wrong secret) ?

[multiOTP]

Hello @yankaiqian,
We are doing various tests about this, and we will keep you in touch.
Rergards,