Skip to main content
There is one sign-in page, at /login, and it works out which kind of credential you are typing.

Staff

Email and password. Operator admins, organisation admins and supervisors. Issues a session that lasts twelve hours.

Agents

Extension and PIN. The people taking calls, at the start of a shift.
The sign-in page

How it knows which you are

By the shape of what you type. An agent’s address is their extension — digits before the @ — with a PIN that is digits. A staff address has letters before the @ and a password. The secret field follows the address: as soon as it looks like an extension, the box becomes a numeric PIN. A numeric address with a secret that is not digits is neither, and almost certainly an agent who typed something other than their PIN. The page says so rather than sending a request that could not have succeeded — which would only spend the PIN limiter’s budget.
There were two pages once, /staff and /login, each explaining why it did not link to the other. /staff still redirects, because the address is in bookmarks and handover notes.

Two doors behind one page

The two API endpoints are still separate and must be: a PIN and a password are very differently sized secrets, and each has its own rate limiter. A run of wrong guesses at one cannot spend the budget defending the other. Nothing about that required two pages.

Signing in as an agent

An agent signs in with the address their handset already registers with:
A bare extension number works where the address you are visiting already names the tenant. The organisation is resolved from the SIP domain before any extension is looked up — extension numbers are not unique across tenants, and there is deliberately no falling back to “some other organisation’s 1001”.
Every way of getting it wrong returns the same message — extension or PIN is incorrect — and takes the same amount of time. A form that said “no such extension” would tell an attacker which numbers exist.
If your PIN has been set for you and must be changed, the first sign-in takes you straight to a change-PIN page.
Agent PIN sign-in requires the server to be configured with a PIN pepper. If it is not, the endpoint answers PIN login is not configured rather than hashing without one. See installing FireTone.

Forgot your password

Forgot password? under the password field emails you a link to choose a new one. It works once, for an hour. The page answers the same whether or not the address has an account, so it cannot be used to find out who does. Choosing a new password, from the link or in Settings → You → Password, signs you out everywhere else. The browser you changed it in stays signed in. Extension and PIN sign-ins have no password: ask your administrator for a new PIN.

Invitations

An administrator adding somebody in Settings → People & access emails them an invitation by default. The link works for 7 days and lets them choose their own password, so nobody else ever knows it. Email a link to set their password on an existing login sends a new one.

Two-step sign-in

With two-step sign-in, a correct password is not enough: a six-digit code is emailed to you, and you type it in. It works for 10 minutes. After five wrong tries you sign in again for a new code. Send a new code is there if it does not arrive.
  • Turn it on for yourself in Settings → You → Two-step sign-in. It asks for your current password, whether you turn it on or off.
  • The operator can require it, for operator admins or for everybody who signs in with a password (Settings → Email → Brand). It then cannot be turned off per person.
  • Remember this browser for 30 days skips the code on that browser, for your address only. Turning two-step sign-in off, or resetting your password, forgets every remembered browser.
Extension and PIN sign-in never asks for a code.
If email breaks while the code is required, nobody can sign in with a password. On the server, firetonectl mfa-off --policy lifts the requirement, and firetonectl mfa-off <email> switches off one person’s own setting.