Skip to content

If there is a breach

A breach is anyone getting at data or keys they should not have: a copied database, a leaked secret, a signed-in session that is not theirs. This page is the plan. Follow it in order, write down the time of every step, and keep going even when the picture is unclear.

What a copy of the data gives away

Know this first: it decides how bad it is.

Leaked What the attacker gets How bad
A site's own database public keys, addresses or sub values; no passwords, nothing to reuse (Security model) low
The provider's database email addresses and mobile numbers, profile fields, session records, and password hashes (PBKDF2 in the browser, PBKDF2 again on the server, salted per account) serious: contact details are personal information
The provider's signing key the power to mint tokens any site accepts, until the key is changed critical
The pairwise salt the power to link one person's sub across sites serious, and permanent (Running a provider)
Someone's secret words that one person's identity key serious for them; only they can move to a new key

The first hour

  1. Stop the leak. Close whatever let them in: the exposed route, the leaked token, the public bucket. Turn the key or token off at its source (Cloudflare, GitHub, GitLab) before anything else.
  2. Change the signing key if it, or the worker's secrets, could have been read. Make a new one (oidc.generateSigningKey()), put the private half in the worker's secrets, deploy. Every token in flight dies within an hour; people sign in again.
  3. Sign people out. For named accounts, the operator routes: disable blocks sign-in and ends every session; force-reset removes the password and ends every session. For one token, POST /oauth/revoke.
  4. Keep the evidence. Export the database and the Worker logs before changing data (wrangler d1 export --remote). Don't delete anything the attacker touched; copy it aside.
  5. Write it down. One file: what happened, when you noticed, what you did and when, what data was involved, how many people.

Working out who is affected

  • Which tables, which accounts, which dates. /accounts/operator/export shows everything held about one account.
  • Whether the data was only reachable or was actually taken. Logs and Cloudflare analytics tell you which.
  • Whether harm is likely: contact details plus anything that lets someone be found, impersonated or defrauded is "likely serious harm".

Telling people

Tell people when they could be harmed, and tell them plainly:

  • what happened and when;
  • what of theirs was involved, exactly;
  • what we have done (keys changed, sessions ended);
  • what they should do: change the password, watch for emails pretending to be us, secure the account;
  • where to ask: help.omxus.com/contact.

Send it by the contact the account verified. Put the same words on the affected sites. Don't wait for a perfect picture; send an update when it changes.

The law in Australia

Under the Privacy Act's Notifiable Data Breaches scheme, an organisation it covers must:

  • assess a suspected breach quickly, within 30 days;
  • if it is likely to cause serious harm to anyone, tell the OAIC and the people affected as soon as practicable.

Many businesses with turnover under $3 million are not covered by the Act. Tell people anyway: it is the right thing, and it is what this page asks of every Omxus provider. If people overseas are affected, their own laws (the GDPR's 72 hours, for one) may apply.

Getting back

  • Restore from the nightly backup if data was changed or destroyed. Restore into a new database, compare, then switch.
  • Check that the hole is closed: repeat the attack against the fixed build.
  • Write up what happened and what changed, and put it in the project's CHANGELOG. If the cause was in Omxus itself, open an issue so every provider gets the fix.

Before it happens

  • Keep secrets in the worker's secrets, never in a repo.
  • Back up every database nightly, somewhere the site's own keys can't reach.
  • Turn on the operator routes now, so they work on the day.
  • Know who decides, and who sends the email. Write their names in your provider's own copy of this page.