Two-step verification
Ask for a second step after the password (an authenticator app, a passkey, or an emailed or texted code), and require it of everyone in your organization.
Two-step verification adds a second step after the password. It applies to every way of signing in: password, "Continue with Google or GitHub", and the sign-in you get after resetting a password. (Single sign-on relies on your identity provider's own second step.)
The ways to answer
| Way | Strength | Notes |
|---|---|---|
| Authenticator app | strong | A 6-digit code from 1Password, Authy, Google Authenticator and the like. |
| Passkey | strong | A security key, or the fingerprint or face unlock on your own device. Several allowed. Needs a browser that supports passkeys. |
| Emailed code | weaker | A 6-digit code to your confirmed email address. Only as safe as the mailbox a password reset would also go to. |
| Texted code | weaker | A 6-digit code to your phone number. Not available on every account. The account page says when it is not. |
| Recovery codes | for emergencies | Ten single-use codes, made when you first turn on a strong way. |
Set them up in Settings, Account, Two-step verification. Only the two strong ways satisfy an organization that requires two-step verification; emailed and texted codes satisfy your own sign-in only.
Codes expire after 10 minutes, work once, and are rate limited (a new one at most every 30 seconds and five an hour). Five wrong answers of any kind lock the second step for 15 minutes.
Remember this device
When you answer the second step you can tick Remember this device for 30 days. That browser then skips the second step when you sign in with your password. It is dropped if you turn two-step verification off or an owner resets it, and you can forget every remembered device from your account. A remembered device does not count as having just answered a second step: the changes below still ask.
Sensitive changes ask again
Even when signed in, these ask for a fresh answer (from the last ten minutes) before they go ahead: creating or revoking an API key, changing or removing a member, requiring two-step verification, resetting a member's second step, removing a passkey, and changing single sign-on. The dashboard opens a prompt, you answer, and the change continues. An API key is not asked: it is a machine credential with no second step.
Requiring it of your organization
An owner can switch on Settings, Security, Require two-step verification. The owner must have a strong way set up first, so the policy cannot lock them out. From then on a member without one can still sign in, but can reach only their account settings, the list of their organizations, and sign-out, until they set one up. That takes effect for people already signed in, within about 15 seconds. A person cannot turn it off while an organization they belong to requires it.
Security notices
Dialgem emails the account's confirmed address whenever a way is added or removed, recovery codes are made or used, or an owner resets it, so a change you did not make is noticed.
When someone loses their phone
With their recovery codes they can sign in and set up again. Without them:
- An owner can remove that member's second step from Settings, Members (the shield icon). That also signs the member out everywhere and forgets their remembered devices.
- Otherwise Dialgem support can reset it after confirming who is asking.
Both are written to the audit log (or the staff log).
Two-step verification, and texted codes in particular, may not be available on every account. The account page says so when something is not available.
Signing in with a passkey and no password
On the Account page choose Add one for passwordless sign-in. Such a passkey must be stored on the device (a "discoverable" credential) and the device must check it is you (PIN, fingerprint or face) every time. On the sign-in page, Sign in with a passkey then needs no email or password, and counts as the second step too, so nothing asks again. A passkey added the ordinary way remains a second step only and cannot replace the password. Five failed attempts lock the second step for 15 minutes, a copied authenticator is noticed by its counter, and an organization that requires single sign-on still turns passkey sign-in away for people at its domains (owners excepted).
What it does not do
- API keys are not affected. Limit what they can do with scopes and an address allowlist.
- It protects signing in and the changes above, not every action in a session that is already open.