Passwords & Policy covers how you change your own password, how an admin resets someone else's, how passwords are stored, and the strength, reuse, and expiry rules every password must pass.

Overview

Every password-based sign-in goes through the same policy engine, whether it's set at account creation, a self-service change, an admin reset, or a forced update. The platform never stores or displays a password in a recoverable form, so the only ways to recover access are a self-service change, the forgot-password link, or an admin reset. Strength, history, and minimum-age checks are customizable per app or tenant, so the specifics you see may be tighter than the defaults described here.

Use Cases

• Let users change their own password from their account without involving an admin.

• Give admins a way to get a locked-out user back in without knowing their old password.

• Enforce a consistent minimum password strength across every place a password gets set.

• Prevent users from cycling back to an old, possibly compromised password.

• Force a password change on a defined schedule or after a security event.

Changing Your Own Password

Use Change Password on your own row in the users table, or on your own user page. Fill in Current Password, New Password, and Confirm New Password — a mismatch shows "Passwords do not match". The platform first re-verifies your current password (a wrong one fails with "Invalid username or password"), then runs the new password through the full policy — strength, history, and minimum age — before saving. On success: "Password changed successfully".

Note: the option only exists if you sign in with a password — SSO users manage their password with their identity provider. Changing your own password does not sign you out of your other sessions; only an admin reset or a forgot-password reset does that.

Resetting Another User's Password

Use Reset Password on their row — it requires the dedicated Reset Password permission on users, and it's hidden on your own row. Set a New Password and Confirm New Password: "Make sure to keep a copy of this password as you will need to provide it to the user." The password must pass the same strength rules and the reuse check against the user's recent passwords. On success: "Password reset successfully. You can now provide the password to the user so they can log in with it."

Note: resetting a password has two immediate side effects — every one of the user's active sessions ends on the spot, and the account is flagged so the user is forced to set a new password at their next login. The minimum-age rule is skipped for admin resets, so you can reset even if the user changed their own password minutes ago.

How Passwords Are Stored

No one — including platform admins — can see or recover a password. Passwords are never stored or logged in plain text: each one is run through a slow, industry-standard one-way key-derivation function with a unique random salt per password, and only the resulting hash is kept. Verification at login recomputes the hash and compares it. A small history of previous password hashes (not the passwords themselves) is kept solely to enforce the no-reuse rule. If a password is lost, the only options are the Forgot password? link or an admin Reset Password — there is no "reveal password".

Password Strength Rules

By default a password must:

• Be 8–64 characters long.

• Include uppercase, lowercase, a digit, and a special character (for example @$!%*?&).

• Avoid sequences, such as abc or 123.

• Avoid repeating any character more than twice, such as aaa or 1111.

• Not contain your username or the service name.

An empty password is rejected outright with "Password can not be null or empty." A weak password is rejected with "Password is too weak. It must: …", listing exactly which rules failed, ending with "Choose a stronger password to proceed."

The rule set is customizable per app or tenant in the application's security settings. Admins pick which checks apply — lowercase letters, uppercase letters, numbers, special characters, preventing common passwords (the sequence/repeat check), and preventing user information (the username/service-name check) — and can set their own minimum and maximum length, which changes the error text accordingly (for example, "Be 10–32 characters long."). All of these checks run everywhere a password is set: creating a user, Change Password, Reset Password, the forced Update Password page, and the forgot-password reset link.

Reuse and Minimum Age

Recent passwords are remembered and rejected: "Reusing any of your last {N} passwords is not permitted. Please choose a new and unique password." The history size is 3 by default and configurable per app; the list includes your current password, so "changing" to the same password always fails. The reuse check applies to every path that sets a password — even an admin doing a Reset Password can't set one of the user's recent passwords.

There can also be a minimum password age, in days, off by default (0 days): changing again too soon fails with "Password was changed recently. Please try again later." The minimum age never blocks an admin reset or a forced first-login/expiry change — only ordinary self-service changes.

Forced Password Updates

After signing in you may land on Update Password: "Please update your password as this is your first time signing in." This happens when the account is flagged for a mandatory change, which occurs when:

• It's your first login — users created from the Users screen with an admin-entered password are flagged automatically (users created by an automation are flagged only if the automation chose to require it).

• An admin reset your password.

• Your password expired — passwords expire 90 days after they were last changed by default; the period is configurable per app, and the clock restarts at every change.

Your credentials are still fully checked first — the forced update only appears after a correct password. While the flag is set, every screen bounces you back to Update Password until you complete it. Enter Password and Confirm Password and click Submit — the new password must pass all policy rules. On success: "Your password has been updated successfully! Redirecting you now…" — all of your sessions end and you sign in once more with the new password.

Change vs. Reset vs. Forgot Password

All three run the same strength and reuse checks.

Notes

A few habits keep password policy effective without becoming a support burden:

• Set a reasonable expiry period rather than relying on the 90-day default alone if your compliance needs differ.

• Use Reset Password, not Change Password, when helping a locked-out user — it doesn't require their old password.

• Tell users the one-time password from a reset must be changed at next login, so it isn't a surprise.

• Tune the strength rule set per app rather than leaving every tenant on the same defaults if requirements differ.

• Point SSO users to their identity provider for password changes — the platform's password screens don't apply to them.

Consistent password policy is one of the simplest controls you have against account compromise — worth getting right once and leaving alone.