Turning up the protection¶

Everything above is already secure. When a particular secret deserves more, add a flag when you store it — the server enforces the rest. These compose freely (you can stack several on one secret), and they apply equally to secrets and files.

Make it un-clobberable. Read-only is the default; make a secret permanently un-replaceable:

bbk put root-ca-key "..." --no-overwrite   # even --overwrite is refused later

Burn after reading, or cap the reads. The secret self-destructs after being read:

bbk put one-time-token "EX_TOK" --delete-on-read   # gone after the first read
bbk put pager-key "PD_KEY" --max-reads 10          # dies on the 10th read

Require two-factor on every read. Enroll once, then flag the secret so each read needs a fresh 6-digit code from your authenticator app:

bbk mfa enroll            # prints an otpauth:// URI for Google Authenticator / Authy / 1Password
bbk mfa verify 123456     # confirm enrollment
bbk put root-pat "..." --mfa-required
bbk --mfa 123456 get root-pat

Require your teammates to approve (K-of-N). Store a secret so that K out of a named set of people must approve before anyone can read it — a "two-person rule" for your most sensitive material:

# Needs 2 of {bob, carol} to approve before alice can read it.
bbk put prod-rootkey "ceremony output" --quorum 2 --signatories bob,carol

bbk -P alice get prod-rootkey     # opens an approval request, returns its ID
bbk -P bob   approve <REQUEST_ID>
bbk -P carol approve <REQUEST_ID>
bbk -P alice get prod-rootkey --request-id <REQUEST_ID>   # now it's released

Approvers can also pre-authorize a reader for a whole category of secrets ahead of time (with an expiry and optional use cap), so routine reads don't need live approval — see grants add.

Encrypt it so even the server can't read it. With --external, the value is encrypted on your machine before it's sent. The server stores only an opaque blob it has no way to open — yet you still can't read it without going through all the normal permission checks and holding the key. Two independent locks, neither enough alone:

bbk put my-secret "value" --external      # server stores ciphertext it can't decrypt
bbk get my-secret                          # decrypted locally, on your machine

There's a lot of flexibility here (managed keys vs. your own passphrase; keeping file ciphertext on the server or resident on your own disk). If you just want "the server can never read this," --external is the one to remember. The full model is in Client-side encryption.