Just wondering if there are any settings that would be restricting an IP address with a token-based survey?

When accessing the survey link and entering a token, it is coming up with this error and won't allow survey access for 10 minutes. It also blocks the ability to sign into the admin panel.
This is with 40 PCs all connected via the same IP, so it seems like it's not allowing multiple connections from the same IP?
There were no attempts to sign into the admin panel when the errors start, just multiple users entering unique tokens on the token page (no duplicate tokens).

I tried connecting via a different IP address and it works fine, but switching back to the original IP the error comes up again.

I can confirm that the latest updates have all been applied as of this morning but the error still occurs. Screenshots are attached.

Thanks in advance.

Just wondering if there are any settings that would be restricting an IP address with a token-based survey?

LimeSurvey has a simple protection against brute-force. If you use LimeSurvey in a group (e.g. classroom), it's not uncommon to trigger that brute-force protection.But there is no way to control and manage that via the GUI.

There is currently no indication that LimeSurvey will offer a GUI to control and manage the brute-force behaviour.
github.com/LimeSurvey/LimeSurvey/commit/...cb0be67d829b34b750fa

You haven't mentioned what LimeSurvey version you use.

You can override bruteforce settings in the config file.

Compare with the defaults

// If the user enters password incorrectly
$config    = 3; // Lock them out after 3 attempts
$config        = 60 * 10; // Lock them out for 10 minutes.

github.com/LimeSurvey/LimeSurvey/blob/ma.../config-defaults.php

I'm not aware of more settings, but perhaps there are some undocumented for token as well.
 

Thank you for this. We have managed to find these settings and have increased the number of attempts to 10 and the lock out time to 1*10 (10 seconds).
We've been using Limesurvey for years but only just now encountering this issue, and found that for some reason the number of attempts was set to 1.
I'll see if this helps, but will there be any issues with setting this to a large number such as 1000 attempts to ensure that it doesn't appear again?

Limesurvey Version 3.25.22+210413

It's a new system since github.com/LimeSurvey/LimeSurvey/commit/...6eb8be7a81da5e614617

It use same system for admin and token.

Like all Brute force attack : it's always possible …
With 10 seconds : i think it's OK for all bots (even 1 seconds is OK for bots).
If you need more securisation for admin : you muts choose complex password.

Maybe have 2 separate settings for timing here can be a good idea ?

Maybe have 2 separate settings for timing here can be a good idea ?

A GUI is needed to allow unblocking and excluding IPs from Blocks.
I wonder if the SaaS version of LimeSurvey has that system activated.
The IP logging/storing has to be indicated in the data protection policy. What is the retention? It can be relevant for the admin to know.

wrote:

Maybe have 2 separate settings for timing here can be a good idea ?

A GUI is needed to allow unblocking and excluding IPs from Blocks.

IP spoofing is so easy !

wrote:

I wonder if the SaaS version of LimeSurvey has that system activated.
The IP logging/storing has to be indicated in the data protection policy. What is the retention? It can be relevant for the admin to know.
 

Not sure : it's used only for technical and security issue.

IP spoofing is so easy !

Everything is easy till you do it. And it's no argument to no offering such an option in the backend.
Because if spoofing is so easy and constantly done in the real word, the bruteforce system as implemented in LimeSurvey will allow people to constantly lock you out of your own system with no effort.

Right

PS : i think we must create an username block, not an IP block for brute force.

PS : i think we must create an username block, not an IP block for brute force.

So that I don't even need to spoof the IP, but directly block you via username. That will always result in an option to exclude certain user names. If not, you have a DoS easily implemented.

Currently LimeSurvey is not having many multiuser setups and is not important enough, to be a toptarget by attacked (in comparism to e,g. backends of WordPress or cPanel).

LimeSurvey SaaS will not enable such featues for sure. The support system will be having a DDoS too.

wrote:

PS : i think we must create an username block, not an IP block for brute force.

So that I don't even need to spoof the IP, but directly block you via username. That will always result in an option to exclude certain user names. If not, you have a DoS easily implemented.

 

I prefer too know someone try to hack my data .

I didn't want to have it activated everywhere, but i think some instance need it. Know you have an attack is always better .
AFA is a good solution for admin part and can be a good solution for token part too (depend on usage).

But here : like i already sayd : it's not related : i already say i think it's a bad idea to use an existing system for another syste.
I think admin brute force protection and token bruteforce protection must have different options.