Passkeys, MFA and single sign-on in an end-to-end encrypted product
Signing in has two jobs in Sapherbox: proving who you are, and opening your keys on your device. How passwords, a second factor, passkeys and Entra ID each handle both.
In most cloud products, signing in is one act. You prove who you are, the server believes you, and it shows you your data, which it could read all along.
In an end-to-end encrypted product, signing in is two acts. The first is the familiar one: convincing the server that this request comes from you. The second has no equivalent elsewhere: opening your keys on your device, because the server holds your files only as ciphertext and cannot open them for you. A sign-in method that does only the first leaves you with an account and nothing you can read.
Every way of signing in to Sapherbox therefore has to answer two questions. How does the server know it is you? And what opens your keys? This article walks through the four answers: passwords, a second factor, passkeys and single sign-on.
What has to be opened
Briefly, so the rest makes sense. When you register, your browser creates a random 256-bit Account Master Key. Your identity keys, the private halves that unwrap every file, folder and group key you have access to, are stored encrypted under that master key. The server keeps the locked master key and the locked identity keys, never the open ones.
So every sign-in method ends in the same place: something on your device has to unlock the master key. Everything after that is identical, whichever way you came in.
Passwords: one secret, two jobs, kept apart
A password is the oldest answer to both questions, and the risky part is that it answers both. If the same secret proves who you are to the server and also opens your keys, then the server, simply by checking it, learns what it needs to open your keys.
Sapherbox keeps the two jobs apart on your device. Your browser runs your password through Argon2id, a deliberately slow function that turns it into a key. That key unlocks your master key and never leaves your device. From it, your browser derives a second value in one direction only, the login key, and that is what the server receives. The server stores a hash of the login key and compares against it, like any password check.
The direction matters. The login key can be computed from the unlocking key, but not the other way round. A server that sees every login key, or a database that leaks every hash, gives an attacker nothing that opens a master key. To get there they would have to guess your password and pay Argon2id’s cost for every guess.
Accounts created before this scheme switch over by themselves: at the next sign-in the browser sends the password one last time, the server replaces the stored hash with one of the login key, and from then on the password stays on the device. This applies to sign-ins in the browser. The desktop sync client and the macOS app do not use the scheme yet; until they do, signing in there sends the password to the server over the encrypted connection.
Administrators can set a password policy (length, character classes, maximum age, no reuse of recent passwords) and an account lockout after a number of failed attempts. Because the server no longer sees the password, the browser checks the policy before it derives anything. The lockout counts failures on the server as before.
A second factor guards the account, not the keys
Administrators can require a second factor for everyone; anyone who has not set one up is taken through the setup at their next sign-in. The factor is a time-based one-time code (TOTP) from an authenticator app, entered after the password.
It is worth being precise about what the code protects. To check a code, the server has to know the secret behind it. A secret the server knows cannot protect anything from the server, so the code has no part in opening your keys. What it does is stop someone who has your password, from a phishing page or a reused password elsewhere, from signing in as you. That is a real and common threat, and it is the one a second factor exists for.
The one-time code applies to password sign-ins. Passkeys and single sign-on bring their own second factor, as the next two sections explain.
Passkeys: signing in and unlocking with one touch
A passkey is a key pair held by your device: the secure chip in a laptop or phone, unlocked with your fingerprint, face or device PIN, or a hardware security key. Signing in with it means your device signs a fresh challenge from the server; the server checks the signature against the public key it stored when you added the passkey. There is no secret to type, so there is nothing to phish, and a passkey only ever answers to the site it was created for.
That settles the first question. For the second, Sapherbox uses an extension of the passkey standard called PRF. Besides the signature, the authenticator can produce a secret value that is bound to that one passkey and that one site, and that only the authenticator can compute. Your browser turns that value into a key and uses it to wrap your master key, exactly as your password-derived key does. The server stores this additional locked box next to the others.
At sign-in, one touch does both jobs: the signature proves it is you, and the PRF value unlocks your master key on the device. What you end up with is the same session as after a password sign-in, down to the last key. Your master key opens the same identity keys, including the post-quantum ML-KEM key and your signing key, so a passkey session can unwrap and share everything a password session can.
A few practical points:
- You add passkeys after signing in. Registering one requires your master key to be open, so it happens from your preferences, once you are in. Adding one asks your device twice: once to create the passkey, once to produce the PRF value.
- Your authenticator needs PRF support. Current platform authenticators such as Touch ID and Face ID, Windows Hello and hardware keys like the YubiKey 5 series support it in current browsers. If yours does not, Sapherbox tells you when you try to add it.
- A lost passkey is not a lost account. Remove it from your preferences; your password, any other passkey and your recovery code still unlock your master key.
Single sign-on: Microsoft proves who you are, but holds no key
Many organisations want people to sign in with the account they already have. Sapherbox supports single sign-on with Microsoft Entra ID through OpenID Connect. Your browser is sent to Microsoft, you sign in there, and Microsoft sends back a signed statement of who you are. Whatever your organisation enforces in Entra, its multi-factor rules and conditional access policies, applies to that step.
That answers the first question. It cannot answer the second, and deliberately so. If the keys that open your files were derived from your Microsoft sign-in, then anyone who can sign in as you at Microsoft could open your files. That includes an Entra administrator who resets your password, and Microsoft itself. Single sign-on would quietly hand the keys to a second party, which is exactly what end-to-end encryption is meant to prevent.
So after the Microsoft sign-in, Sapherbox asks for a vault passphrase. It plays the role a password plays for everyone else: your browser turns it into a key with Argon2id, and that key unlocks your master key. The passphrase never leaves the browser, not even as a login key, because Microsoft has already done the proving. The first time you sign in through single sign-on, you choose the passphrase and receive a recovery code, as in a normal registration. If you already had a password account with the same address, your existing password unlocks the vault the first time and becomes your passphrase from then on.
On a device where you have added a passkey, the passkey can stand in for the passphrase: Microsoft proves who you are, the passkey opens your keys.
What no sign-in method can do
Each method can let you in. None of them lets anyone else open your files: not the server, not Microsoft, not us. The table puts the four side by side.
| Sign-in method | How the server knows it is you | What opens your keys on the device | What the server holds |
|---|---|---|---|
| Password | Login key derived from the password | Argon2id key from the password | Hash of the login key, master key locked under the password |
| Password + one-time code | Login key, then the code | Same as password | As above, plus the code secret |
| Passkey | Signature from the passkey | PRF value from the passkey | Public key, master key locked under the PRF value |
| Entra ID | Microsoft’s signed statement | Vault passphrase, or a passkey | Your Entra identity, master key locked under the passphrase |
The flip side is the one every end-to-end product has: if every way of opening your master key is gone, no sign-in method can bring it back. That is what the recovery code is for, and for organisations the escrow key they hold themselves. We have described both in Password reset without a provider backdoor.
Questions?
If your security team wants to know how a particular sign-in method fits your policies, or wants the technical description behind this article, get in touch at hello@sapherbox.com.