Threat model

This page says what Sternway protects, against whom, and where that protection stops. Each section lists what holds and what does not. “Does not hold” is a known limit of the design, not a bug waiting for a fix.

What is protected: your vault (hosts, keys, passwords, snippets, known hosts, port forwards and settings), the sessions you open, and the account that syncs them. Secrets are encrypted on the device before anything leaves it.

Sternway has not had an outside security review yet. The statements here come from the design and its tests, and from internal reviews of each release.

A malicious or compromised sync server

Holds

• It cannot read your data. Items, session logs and vault names are sealed with keys it never has, and bound to their id, type, vault and key version, so it cannot move them between vaults or pass one off as another (How the end-to-end encryption works).
• It cannot make your password cheaper to guess: the apps refuse to derive your keys with less work than the minimum, or than the account used before.
• It cannot change a team’s membership. The member list is signed by the owner and checked by every device; a vault key is accepted only from the owner (or an allowed admin) at a version the signed list allows. A team or vault that appears from the server is not used until you accept it on that device (How teams and trust work).
• It cannot quietly serve an old version of an item: every item carries a version counter inside its sealed data, and an older one is refused and reported. A known host it says was deleted is never removed without asking.
• It cannot read shared terminal sessions: their key is in the invite link’s # part, which never reaches the server.
• It cannot push a fake update: the update feed is signed with a key built into the app, with an expiry and protection against replaying an old feed.
• It cannot wipe your own data. A revoked device, a deleted account or a failed sync never deletes your own hosts and keys from the device (How Sternway keeps your data safe).

Does not hold

• Trust on first use. The first member list of a team, and the first public key of each person, are taken as the server presents them until you compare safety numbers. A server malicious from the very start can present a person or team of its own; the accept prompt and the “Not verified” mark make this visible, they do not prevent it.
• Freezing. The server can withhold new versions and new member lists, so a device keeps an older (but genuine) state. It cannot forge newer ones.
• Deletions of most items. Below the threshold that makes a sync ask, the server can make an item other than a known host disappear, as a teammate’s deletion would. It cannot bring an older version back afterwards.
• Metadata. The server sees and keeps item ids, types, sizes, revisions and times; your email, name and handle; device names and platforms; team names, members and their signed lists (with the policy values and reasons of a team that uses policies); invites; which team hosts you are connected to (presence, which you can turn off); and your IP address.
• The key directory. Anyone who builds an authorized_keys file from your published keys trusts the server for them.
• Email. Unless the server can send mail and you verified your address with a mailed code, nothing proves an email address belongs to its account; team member rows say which.

Someone on the network

Holds: every SSH connection, each jump host included, checks the host key. A changed key stops the connection; the only way on is Replace key. Host certificates count only with a valid signature from a CA you trust and a matching name. Old, weak algorithms are off unless you turn them on for a host. Sync uses HTTPS only (plain HTTP only to the same computer), and what it carries is end-to-end encrypted anyway. Single sign-on and passkey sign-ins come back only to the app that started them.

Does not hold: the first connection to a host trusts the key you accept, as OpenSSH does. For anything important, compare the fingerprint with the server’s over another channel.

A malicious SSH server

Holds: what a server prints cannot run code in the app. A request to write to your clipboard (OSC 52) is asked about and capped at 64 KiB, and reads are ignored. Links from a terminal open only after you confirm, and only http, https and mailto. Pasting strips control characters and asks before a paste of several lines. SFTP downloads keep file names inside the folder you chose. Agent forwarding is off unless you turn it on, and it forwards Sternway’s keys, never your SSH agent.

Does not hold: a server you log in to can show you anything in the terminal. What you type there and what you run is yours.

A team member, or a former one

Holds: the server enforces who may view, edit or manage each vault. A removed member gets nothing new: the next key rotation leaves them out. A port forward from a team vault, and any forward that listens beyond this device, starts only after you approved that rule on this device. A team host another member changed (its address, jump hosts, login, startup command and more) stops before connecting, says who changed what and when, and asks. A team vault cannot turn on agent forwarding beyond your own setting, and a host key you accepted yourself wins over a team vault’s.

Does not hold:

• A member with edit access can still write misleading items: a host they created, a snippet, a known host for a host nobody trusted before. The prompts make changes visible; they do not judge them.
• The “changed by” name is the writer’s own claim; a dishonest member can put another member’s name there.
• Removed members keep what they had: the keys and items they synced before. Rotation protects only what is written afterwards. Change credentials they may have seen.
• “Can view” is enforced by the server only: a viewer’s devices hold the vault key and could read everything in it.

A team admin, and team policies

Holds: an admin can sign only what the owner allowed, and every device checks each change against the team’s rules before it uses it, so an admin cannot take the owner’s powers, grant access they do not have, or relax a policy past what the owner allows. Policies are applied by each member’s app from the signed list, never loosen a member’s own setting, and a team whose policy a device cannot read is refused rather than treated as having none. Device reports are signed by each member’s own key; the server can withhold them but not forge them.

Does not hold: app policies are enforced by the apps, so a modified app can ignore them. Server policies are enforced by the server, so a malicious server can skip them while showing them as on. Admins who collude, or an admin and the server together, can do what each may do; the owner sees every signed change and can revert relaxations. Policy values and reasons are visible to the server.

Other apps on the phone

Holds: the app’s data is left out of Android backups; only its main screen and its own links are open to other apps, and links into it (ssh://, sternway://) connect only after you confirm and never use a password from the link. The lock screen covers every screen and the recents preview; screenshots are blocked while a secret is shown (or always, with Block screenshots). Secrets copied to the clipboard are marked sensitive.

Malware or another user on the computer

Holds: the app’s data is sealed with a key the operating system’s keychain holds, files are readable only by your user, a profile does not open on another account or computer, and the app’s window runs sandboxed with a strict content security policy.

Does not hold:

• Malware running as you can read the keychain, the app’s memory and its files, as you can. Sternway is not a defence against it.
• The app lock is a screen, not encryption of what is open. While the app is locked, the keys it already unlocked stay in memory. Locking stops someone at the keyboard, not malware.

Imported files

Holds: an import never runs ProxyCommand, LocalCommand or Match exec from a file (a ProxyCommand runs only from your own linked ~/.ssh/config, which never syncs). Imports are previewed, read only regular files of at most 16 MiB, list every key file they would read (none ticked for a team vault), and take a snapshot before replacing anything. CSV exports write formulas as text.

Where to read more

• What leaves your device: every request the apps make.
• How Sternway keeps your data safe: every way local data can go, and what protects it.
• How teams and trust work.