To protect the safety of the data and prevent disruptions to the operations due to hacker attacks, the system responds to attempts to guess a user’s password.
In the normal state, the user needs to enter just the login name and password to access the system. If, however, she makes multiple attempts to log in with an incorrect password, the system raises to the elevated state.
To log in in the elevated state the user needs to supply her login name, password, and additionally solve a CAPTCHA challenge. Read more about CAPTCHAs.
If the user enters multiple wrong combinations of user names and passwords in the elevated state, the system passes to the locked state, where the user with this name cannot log in for the predefined duration of time.
The parameters of this defensive strategy are:
the number of attempts before transition from normal to elevated state is fixed at 5;
the number of attempts before transition from elevated to locked state is defined in MaxFailedAccessAttemptsBeforeLockout parameter in the Authentication section of
duration of the locked state, as defined in the parameter LockoutDuration in the following format
- d is days (assumed 0 if omitted);
- hh two digits for hours (mandatory);
- mm two digits for minutes (mandatory);
- ss two digits for seconds (mandatory).
The exact values of these parameters are up to the security expert to determine.
Note that the counters of incorrect login attempts and locking are on the per user basis. For example, if the accounts of users John and Mary are locked, users Peter and Irene may still be able to log in.
Note also that when autolock gets activated, this doesn’t disable the user that has already logged in.
System administrators should not rely solely on these CAPTCHA and autolock features to ensure the safety of their data. They should use the time of the automatic lockout to trace the IP addresses from which the attack is being staged to disable further communication with them, and apply all other tools available to them to prevent unauthorized access to the collected data.
Releasing the autolock by the administrators using the UI
The Survey Solutions administrator can release the autolock that has been
engaged from the user’s profile by pressing the
The users in HQ role can see the status of the account, but can not remove the autolock:
Releasing the autolock from console
To release the autolock that has already engaged before it expires automatically requires OS-access to the server where Survey Solutions is installed. This maintenance can be performed by the person who installed Survey Solutions.
We will need to run the command:
releaselock with parameters
--login. For example:
.\WB.UI.Headquarters.exe manage users releaselock --login loginName
You need to run this command while in the directory where the file
WB.UI.Headquarters.exe is located.