This article explains how the Linux Password Policy works in Swif, how password entropy is enforced, and what each setting in the policy does.

The Linux Password Policy in Swif lets you define and enforce password rules on Linux devices.

This policy is designed to align with enterprise best practices and customer requirements such as Navarik’s request to meet minimum password entropy guidance from Apache Infra.

The following sections describe each setting in the Linux Password Policy using the display names shown in the Swif admin UI.

Defines the minimum number of characters a password must have.

Recommendation: Use at least 12 characters, especially for admin or high‑risk accounts.

Sets the minimum number of numeric characters (0–9) required in each password.

Sets the minimum number of uppercase letters (A–Z) required in the password.

Sets the minimum number of lowercase letters (a–z) required in the password.

Sets the minimum number of special characters required.
Examples include: ! @ # $ % ^ & * ( ) _ + and other non‑alphanumeric characters.

Requiring at least one special character significantly increases password complexity.

Defines how many character positions must be different from the previous password.

Example:
If this is set to 4, the user’s new password must differ from the old one in at least four character positions, preventing very small changes like appending 1 to an old password.

Defines how many different character groups must appear in a password. Character classes are:

Example:
If set to 3, the password must contain characters from at least three of these four groups (for example, lowercase + uppercase + digits).

Limits how many times the same character can appear in a row.

Example:

This helps avoid weak patterns like long sequences of the same character.

Limits how many characters from the same character class can appear consecutively.

Example:

This prevents long runs of the same type of character and encourages mixed‑type passwords.

When turned on, Swif checks the password against the user’s personal information stored in GECOS fields (for example, full name, contact info).

If the password contains straightforward pieces of this personal information, it can be rejected. This prevents easily guessable passwords like including your first or last name.

When turned on, passwords are checked against a dictionary file of disallowed words (for example, common or weak passwords such as password, qwerty, letmein).

If this option is enabled, you will see an additional setting:

Specifies the file path to the dictionary that Swif uses when checking passwords. You can provide a custom dictionary that contains:

When turned on, passwords are checked to ensure they do not contain the username.

Often combined with Username Substring to fine‑tune how strict this check is.

Defines the length of username substrings to look for inside the password.

Example:

Swif will check every 3‑character segment (nav, ava, var, ari, and so on) and can reject passwords that contain them, making it harder to build passwords directly from the username.

Sets the maximum number of failed attempts allowed before an account is locked, according to your PAM and lockout configuration.

Typical practice: 3–5 retries to protect against brute‑force attempts while remaining reasonable for users.

Controls whether all the above password rules (length, complexity, entropy‑related checks, etc.) are also enforced for root users.

Recommendation: Turn this on in most environments to make sure highly privileged accounts meet your strongest standards.

These settings control how long passwords are valid and when users are warned to change them.

Specifies the maximum number of days a password can be used before the user is required to change it.

Defines the minimum number of days that must pass before a user is allowed to change their password again.

This prevents users from quickly cycling through multiple password changes to get back to an older password.

Defines how many days before expiry users are warned about their upcoming password expiration.

Example:

Controls whether Maximum Days, Minimum Days, and Warn Age Days also apply to the root user.

Enables password history so users cannot reuse a number of their previous passwords.

If this option is enabled, an additional setting appears:

Defines how many of the user’s last passwords are remembered and blocked from reuse.

Example:

When a user changes a password on a Linux device managed by Swif:

To align with common enterprise and Apache Infra‑style guidance, consider the following starting point: