Security model

Three keys, three places, and we hold only the one that opens nothing.

The design goal is simple to state: an attacker with everything our servers hold, including a customer's username and password, must learn nothing about the customer's wells.

What lives where

ItemWhereWho can read it
Raw rig files (mudlogs, geology tables, surveys)Your workstation onlyYou
Built dashboard objects (plain JSON)Your workstation (out/)You
Encrypted objects (AES-256-GCM over gzip JSON)Your workstation and, with sync on, our private object storeAnyone with the data passphrase; nobody else, including us
Data passphraseEngine config on your workstation; typed into the browser per sessionYour team
Username, password hash (scrypt), licence state, audit logOur private storeOur admin console
Engine push secret (hashed)Hash on our side, plain in your engine configYour engine

The three keys

1. Account password

Authenticates a person to the service. It is checked server-side against an scrypt hash and produces a short-lived, HttpOnly, SameSite=Strict session cookie. It unlocks the dashboard shell and the right to download ciphertext for your organisation. Nothing more.

2. Data passphrase

Chosen in the engine, never transmitted. Browser and engine derive the same AES-256 key: PBKDF2-SHA256 (250,000 rounds, per-organisation salt) then HKDF-SHA256. Every object is encrypted with a fresh random nonce and authenticated (GCM tag), so a wrong passphrase fails cleanly and a tampered object is rejected. A leaked account password does not help: without this passphrase, the ciphertext is noise.

3. Push secret

Lets your engine upload new objects. It is a random 256-bit token; we store only its hash. It cannot read anything and can be rotated from the dashboard's Account page.

Local mode: zero upload

If the policy is "nothing leaves the site", skip sync. The dashboard can open the engine's output folder directly through the browser's file-system access API (Chrome and Edge). The licence check is the only network call.

Platform hardening

What we can and cannot do

We can see that an organisation exists, how many objects it pushed and when, and the names of the objects (well identifiers are hashed by the engine before upload when you enable anonymise_names). We cannot read any value, depth, event or geology description, and we cannot recover a lost data passphrase. If it is lost, run borewatch set-key and push again; the engine rebuilds everything from the files on your disk.

Cryptography is implemented with the platform primitives (WebCrypto in the browser, the cryptography package in the engine); the formats are documented in the engine source so you can verify them.