Skip to content

Password policy

This page helps you choose the rule every new password must meet.

Password policy under Admin, General applies whenever a password is set: on the registration, activation and reset forms, under Account, Change password, when an administrator creates a user or gives one a new password, through the Admin and Account APIs, and in the recover command. Every page that takes a new password shows the rule under the field, and a refused password is told which rule it broke.

  1. In the admin console, open Admin, General.

  2. Under Password policy, choose a card. NIST SP 800-63B comes first, and it’s the one we recommend.

  3. Click Save. The next password each user sets is held to it. Passwords already set aren’t checked again: see what switching does.

Policy API value At least Also
NIST SP 800-63B nist 15 characters Any characters at all, with no kind required. A commonly used password is refused, and so is one too close to the account’s details or the app’s name.
No policy none 1 character Nothing
Low low 6 characters Nothing
Medium medium 8 characters A lowercase letter, an uppercase letter and a number
High high 10 characters A lowercase letter, an uppercase letter, a number and a symbol

Every policy accepts at most 72 bytes, the most bcrypt hashes. A character outside ASCII takes two to four of them. Each Unicode code point counts as one character toward the minimum.

The other four policies fall short of NIST SP 800-63B, and their cards say so. They’re for an installation that must require kinds of character. Choosing one is a departure from the guideline you make on purpose.

The general settings API sends and takes the policy as passwordPolicy, with the values above. See PUT /api/v1/admin/settings/general.

Setting Default
Password policy NIST SP 800-63B (nist in the API)

The first administrator’s password always meets the NIST rule, whatever the policy: see GOIABADA_ADMIN_PASSWORD.

NIST SP 800-63B is the US National Institute of Standards and Technology’s guideline for how people sign in. The nist policy follows its fourth revision, SP 800-63B-4, section 3.1.1.2, for a password that may be the only thing a sign-in checks:

  • Length. At least 15 characters, each Unicode code point counting as one. Length is what makes a password hard to guess.
  • No composition rules. The verifier “SHALL NOT impose other composition rules”, such as asking for an uppercase letter, a digit or a symbol. They make a password harder to remember without making it harder to guess: people answer them with Password1!.
  • A blocklist. Every new password is compared against a list of commonly used, expected or compromised passwords. “The entire password SHALL be subject to comparison, not substrings or words that might be contained therein.”
  • Guidance and a reason. The verifier offers guidance on choosing a strong password, and gives the reason when it refuses one.
  • No forced changes on a schedule. Goiabada never expires a password. When you know one was compromised, give the user a new one, as what switching does shows.

Goiabada has no password hints and no security questions, which the guideline forbids too.

Under nist, a password on a built-in list of commonly used passwords is refused. The list is the 16,043 passwords of 15 characters or more, and at most 72 bytes, in three public lists, lowercased and with duplicates removed:

List License
The UK National Cyber Security Centre’s 100,000 most used passwords, drawn from Have I Been Pwned’s Pwned Passwords Crown copyright, under the Open Government Licence v3.0; Pwned Passwords under CC BY 4.0
Pwdb’s 1,000,000 most common passwords (2020) MIT
The 1,000,000 most common of xato’s ten million passwords (2015) MIT

All three come from SecLists, under the MIT license. The list is built into the auth server and the setup wizard, so checking a password makes no network call and works on an installation with no internet access.

The whole password is compared with each entry, ignoring case, so passwordpassword and PasswordPassword are refused, while a passphrase that merely contains a listed password isn’t. Shorter common passwords aren’t on the list, since the 15-character minimum already refuses them.

Under nist, a password is also refused when it’s the account’s email address, the part before the @, the username or the app name, or one of those written twice or more, or padded with digits, symbols or spaces at either end. Case is ignored. For [email protected], with the username janedoe, in an app named Goiabada, these are all refused:

  • [email protected]
  • jane.doe2026!!!!!!
  • JaneDoeJaneDoe2026
  • goiabada2026!!!!!
  • GoiabadaGoiabada

A passphrase that merely contains one of them, such as jane likes long walks, isn’t.

NIST SP 800-63B-4 allows a minimum of 8 characters for a password that’s only ever used beside a second factor. No policy here does, because no password here is known never to be the only factor: a client at urn:goiabada:level1 signs in with the password alone, urn:goiabada:level2_optional skips the code for a user without two-factor authentication, and the password grant checks nothing else. See ACR and AMR.

The nist policy meets the section’s SHALLs for choosing a password. It departs from two of its SHOULDs:

  • The maximum is 72 bytes, not 64 characters. The guideline says the verifier “SHOULD permit a maximum password length of at least 64 characters”. bcrypt hashes at most 72 bytes, so that’s the limit: 72 characters of ASCII, 36 of Cyrillic, Greek, Arabic or Hebrew, 24 of Chinese, Japanese or Korean, or 18 emoji. A user writing in Japanese has between 15 and 24 characters to work with.
  • Passwords aren’t normalized. The guideline says “the verifier SHOULD apply the normalization process for stabilized strings using the Normalization Form Canonical Composition (NFC)”. Goiabada counts, checks and hashes the characters as typed, so café typed with a precomposed é and typed with an e and a combining accent are two different passwords. Most keyboards type the same form each time, but a password typed on one device may not sign in on another.

Switching policy, to nist or any other, holds the next password each user sets to it. Passwords already set aren’t checked again: sign-in compares the password with its hash and judges nothing, so nobody is stopped, prompted or flagged for a password an earlier policy accepted. That’s what the guideline asks too: it applies its rules when a password is set or changed, and forbids forcing changes on a schedule.

To give a user a password that meets the new policy, open Admin, Users, the user, and their Authentication tab, and use New password.