> For AI agents: the complete documentation index is available at https://www.jumpserver.com/docs/v4/llms.txt, the full documentation bundle is available at https://www.jumpserver.com/docs/v4/llms-full.txt.

# Authentication security

This topic introduces configuration parameters for user authentication security.


1

In the right area of the top navigation bar, click .

![image](/docs/images/docs/navs/nav-settings.png)

2

In the left menu, click **<Icon name="Security" /> Security**.

3

On the right page, click **Auth security** tab.

## Basic

This section introduces the user login configurations.

### Login CAPTCHA

`recommended`

Login CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) can effectively prevent brute-force attacks by malicious programs.

Once enabled, if a user fails to log in, any subsequent login attempts from the same IP within the next hour will require entering a CAPTCHA.


Note

Once enabled, the [Login dynamic code](#login-dynamic-code) and [MFA in login page](#mfa-in-login-page) will be disabled.

### Login dynamic code

Login dynamic code is concatenated with the user’s password and sent together to the authentication service for verification.

For example, if the user’s password is "passwd" and the dynamic code is "1234", the system will send "passwd1234" as the password to the backend authentication service during login.

This method is commonly used in scenarios such as RADIUS authentication.


Note

Once enabled, the [Login CAPTCHA](#login-captcha) and [MFA in login page](#mfa-in-login-page) will be disabled.

### Auto disable threshold (day)

`required`

Default: `999` Min: `30` Max: `99999`

Automatically disabled users.

Users who have not logged in for more than the configured days will be automatically disabled.

For more information about enabling users, see [Enable or disable users](https://www.jumpserver.com/docs/v4/users/enable-disable-users.md).

### Suspicious login verification

Remote login alert.

If a user has not logged in from the city of their most recent login within the past 7 days, the system will send a remote login alert through the user’s enabled message channels (e.g., in-site notifications, email, etc.).

## MFA

This section introduces the MFA configurations.

### Global MFA

Global MFA can be applied to all users at once, eliminating the need to configure it for each user individually, which simplifies administration.

- Not enabled

  Global MFA is disabled, but users can enable it from their profile page.

- All users

  Global MFA is enabled for all users and cannot be disabled by individual users.

- Only admin users

  Global MFA is enabled for admin users (including users with `System Admin` or `Organization Admin` roles) and cannot be disabled by them. Regular users can enable or disable it from their profile page.


Tip

If you have enabled global MFA but are unable to log in, you can run the following command to disable it.
```
docker exec -it jms_core bash
cd apps/
python manage.py shell
```
```
from settings.models import Setting
s = Setting.objects.get(name="SECURITY_MFA_AUTH")
s.value = 0
s.save()
```

### MFA in login page

Effective only when "Global MFA" is enabled and "All users" is selected.

Once enabled, users will see the MFA code on the login page and can enter it together with their password for one-time verification.

If a user has not yet enabled MFA, they do not need to enter the MFA code on the login page. After the username and password are successfully verified, the system will guide the user through the MFA setup process.


Note

Once enabled, the [Login CAPTCHA](#login-captcha) and [Login dynamic code](#login-dynamic-code) will be disabled.

### MFA via email

Email can be used as an MFA authentication method. When users enable MFA and log in, they can choose to receive the MFA code via Email to complete verification.


Tip

Administrators must configure the Email service in advance. For more information, see [Email service configuration guide](https://www.jumpserver.com/docs/v4/notifications/email.md).

### Third-party login MFA

MFA can be enforced for users authenticated via third-party login methods. This applies mainly to redirection-based logins and QR code logins.

| Authentication Method | Controlled by this setting |
| :-------------------- | :------------------------: |
| AD/LDAP               |             ✖️             |
| CAS                   |             ✔️             |
| Passkey               |             ✖️             |
| AD/LDAP HA            |             ✖️             |
| OIDC                  |             ✔️             |
| SAML2                 |             ✔️             |
| OAuth2                |             ✔️             |
| WeCom                 |             ✔️             |
| Dingtalk              |             ✔️             |
| FeiShu                |             ✔️             |
| Lark                  |             ✔️             |
| Slack                 |             ✔️             |
| RADIUS                |             ✖️             |

Users logging in through other authentication methods, like local users, can directly enable and use MFA.

### MFA verify TTL

`required`

Default: `3600` (seconds)

When an administrator views an asset account’s secret, the system requires MFA verification by default. This setting controls the validity period of the verification, with a default value of 3600 seconds. Within this period, subsequent secret views do not require repeated MFA verification.

For more information about disabling MFA verification when viewing account secrets, see [SECURITY_VIEW_AUTH_NEED_MFA](https://www.jumpserver.com/docs/v4/configuration.md#security_view_auth_need_mfa).

### OTP issuer name

Default: `JumpServer`

When a user binds MFA, this field specifies the name of the service or application generating the OTP, helping the user distinguish codes from different services within their OTP app.

### OTP valid window

`required`

Default: `2` Min: `0` Max: `10`

This setting controls the valid time window for one-time passwords (OTP). A new OTP is typically generated every 30 seconds, and to accommodate network delays or user input lag, the system allows OTPs from a few previous and subsequent time steps to remain valid.

If set to 2, the system accepts codes from the current, previous 2, and next 2 time steps.

If set to 0, only the current code is valid.
