Reset or change a password¶

Three ways to set a password, from the everyday one to the one for when nobody can sign in at all. All three enforce the same password policy.

You are…	Use
Signed in, changing your own password	Change my password on the Access page
A super admin, resetting somebody else's	Reset password on their row
Locked out — the super admin's password is lost	`cyphers-hub reset-password`, as root on the Hub host

There is no "forgot my password" link and no e-mail reset: the Hub runs on your network and sends no mail. A lost password is recovered by someone with more authority than the account — a super admin in the dashboard, or root on the Hub host.

The password policy¶

Length does the work. There are no "one digit, one symbol" rules and passwords never expire — both push people toward worse passwords, and current NIST guidance (SP 800-63B) drops them. The Hub has no second factor and this login controls a certificate authority, so the minimum is long:

Rule	Value
Minimum length	15 characters. Spaces are allowed; a short sentence of four or five words is long enough.
Maximum length	128 characters
Composition	None required — no mandatory digits, capitals or symbols
Username	The password must not contain the username
Variety	At least 5 different characters (`aaaaaaaaaaaaaaab` is not a password)
Common patterns	Refused when the whole password is built from common passwords, product words, keyboard runs and digits — `Password123456789`, `qwertyqwertyqwerty1`, `CyphersAdmin2026!!`. Any word of your own makes it pass.
Expiry	None. Change a password when you suspect it is known, not on a calendar.

Every form states the policy, checks length, the username and the confirmation as you type, and keeps its button disabled until the request could succeed. When the Hub still refuses — the common-pattern rule needs its word list — it lists every broken rule at once, each with a suggestion.

The policy applies when a password is set, never at sign-in: passwords that predate it keep working until they are next changed.

Change your own password¶

Access → Change my password. Any signed-in user can do this; it needs no user-management permission.

Enter your current password. A session someone else walked up to is not enough to change it.
Enter the new password twice. It must differ from the current one.
Change password.

Your other sessions — other browsers, other machines — are signed out. The one you made the change from stays signed in. A wrong current password changes nothing and raises the same alert a failed sign-in does.

Reset another user's password¶

Access → the user's row → Reset password. Super admins only.

Enter the new password twice and confirm. The user is signed out everywhere and signs in again with the new password — pass it to them out of band, and have them change it with Change my password straight away.

An Automation identity has no Reset control: it drives the API with a key and never signs in, so it has no password, and the Hub refuses to give it one (no_login_identity).

A lost super admin password: reset from the Hub host¶

If the only super admin is locked out, nothing in the dashboard can help — only a super admin resets passwords. (create-admin is not a way round it either: it grants super admin to the first user only.) Recovery is a command on the Hub host, run as root.

Native install¶

sudo sh -c 'set -a; . /opt/cyphers/.env; exec /opt/cyphers/cyphers-hub \
  --installation-config /etc/cyphers/installation.toml \
  reset-password --username admin'

Docker package¶

docker compose exec -u 0 hub cyphers-hub \
  --installation-config /etc/cyphers/installation.toml \
  reset-password --username admin

The command prints the policy, asks for the new password twice (three tries), and confirms:

Password reset for admin. Every session of that user was ended.

The Hub does not need to be stopped or restarted.

There is no --password flag, on purpose: a flag lands in shell history and in the process list. For automation, pipe one line on stdin instead.
Forgot the username too? Run it with any name; the refusal lists the super admins on this Hub.
An Automation identity is refused here as well.

Who can run it¶

The command refuses to run unless it is root. That check is a guardrail, not the lock. The lock is the database credential: /opt/cyphers/.env is readable only by root and the cyphers service account, and on Docker, access to the Docker socket is already root on that host. Whoever can reach the database with its password owns every login in it — so protect that file and that host, and treat this command as what it is: the system administrator's way back in.

What it leaves behind¶

A host reset is deliberately loud:

an audit record, user_password_reset, actor cli:root, naming the user;
a warning on the Activity page — The password for "admin" was reset from the Hub host command line — which a running Hub shows within five minutes and sends to your notification hook.

A reset from the dashboard writes the same audit record with the super admin who did it as the actor; a self-service change writes user_password_changed. The password itself is never recorded anywhere.

Failed sign-ins raise an alert¶

Every failed sign-in is recorded (login_failed) and raised as a warning on the Activity page and, at the default notification threshold, to your notification hook:

Failed login for "admin" from 203.0.113.9

The event carries the username that was tried, the source address, the time, and — for you, never for the caller — whether that user exists. Accounts are not locked: a lockout lets anyone who knows a username lock its owner out. Sign-in attempts are rate-limited per source address instead.

First install¶

ADMIN_PASSWORD (Docker) and create-admin --password (native) are held to the same policy. On Docker, a non-compliant ADMIN_PASSWORD stops the container on first start with the broken rules in docker compose logs hub, rather than starting a Hub nobody can sign in to. An existing install is not affected: once the admin exists, the bootstrap password is never read again.