[BUG] autolock_time user error

[devion01]

Hello multiOTP,

how is autolock updated?
In our environment, the first users were no longer able to log in after 6 months.
After a lot of research, we found out that autolock had blocked the respective users. However, these users logged in every day.
Hence my question: how does the value (autolock) come about and how is it updated?

Best regard
devion01

[multiOTP]

Hello,

Please check the logs to see why the user has been autolocked. Most of the time, it's because somebody tried to connect several times with this account with a bad username/password.

Number of successive fail attempts and temporay lock duration can be set in the configuration

Regards,

[devion01]

Hello,

It was not a system autolock, but rather the epoch (timestamp) had expired. This locked out all users who had used HOTP for the first time six months ago. Normally, the epoch should be updated automatically. Unfortunately, I do not know why this was not the case here. Once the stamp was renewed, users were able to log in again.

Regards

[multiOTP]

Hello,
Good to hear that it was just an epoch timestamp issue. There is perhaps not enough rights on the files in order to authorize the system to update the stamps. Regards.

[devion01]

Since the system does not do this automatically, we had to update the epoch manually. How can we check or incorporate this point?

[multiOTP]

Hello,
Which timestamp was not updated correctly ? Which entry/ies in which file(s) ?
What are the rights on the files ?
Are you running on Windows or Linux ?
Regards,

[devion01]

Hello,

My MultiOTP instance runs on a Docker container with the Linux Ubuntu operating system.

In the “User.db” file (e.g., “Max.Mustermann.db”), the “autolock_time” timestamp is not automatically updated.
This triggers the following scenario.

The permission is set to 6 for everyone.

multiotp-database-format-v3
algorithm=totp
attributed_tokens=
autolock_time=1748088892
cache_level=1
cache_lifetime=15552000