Enforcing Complex Passwords

When you create or update a user account, you can require the user to create strong (complex) passwords. Complex passwords are enabled by default when you create a Site using the "strict security settings" option. (If you also want to create anonymous accounts, refer to Anonymous User Accounts.)

EFT login security controls do not apply to SAML (Web SSO) failed logins. Password complexity and failed logins are within the responsibility of the IdP and are not controlled by EFT.

To require accounts use complex passwords

  1. In the administration interface, connect to EFT and click the Server tab.

  2. On the Server tab, click the Site, Settings Template, or user that you want to configure, then click the Security tab.

  3. Select the Enforce strong (complex) passwords check box, and then click Configure. The Password complexity settings dialog box appears.

  4. Refer to the guidelines in the table below:

    5. Field

    Default

    Min/Max Values

    Minimum password length - Specify the minimum number of characters that must be in the password

    8

    6 - 99

    In the Character categories area, specify the type of characters that must be in the password:

    The password must contain characters from at least N of the following categories:

    • Uppercase

    • Lowercase

    • Numeric (0-9)

    • Non alpha-numeric (e.g., !, #, $, %)

    • Non-4-bit ASCII characters

    3 categories

    2 categories, up to the maximum password length

    Must not contain N or more characters from the user name

    3

    2 characters, up to maximum password length

    Must not contain N or more repeating characters.

    3

    2 characters, up to maximum password length

    Must not consist solely of a word in the following Dictionary file.

    (Click the ellipse icon  to select a file.)

    on

    n/a

    Must not be a dictionary word backwards

    off

    n/a

  5. Click OK to save the settings or Cancel to keep existing settings.

  6. Click Apply to save the changes to EFT.

For example, suppose you specified that the password must:

  • contain at least 6 characters

  • contain uppercase letters

  • contain lowercase letters

  • contain numbers

That means that the password must contain at least one uppercase character, at least one lowercase character, and at least one digit. So in this case, a password could be A5s3*v35, but not a5s3*v35, because you specified that a password should have at least one uppercase letter.

  • PCI DSS requirements include minimum password lengths, complexity, and reuse rules.

  • The dictionary file cannot exceed 10 MB. If you exceed the file size, the Event log will indicate that not all of the file could be loaded. If the dictionary file is not available, EFT operations will continue and a log error is written to the Event log.

  • Non-alphanumeric characters are not required by default; you must explicitly specify this option if you want to require it. For those who might be using a non-English language operating system, it is best to leave the Non alpha-numeric check box cleared because of characters that are not normally found on a standard keyboard. In this case, your users are free to use non-alphanumeric characters when they create their own password, you just would not require that they do, and the system will not include them when you automatically generate a complex password.

  • COM-created accounts are not subject to complexity requirements unless the CreateComplexPassword method is used. Refer to the API Reference for details.

  • When checking against the user's account name, several characters are treated as delimiters that separate the name into individual tokens: commas, periods, dashes/hyphens, underscores, spaces, pound signs, and tabs. For each token that is three or more characters long, that token is searched for in the password; if it is present, the password change is rejected. For example, the name "Erin M. Hagens" would be split into three tokens: "Erin", "M", and "Hagens". Because the second token is only one character long, it would be ignored. Therefore, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password. All of these checks are case-insensitive.