This repository holds the Sesame server: the vault-blind Go API, the account portal, and the administration portal. It is early software and has not had an independent security audit.

The rule this service exists to keep: the shipping API stores account and release records, not vault data. Sync stores opaque ciphertext and signed headers and has no decryption key. It is off until an operator turns it on, and it has not had an independent security review.

Do not open a public issue, discussion, or pull request for a security problem. Use GitHub private vulnerability reporting: open the repository's Security tab and choose Report a vulnerability.

If you cannot use GitHub, ask for a security contact through the account portal's support form. Do not put vulnerability details in that first message: support intake is read by a wider group than an advisory.

• What an attacker gains, in one sentence.
• Whether it needs an account, an admin session, or neither.
• The steps to reproduce it, in order, against your own deployment.
• Whether you ran the self-hosted Compose deployment or something else.

Never send a real password, vault, export, recovery kit, TOTP seed, session cookie, or account token. Use fictional data in every reproduction.

• We acknowledge within 5 working days.
• We give an assessment and a rough timeline within 10 working days.
• We tell you when a fix ships and credit you unless you prefer otherwise.

In scope:

• Any endpoint that accepts, stores, or returns something a vault-blind service must never hold: a vault, a master password, a PIN, a recovery kit, a wrapping key, or a TOTP seed. This is the highest-severity class here.
• Authentication, session handling, CSRF, and the origin rules: reaching an account route from an origin that is not the account portal, or an admin route from anything but the admin portal.
• Cross-account access: reading, changing, or deleting another account's data.
• Privilege escalation between admin roles, audit-log tampering, or crossing from an admin session to account data.
• Desktop link and device tokens, download tickets, passkey ceremonies, and the signed capability envelope.
• The self-hosted deployment: a key that is predictable, shared between installations, or logged; an admin bootstrap that can be replayed.
• Support intake accepting secret-shaped content it should refuse.
• Sync: a server that can read, add, hide or reorder a device or a version without a client noticing, a request signature that can be replayed or moved to another token, and any route that changes state without a device signature.

Out of scope:

• Missing hardening with no demonstrated impact: header audits, version disclosure, rate limits without a working amplification, scanner output.
• Denial of service through traffic volume, and social engineering.

We will not pursue or support legal action against research that stays within the scope above, uses only your own deployment and your own accounts, avoids accessing or retaining anyone else's data, avoids degrading the service for others, and gives us reasonable time to ship a fix before public disclosure.

Each administrator audit row stores hash = SHA256(prev_hash || canonical(row)) over its stored values, computed in the same transaction as the insert. The API recomputes the chain during the hourly maintenance run and writes a signed checkpoint, covering the newest row, with the capability signing key from SESAME_CAPABILITY_SIGNING_KEY. It logs the covered sequence, the chain hash, the signing key id and the signature in hex. The checkpoint proves the covered history was not rewritten after the checkpoint was taken, when that log line is retained outside the database. It does not prove that the entries were accurate, and a writer who rewrites the whole chain and every retained copy before the next verification is not detected by the database alone.

• Sesame has not had an independent security audit.
• The self-hosted deployment runs over loopback HTTP by default. A deployment behind TLS must set the two session-secure settings itself.