General Security

General Security lets you configure security policies for registration, sign-in, password reset, and multi-factor authentication, including Registration Protection, Verification Security, Password Security, and Access Restrictions. All settings apply only to the current application.

Path: Sign in to the RootAuth Console → select the target application → click Configuration in the top navigation → Security Settings → General Security.

 

 

1. Registration Protection

Registration Protection reduces risks such as duplicate registrations and disposable-email registrations. It applies to email registration.

1.1 Check Google Email Uniqueness

When Check Google email uniqueness is enabled, RootAuth treats dot and plus aliases for the same Google inbox as the same email address, preventing users from registering repeatedly with different aliases. This option is disabled by default.

• It applies only to gmail.com and googlemail.com email addresses.
• The system ignores dots before @ and ignores + aliases and everything following them.
• For example, name@gmail.com, na.me@gmail.com, and name+test@gmail.com are recognized as the same email address.

 

1.2 Block Disposable Email Registration

When Block registration with disposable email domains is enabled, the system blocks registration attempts made with temporary or disposable email addresses. This option is enabled by default.

You can choose either of the following detection methods, or select both:

Detection method	When to use it
Use the RootAuth disposable email database	Selected by default. RootAuth blocks registrations based on its built-in disposable email domain database.
Use a custom disposable email domain blacklist	Blocks registrations using the domain list maintained for the current application. Use it to add temporary email domains identified by your organization.

After selecting a custom blacklist, add domains in Email Domain Blacklist. You can add domains individually or in batches. At least one valid domain is required before you can save.

• @example.com: Matches only the example.com domain.
• .example.com: Matches example.com and all of its subdomains.

 

2. Verification Security

2.1 Human Verification

Human verification identifies automated requests across registration, sign-in, password reset, and multi-factor authentication. With Users must always complete human verification before sending verification codes and submitting information permanently enabled, users must complete human verification before they can request a verification code or submit related authentication information.

Under Verification Service, select a provider that suits your deployment region and business needs:

Verification service	Available modes	Configuration guidance
Tencent Cloud Mainland China	Slider verification, non-intrusive verification	The default service. Suitable when most application requests originate in mainland China.
Tencent Cloud International	Slider verification, non-intrusive verification	Suitable for overseas deployments. Select a service node based on the region where your application requests originate.
Cloudflare Turnstile	Managed, non-interactive, invisible	Create a Turnstile widget in the Cloudflare dashboard, then enter the corresponding Site Key and Secret Key.

 

2.2 Configure Cloudflare Turnstile

1. Create a Turnstile widget in the Cloudflare dashboard that matches the selected verification mode.
2. For Managed or Non-interactive, configure separate credentials for Verification before requesting a code and Information submission verification. Information submission verification always uses Invisible mode.
3. For Invisible, create one invisible-mode widget and enter one set of Site Key and Secret Key.
4. Return to RootAuth, enter the credentials, and save the configuration.

Only one human verification service can be enabled at a time. After switching services, make sure the required verification mode and credentials for the selected service are fully configured.

 

2.3 Verification Code Rules

Verification code rules apply to email and SMS numeric codes used in registration, sign-in, password reset, and multi-factor authentication. Email and SMS codes use the same set of rules.

Setting	Default value	Available range and behavior
Code length	6 digits	Choose 4 or 6 digits. Newly generated verification codes contain numbers only.
Code validity period	10 minutes	Set from 1 to 30 minutes. A code expires after the selected period, counted from when it is generated successfully.
Resend interval	60 seconds	Set from 30 to 300 seconds. Users must wait before requesting another code; after a new code is sent successfully, the previous code expires immediately.
Code attempt limit	3 attempts	Set from 1 to 10 attempts. Once the maximum is exceeded, the current code expires and the user must request a new one.

After you save, new rules apply to subsequently generated verification codes and do not affect codes that have already been sent.

 

3. Password Security

Password Security lets you standardize validation rules for registration, sign-in, password changes, and password resets that use a password.

3.1 Password Length and Format

• Password length: Set the minimum and maximum password length. The default minimum is 8 characters and the default maximum is 20 characters. You can set values from 8 to 32 characters, and the maximum cannot be lower than the minimum.
• Password rule: Choose Must contain uppercase and lowercase letters and numbers (default), Must contain letters and numbers, or Do not validate password format.

 

3.2 Password Change Verification

Under Password Change Verification, choose whether users must verify their current password when changing it. The default is Require current password verification. If your application implements a specific flow through the API, you can choose Do not require the current password.

 

3.3 Password Reset Policy

Under Password Reset Verification, choose whether a new password can match the current password. By default, matching the current password is not allowed, which prevents users from retaining their existing password after a reset. Choose to allow it only when required by your business scenario.

 

4. Access Restrictions

Access Restrictions limit users from registering or signing in according to the country or region resolved from the request IP address.

4.1 Enable Country or Region Restrictions

1. Enable Country or Region Restrictions.
2. Search for and select the countries or regions to restrict in Countries or Regions Prohibited from Access. The list supports multiple selection and clearing. At least one option is required before you can save when restrictions are enabled.
3. Select Other to also restrict IP addresses whose source cannot be identified.
4. Under Restricted Scenarios, select Registration and/or Sign-in. Both are selected by default, and at least one scenario must remain selected.
5. Click Save to apply the rule.

Users from restricted countries or regions cannot continue the selected registration or sign-in flow. Multi-factor authentication is not a separate restricted scenario: users blocked at sign-in do not proceed to MFA after sign-in.

Rule priority: IP blacklist > country or region restriction > other risk policies.

 

5. Save and Verify

• All sections on this page use the Save and Reset buttons at the bottom of the page. We recommend saving after completing all changes.
• After saving, verify the configuration through your application's registration, sign-in, or password-reset flow. For example, register with a restricted email domain, request a verification code, or sign in from a restricted region.
• When multiple policies are enabled, the system applies them according to their priority. Consider all enabled security policies when testing a single feature.