SyFly security whitepaper

Summary

SyFly is a password manager built on end-to-end encryption. Everything you store is encrypted on your own device, with keys that come from your master password, before it is sent anywhere. Our servers store and sync locked data only and never receive a key that could open it.

• Vault data is encrypted with AES-256-GCM on the device; keys are random 256-bit keys.
• The key that opens your vault is locked with a key made from your master password with PBKDF2-HMAC-SHA256 and 1,000,000 iterations.
• Sharing locks a copy of the item's key for each recipient with RSA-OAEP 4096.
• Sign-in is separate from unlocking: the account password, a second step and lockouts protect the account, and only the master password, the recovery key or Face Key open the vault.

Design goals

• The server can't read your vault. A copy of everything we store, taken by an attacker or handed over by law, contains no readable passwords, notes or files.
• One master password, many keys. Every container, item, repository and group has its own key, so sharing one thing never exposes another.
• Nothing is guessed. Every encrypted value is sealed: data that was changed or doesn't open is refused, never shown.
• The same everywhere. Web, browser extensions, desktop and mobile use the same formats and are tested against the same shared test cases.
• Recoverable by you only. If you forget your master password, your recovery key or Face Key gets you back in. SyFly can't.

Threat model

What SyFly protects against

• Someone who gets a copy of our database or backups: they find encrypted data only.
• Someone at SyFly, or anyone with access to our servers: no key that opens your vault ever reaches them.
• Someone who learns your account password: without your master password, the vault stays locked, and a second step is asked at sign-in.
• Password guessing: lockouts and limits stop online guessing; 1,000,000 PBKDF2 iterations slow down guessing against a stolen copy.
• Tampering with stored data: altered values fail to open and are refused.
• Someone you share with: they receive only what you shared, never the keys to anything else.
• Someone on the network: every connection uses TLS, and the data inside is encrypted again on the device.

What SyFly can't protect against

• A device that is already compromised: malware that reads the screen or the keyboard while your vault is unlocked sees what you see.
• A weak or reused master password: if it can be guessed, a stolen copy of your encrypted vault can be opened. Use a long passphrase you don't use elsewhere.
• Someone who has your master password, your account password and your second step together.
• The code of the web app: it is sent by our server each time you open it, so you trust that server to send the genuine app. The browser extensions, desktop and mobile apps carry their code with them.
• What the service needs to run: your email, who you share with, when you sign in, and how much you store are visible to us, though never the content.

Where things run

• Your device (web app, browser extensions, desktop and mobile apps): What it does: Makes and holds the keys, encrypts and decrypts everything, checks Face Key, talks to security keys
• SyFly servers: What it does: Store and sync encrypted data, check sign-in, send codes and alerts, enforce limits and lockouts
• Outside services: What it does: Hosting, payments, email and text messages, listed with what each receives on the Transparency page

Keys and encryption

Every locked key is sealed to its owner and to what it protects, so it can't be reused for anything else or by another user. Before a new key is sent, the device checks that it opens again. A rewrite of a key is refused if another device changed that key in the meantime, so a newer key is never replaced by an older one.

The full details are on the Encryption page.

• Key from your master password: How it is made: PBKDF2-HMAC-SHA256, 1,000,000 iterations for new accounts (the apps refuse fewer than 600,000), a random 16-byte salt per account, 256-bit output; What it locks: Your account key
• Account key: How it is made: Random 256-bit key made on your device; What it locks: Your private key and your own copy of every key below
• Key pair: How it is made: RSA-4096; the public key is readable by others, the private key is locked under the account key; What it locks: Keys other people share with you
• Container, repository, group and item keys: How it is made: Random 256-bit keys, one per container, repository, group and item; What it locks: The content inside them
• Recovery key: How it is made: 32 random bytes you save (52 characters); What it locks: A second copy of your account key
• Face Key: How it is made: Recovered from your face on your device, plus a server part given out after your email code and PIN; What it locks: A copy of your account key for that device
• Locking keys and data: Algorithm: AES-256-GCM with a random 96-bit IV for every value and a 128-bit authentication tag
• Keys derived from a key: Algorithm: HKDF-SHA256, a separate key for each purpose
• Sharing: Algorithm: RSA-OAEP with 4096-bit keys and SHA-256
• Container passphrases and answers: Algorithm: PBKDF2-HMAC-SHA256 with a random salt per copy, then AES-256-GCM
• Security keys: Algorithm: FIDO2 hmac-secret (WebAuthn PRF), then HKDF-SHA256 and AES-256-GCM
• Account password: Algorithm: bcrypt, checked on the server; it never opens the vault
• Connections: Algorithm: TLS

Sign-in and sessions

• Two passwords. The account password signs you in and is stored only as a bcrypt hash. The master password opens the vault and never leaves your device.
• A second step. A code by email or text message, an authenticator app, or a hardware security key, with one-time backup codes.
• Sign in with Google, Apple or your organization. Single sign-on proves who you are; your master password still opens the vault.
• Lockouts. After several wrong attempts, sign-in and unlock pause for 15 minutes, counted across all our servers, and repeated requests are rate-limited.
• Sessions. On the web, the session is kept in a cookie that page scripts can't read. A device unused for 30 days is signed out.
• Up-to-date apps only. An app too old for the current security rules is asked to update before it can sign in.

Unlocking and recovery

Changing or resetting the master password is a single step: your device re-locks your account key, your recovery copy and every key tied to the master password, and the server saves all of it or none of it. SyFly can't reset your master password or open your vault for you.

• Master password: What happens on your device: Makes the key that opens your account key, then your private key
• Recovery key: What happens on your device: Opens its copy of your account key; you then choose a new master password
• Face Key: What happens on your device: Your face, your email code and your PIN open the copy of your account key kept for Face Key
• Open session: What happens on your device: Reuses the keys kept for the session until it ends

Containers with their own lock

A container can be locked with your master password, its own passphrase, or a security key such as a YubiKey. With a passphrase, its key is sealed with PBKDF2 and AES-256-GCM; with a security key, with a secret only the physical key can produce (FIDO2 hmac-secret). One container can open with any of your registered keys, up to 10 per account. SyFly never receives these secrets.

Sharing

• People. Your device locks a copy of the item's key with each recipient's public key. The recipient's device opens it with their private key and re-locks it under their own account key.
• Single items. An item shared from a container gets its own key, so the person never receives the container's key.
• Passphrase and security-key containers. You choose each recipient's secret: a passphrase, a security key you give them, or the answer to a question. Each copy is bound to its recipient.
• Groups. A group has its own key, locked for each member. Items shared with a group are locked once for all members.
• Organizations. Members, groups and shared spaces, with single sign-on for organizations that use it.
• Backup person. Their copy is locked with a passphrase or security key you choose and released only after your inactivity period ends or you approve their request.
• New keys and removing access. When someone gets a new key pair, your device locks fresh copies for them the next time you unlock. Removing someone deletes their copy.

Face Key

Face Key signs you in and opens your vault by recognising your face on your own device; no photo or face template is uploaded. A sign-in needs four things together: your face, an email code, your PIN, and a server part that is given out only after the code and the PIN. Two anti-spoofing models check every capture. In testing, no stranger was accepted out of 8,348 photos, and a stolen copy of our data plus a photo of the owner opened 0 of 120,720 attempts.

The models, error rates and limits are on the Face Key page.

On your device

• While unlocked, keys are kept for the session, encrypted (web) or in the system keychain (desktop, mobile), and removed when you log out or the session ends.
• The web app locks after 15 minutes without activity, the browser extension after 30 minutes or when the screen locks. On the web, a copied password is cleared from the clipboard after 45 seconds.
• Files are encrypted on the device before upload.
• AutoFill on iOS, Android and macOS uses a sealed local copy of the keys you opened, protected by the system keychain, and never stores the master password.

On our servers

Where data is stored and which outside services are used are on the Transparency page.

• A web application firewall filters requests before they reach the application.
• App pages run with a strict content security policy: no inline or injected scripts, and no analytics or advertising scripts.
• Limits, lockouts and blocks against abuse are shared across all servers, and blocks target a single device rather than a whole network where possible.
• Security events, such as sign-in attempts and blocked requests, are logged and alert our team.

Known limits

• There is no way yet to replace your account key itself. Changing your master password re-locks the same account key, which protects you if your master password leaks, but not if the account key itself was taken from a compromised device.
• The web app's code is delivered by our server on each visit (see the threat model). The browser extensions and the desktop and mobile apps don't depend on this.
• Face Key alone may accept an identical twin; the email code, the PIN and the server part still stop them.
• A security question is the weakest way to lock a shared container, because real answers are often easy to find. Prefer a passphrase.
• SyFly has not yet been audited by an independent security firm.

Reporting a vulnerability

If you find a security issue, please tell us. Our policy, with reply and fix times and safe harbor for good-faith research, is on the Report a vulnerability page.