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 appsettings.production.ini file;

• duration of the locked state, as defined in the parameter LockoutDuration in the following format d.hh:mm:ss, where:

  • 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 UNLOCK button.

Administrator's view of the autolocked account.

The users in HQ role can see the status of the account, but can not remove the autolock:

HQ-user's view of the autolocked account.

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 --username or --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.