- TypeScript 66.4%
- Svelte 27.7%
- CSS 2.9%
- Shell 1.6%
- JavaScript 0.7%
- Other 0.7%
The original spec stored only `kek_salt`, `wrapped_dek_pw`+nonce,
`rec_salt`, and `wrapped_dek_rec`+nonce. Under that model, anyone who
knew a user's email could POST to /auth/recovery-complete with junk
material and overwrite the password-side wrap, locking the legitimate
user out. The data stayed safe (the attacker couldn't decrypt
anything) but the account was effectively DoS'd until the user dug up
their recovery code.
Fix: add a recovery-side verifier mirroring the password-side one.
Storage: two new columns on `users`:
- rec_auth_salt BLOB NOT NULL — independent of rec_salt
- rec_auth_verifier_hash TEXT NOT NULL — Bun.password.hash output
The migration adds them via ensureColumn() for forward-compat with
scaffold DBs that pre-date this commit; new tables get them via the
CREATE TABLE statement.
Wire protocol:
- SignupRequest gains rec_auth_salt + rec_auth_verifier
- RecoveryChallengeResponse gains rec_auth_salt
- RecoveryCompleteRequest gains rec_auth_verifier
Server (server/auth.ts):
- signup hashes the recovery verifier alongside the auth verifier
and stores both
- recovery-challenge returns rec_auth_salt so the client can derive
the verifier; refuses with 409 for pre-fix accounts that have a
NULL rec_auth_salt
- recovery-complete calls Bun.password.verify against the stored
hash BEFORE touching any state. Always runs verify even for
unknown emails (against a dummy hash) so timing doesn't leak
existence — same pattern we already used for /auth/login.
Client (frontend/src/lib/auth.ts):
- signup() generates a fourth salt and derives the recovery
verifier from the recovery code
- recover() fetches the new rec_auth_salt and submits the derived
verifier as part of recovery-complete
Recovery.svelte distinguishes the new 401 ("Feil gjenopprettingskode")
and 409 ("Denne kontoen mangler gjenopprettingsverifikator") cases.
Regression test (tests/auth.test.ts) asserts the gate is real:
- junk recovery verifier → 401, no state changes
- unknown email → 401 (constant-time)
- challenge response includes rec_auth_salt
- correctly-derived verifier passes the gate
SECURITY.md is updated to describe four salts instead of three, the
new key-model storage, and the closed lockout DoS. CLAUDE.md flags
the rec_auth_* columns as load-bearing — removing them re-opens the
hole.
This is the only deviation from the spec's stated storage model;
documented as such in both SECURITY.md and CLAUDE.md.
|
||
|---|---|---|
| frontend | ||
| server | ||
| shared | ||
| tests | ||
| .dockerignore | ||
| .gitignore | ||
| bun.lock | ||
| CLAUDE.md | ||
| Containerfile | ||
| package.json | ||
| README.md | ||
| SECURITY.md | ||
| tsconfig.json | ||
| winter-list-claude-code-prompt.md | ||
Vinterliste
A small end-to-end-encrypted app for collecting winter activities — things to do when winter feels long. Activities can be:
- private — encrypted client-side; the server only ever sees ciphertext;
- semi-public — visible to everyone, but the creator is not shown;
- public — visible to everyone, attributed to the creator.
See SECURITY.md for the cryptographic model. It's load-bearing
— read it before changing anything in shared/crypto.ts or the auth flow.
Stack
- Runtime: Bun 1.3+. TypeScript everywhere.
- HTTP: Hono on Bun.
- DB:
bun:sqlite(built-in), WAL mode. - Server password hashing:
Bun.password(argon2id) — auth verifier only. - Client crypto:
libsodium-wrappers-sumo(WASM — the SUMO build is needed because the standardlibsodium-wrappersdoesn't shipcrypto_pwhash). Argon2id viacrypto_pwhash; AEAD via XChaCha20-Poly1305-IETF. - Frontend: Svelte 5 + Vite. Private tag index in IndexedDB.
- Container: single
oven/bunimage, one volume for the SQLite file.
Layout
shared/ pure modules used by both server and frontend
crypto.ts libsodium-backed key derivation, AEAD, wrap/unwrap, helpers
types.ts wire-level types shared across the network boundary
server/ Bun + Hono backend
db.ts bun:sqlite, WAL, idempotent schema migration
session.ts opaque, server-stored sessions (httpOnly cookie)
auth.ts signup, challenge, login, logout, password change, recovery
activities.ts CRUD with visibility rules
tags.ts server-side (public/semi) tag store + autocomplete
index.ts Hono app + static frontend in production
frontend/ Vite + Svelte 5 SPA
src/lib/crypto.ts re-exports shared/crypto for bundling
src/lib/api.ts fetch wrapper for the JSON API
src/lib/auth.ts signup/login/recovery orchestration
src/lib/tagIndex.ts IndexedDB store for private tags
src/lib/session.svelte.ts in-memory DEK + current user
src/components/ Svelte 5 components (Login, Signup, Recovery, Home, …)
tests/ Bun tests
crypto.test.ts round-trip wrap/unwrap, AEAD, password change, recovery
Containerfile single-image build for podman
Running locally
You need Bun 1.3+ installed.
bun install
# 1. In one terminal — start the API on http://localhost:3000
bun run dev:server
# 2. In another terminal — start the Vite dev server on http://localhost:5173
# (it proxies /api to :3000)
bun run dev:frontend
The dev server writes the SQLite file to data/vinterliste.db. Set
VINTERLISTE_DB=/some/other/path to override.
Tests
bun test
The crypto tests cover:
- DEK wrap/unwrap via both the password and recovery paths;
- AEAD encrypt/decrypt round-trip, plus tamper and wrong-key rejection;
- password change preserves activity ciphertexts (DEK is the same);
- recovery unlocks even after multiple password changes;
- recovery-code normalisation handles dashes and casing;
- the safe alphabet excludes visually ambiguous characters.
Typecheck
bun run typecheck
Production build
bun run build:frontend # produces frontend/dist
NODE_ENV=production bun run start
The server serves the SPA from frontend/dist in production. All non-/api/*,
non-/assets/* requests fall through to index.html so client-side routing
still works.
Container (podman)
The provided Containerfile builds a single image that serves API + frontend
and persists the SQLite database in /app/data (one volume).
BUILDAH_FORMAT=docker podman build \
--build-arg BUILD_DATE="$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--build-arg GIT_REVISION="$(git describe --always --dirty 2>/dev/null || echo dev)" \
-t vinterliste:latest .
# Create a named volume for the SQLite file
podman volume create vinterliste-data
podman run --replace --name vinterliste \
-p 3000:3000 \
-v vinterliste-data:/app/data:Z \
vinterliste:latest
# Visit http://localhost:3000
The container exposes /api/health for healthchecks and bakes the build date /
git revision into both OCI labels and /etc/build-info.
Manual verification
After signing up an account, the spec asks you to inspect a private row
directly in the DB and confirm only ciphertext is stored:
sqlite3 data/vinterliste.db \
"SELECT id, visibility, title, loc_label, scheduled_at,
length(ciphertext) AS ct_len, length(nonce) AS nc_len
FROM activities WHERE visibility = 'private';"
You should see title, loc_label, and scheduled_at all NULL, and the
ciphertext / nonce columns populated.
Status / scope
This is the scaffold from winter-list-claude-code-prompt.md. In scope:
- repo structure, schema, single-image container
- crypto module + tests
- signup / login / password change / recovery
- activity CRUD with strict visibility handling
- tag autocomplete (server
tagstable + client IndexedDB)
Explicitly out of scope for now:
- sharing/permissions beyond the three visibility levels
- comments, notifications, other social features
- native/mobile apps
- server-side full-text search over private data
- rate limiting on auth/recovery endpoints (defense-in-depth — the recovery verifier already closes the lockout-DoS hole; rate limiting reduces online brute-force surface)