Syncplify.me Server v8

Appearance

Passkeys (WebAuthn) ​

Syncplify Server! supports passkeys, the industry standard passwordless sign in method built on WebAuthn (FIDO2). A passkey is a cryptographic credential stored on the user's device (a phone, a laptop with a fingerprint reader or face unlock, or a hardware security key) that signs a server issued challenge instead of transmitting any secret. This page explains where passkeys apply, how they interact with two factor authentication, how credentials are bound to host names, and how they behave in a high availability cluster.

Where passkeys apply ​

Passkeys can be used by all three account types, each on its own login page:

  • SuperAdmins sign into the SuperAdmin UI.
  • Admins sign into the Admin UI of their virtual site. Admin passkeys are scoped to one virtual site, so the virtual site must be entered on the login page before the passkey button becomes active.
  • Users sign into the WebClient. Passkeys are available to normal users and to OIDC users. LDAP and SAML users cannot enroll passkeys, because their authentication is delegated entirely to the directory or identity provider, and a local passkey would keep working even after the account is disabled on the directory side.

Passkeys are available in every edition of the product; no specific license tier is required.

How signing in works ​

Every login page shows a "Sign in with a passkey" button when the browser supports WebAuthn. Passkeys are enrolled as discoverable credentials, so the user does not need to type a username first: the browser lists the matching passkeys for the site, the user picks one, unlocks it with the device screen lock (PIN, fingerprint, or face) or with a hardware security key, and is signed in. All the usual account checks still run on every passkey login: account status, allow lists, protocol permissions, connection limits, and scripted authentication events for WebClient users.

Passkeys and two factor authentication ​

Every passkey ceremony in Syncplify Server! requires user verification, which means the authenticator itself must confirm the user's identity with a PIN or a biometric before it signs the challenge. A verified passkey is therefore inherently two factor: something the user has (the device holding the key) plus something the user knows or is (the PIN or the biometric). For this reason a successful passkey login does not ask for a TOTP one time code, even when the account has an authenticator app enrolled or is required to use MFA. Password logins are unaffected and keep their usual second factor behavior.

Host name binding ​

A passkey is cryptographically bound to the host name (the WebAuthn relying party ID) it was created on. A passkey enrolled on files.example.com works on that host only; if the same virtual site is also reachable as transfer.example.com, a separate passkey must be enrolled there. Keep this in mind when you plan bindings and additional host names for your virtual sites, and when you migrate a deployment to a new domain: after a host name change users must enroll new passkeys and can keep signing in with their password in the meantime.

Enrollment and management ​

Each account manages its own passkeys from its settings page:

  • SuperAdmins: SuperAdmin UI, Settings, Security tab.
  • Admins: Admin UI, Settings, Security tab.
  • Users: WebClient, Settings, Authentication tab.

Every account can hold up to 10 passkeys, and each one can be named, renamed, and deleted. Administrators additionally have oversight:

  • Admins can review and revoke any user's passkeys from the user editor.
  • SuperAdmins can review and revoke any Admin's passkeys through the REST API.

Revoking a passkey takes effect immediately: the next login attempt with the revoked credential is denied. Passkeys are never the only credential on an account; password (or SSO) sign in always remains available, so a lost device never locks anyone out.

Security properties ​

  • The private key never leaves the user's device or security key; the server stores only the public key.
  • Nothing that is typed or stored on the server can be phished or replayed: each login signs a fresh, single use challenge, valid for five minutes.
  • Credentials are bound to the exact host name and origin, which defeats lookalike domain phishing.
  • The server verifies the authenticator's signature counter and rejects logins that look like a cloned credential.
  • No personal information is stored on the authenticator; the account reference kept on the device is an opaque salted hash.

High availability ​

Passkey credentials and in flight ceremony state are stored in the shared database, so in an HA cluster a login can begin on one node and complete on another without any special configuration.

Browser support ​

Passkeys work in all current versions of Chrome, Edge, Safari, and Firefox, on Windows, macOS, Linux, Android, and iOS. On browsers without WebAuthn support the passkey button and the enrollment section are simply hidden, and password or SSO sign in works as usual.