x

Main chapters

  1. LimeSurvey Cloud vs LimeSurvey CE
  2. LimeSurvey Cloud - Quick start guide
  3. LimeSurvey CE - Installation
  4. How to design a good survey (Guide)
  5. Getting started
  6. LimeSurvey configuration
  7. Introduction - Surveys
  8. View survey settings
  9. View survey menu
  10. View survey structure
  11. Introduction - Questions
  12. Introduction - Question Groups
  13. Introduction - Surveys - Management
  14. Survey toolbar options
  15. Multilingual survey
  16. Quick start guide - ExpressionScript
  17. Advanced features
  18. General FAQ
  19. Troubleshooting
  20. Workarounds
  21. License
  22. Version change log
  23. Plugins - Advanced
 Actions

AuthDB plugin

From LimeSurvey Manual

AuthDB ("LimeSurvey internal database") is the default authentication method for the LimeSurvey administration interface: administrators log in with a username and password stored directly in LimeSurvey's own database, rather than through an external system such as LDAP, a web server login, or an OAuth provider.

  AuthDB is a core plugin that is always active and cannot be deactivated. It is the fallback authentication method LimeSurvey relies on, so unlike other core plugins there is no "activate" step and no switch to turn it off in Plugin Manager.


How passwords are stored

Passwords are never stored in plain text. They are hashed using PHP's standard password hashing function, which currently produces a bcrypt hash. If an account still has a password from a much older LimeSurvey version (stored with a legacy, weaker hash), that account can still log in normally — LimeSurvey recognizes the old format, and the password is automatically re-hashed to the current, stronger format the next time that user logs in successfully. No administrator action or forced password reset is needed for this upgrade to happen.

Restricting which users may use it

Every user account has an Use internal database authentication permission. This lets an administrator prevent a specific account from logging in with a username/password combination at all — for example, to require that a given administrator only logs in through LDAP or single sign-on instead. This permission cannot be removed from the built-in superadministrator account (user ID 1).

Each user account can also have an Expiry date/time set (in User Management). Once this date/time has passed, the account can no longer log in via AuthDB, regardless of a correct password. This is an account-expiry setting, not a password-expiry setting — it does not force periodic password changes.

Password requirements

AuthDB itself does not enforce any password complexity rules. Password requirements are configured separately, in the PasswordRequirement core plugin's settings (Configuration -> Plugin manager -> PasswordRequirement -> Settings), which offers separate rules for:

  • Password requirements for administration login: require at least one digit, require at least one uppercase character, require at least one special character, and a minimum password length (12 characters if left blank).
  • Password requirements for "Save and return later" (the password respondents can set to resume an incomplete survey later): the same set of rules, each off by default, with its own minimum length (8 characters if left blank).

Protection against repeated login attempts

Repeated failed login attempts are throttled globally, independently of which authentication method is used. This is configured under Configuration -> Global settings -> Security, with separate settings for the administration login and for survey participants:

  • IP allowlist: IP addresses excluded from the attempt limit entirely.
  • Maximum number of attempts: how many failed attempts are allowed before an IP address is temporarily blocked (default 3; leave empty to disable this protection).
  • Lockout time in seconds (after maximum number of attempts): how long an IP address stays blocked once the limit is reached (default 600 seconds; leave empty or 0 to disable).

The same three settings exist a second time under Brute-force protection for survey participation, for the front-end survey token/password screen, along with a Reset participant attempts button. Blocking is based on the visitor's IP address, not on the specific username being tried.

  If the AuditLog plugin is active with its "Log if a user login has failed" setting enabled, a failed login is also recorded there. This is a separate, independent mechanism from the lockout described above — disabling AuditLog does not disable the lockout, and changing the lockout settings does not affect what AuditLog records.