Mitigate bruteforce attempts

[Antoine-Gicquel]

Hi,
I have seen past issues about this topic, which have all been disregarded because "if an attacker has access to the SoftHSM library, he could also access the filesystem and loot the token file, to try and bruteforce locally".

However, as a QubesOS user, I use extensively SoftHSM in combination with socat, so that my SoftHSM server is on a virtual machine with all my certificates (a vault VM), and my clients (for instance a Firefox process) are all in other VMs, with no direct access to the vault's file system. In such cases, I feel it makes the most sense to implement a kind of rate limiting in SoftHSM as it would drastically reduce the bruteforce pace of an attacker in a client VM. The way I implemented it is very trivial, feel free to make it cleaner or to tell me what to do in order to make it so.
By default, when no configuration option is added to the config file, it does not change the behavior of SoftHSM (no delay on failed attempts). However, if you add the login.fail_delay (here again, the name might not be in line with the configuration options naming scheme, feel free to tell me about it) in your config file, the value of the option you provided (in seconds) will be waited on a failed attempt.

Feel free to reach out if you have any question, or to make any modification to the code of this PR.

Best regards,
Antoine

[Antoine-Gicquel]

I guess these checks are broken x) The project should build perfectly, and has been tested on Debian 11.

Also to add on my initial post : I think it doesn't cost much to merge this PR, and it can help raise the security level of SoftHSM in some use-cases (not all cases, I hear you).