Threat Model Document

Threat Model Document — Heimdall API

1. Purpose

The System Requirements Document states the security controls this API implements. It does not state what they defend against, and a control without a stated threat cannot be judged: there is no way to tell whether it is sufficient, whether it is the right control, or whether removing it would matter.

This document states the threats. Each one names the asset at risk, what an attacker must already be able to do, the control that addresses it — cited as an existing FR or NFR rather than restated — and how anybody knows the control works. Where nothing addresses a threat, that is written down as a finding rather than left out.

It uses the same three verification methods as the Testing Specification Document §11, for the same reason:

• Test — executed by the suite. Fails the build when the property stops holding.
• Inspection — established by reading the code or configuration, and re-established when it changes.
• Measurement — a number produced by a run and published.

And the same rule: a threat whose verification method is “none” is a finding. §11 collects them.

This is a design-level review. It is not a penetration test, and nothing here was established by attacking a deployment.

2. Method

Threats are numbered TH-nn and grouped by the trust boundary they cross, not by the feature they affect. Feature-organised threat models miss the crossings, and the crossings are where the defects are: two features can each be correct and still combine into a boundary that leaks.

Residual risk is what is left after the control, judged on this codebase rather than in the abstract:

• Low — the control addresses the threat and something checks the control.
• Medium — the control addresses the threat, but its coverage has a stated limit, or nothing checks it.
• High — no control, or the control does not cover the case described.

3. Trust boundaries

flowchart LR
    Anon[Anonymous caller]
    Auth[Authenticated caller]
    API[Heimdall API]
    DB[(PostgreSQL)]
    Google[Google identity]
    Ops[Operator / environment]

    Anon -->|TB-1| API
    Auth -->|TB-2| API
    API -->|TB-3| DB
    API -->|TB-4| Google
    Ops -->|TB-5| API

4. TB-1 — Anonymous internet to the authentication endpoints

Every endpoint here is AllowAnonymous by necessity (NFR-04): a caller cannot hold a token yet. They are therefore the only endpoints reachable by someone with nothing at all, and they are where the expensive work is.

TH-03 was the one to read twice, and it is now closed. Each login costs a full Argon2id verification at 600 MB and 16 threads. The rate limiter admits ten a minute per IP and releases them together, so one address could demand roughly 6 GB of working set per minute and remain entirely within policy — measured at 2.8 seconds per login when it happened (SRD §6.3.1). The limiter is partitioned by remote IP and is per-instance, so callers spread across addresses multiplied that budget rather than sharing it, and nothing behind it bounded what got through.

PasswordHashGate is that second bound, and it is deliberately not partitioned by anything: four derivations at once for the whole process, the rest refused with 503 and a Retry-After after ten seconds. Two properties matter and both are tested. It covers every derivation on a request path rather than login alone — an authenticated caller creating persons in a loop reaches the same memory, and a bound with a way around it is not a bound. And it refuses rather than queues, because an unbounded queue is this threat with the pressure moved from memory into the thread pool.

The refusal is a load condition, not a rejection, so it answers 503 rather than 500 and says nothing about the account: the decoy verification AF-11a spends passes through the same gate as a real check, so saturation cannot be used to tell an existing address from an absent one.

The gate bounds one process. Two instances behind a load balancer will each permit four, so the deployment’s total is the bound times the replica count — which is the ordinary arithmetic of horizontal scaling (§6.2) rather than a gap, but it means the number to size against is per instance.

And that is why TH-03 is Medium again. The gate sheds the excess rather than letting it exhaust memory, which protects the process; it does not protect the service. Four permits clear about eleven derivations a second, roughly seven hundred a minute, and the per-partition limit admits ten a minute, so about seventy partitions sending login attempts with made-up addresses fill it — and then a real sign-in waits ten seconds and gets 503, for every client system that depends on Heimdall. Counting an IPv6 caller per /56 rather than per /64 raised the price for one subscriber from a single prefix to many; it did not change the arithmetic for many unrelated networks. The same arithmetic held for an administrator’s token, from one address: creating persons in a loop derives a hash per request. Those endpoints are now limited to thirty a minute per actor and thirty per address — the second because an owner can create co-owners, each a new actor, and so multiply a per-actor bound from one address. What is left there is the same distributed case as for sign-in.

Two fixes were considered and refused. A global anonymous budget ahead of the gate, sized below its throughput, turns the same flood into a denial of every caller at a lower cost to the attacker: whoever spends the budget has denied the service, and they no longer even need to fill the gate. Reserving gate capacity for accounts that exist would make the wait itself an enumeration oracle, which TH-02 exists to prevent. What does work is a bound applied before the request reaches the process, where the network shape of the flood is visible and the cost of refusing it is not paid in Argon2id: the operations guide gives the Traefik middleware for it. Until an operator applies it, this residual is the deployment’s.

TH-04 is rated Low on a different footing from before. It was Low because a further code cost a fresh password check. That price falls on the wrong caller: a second factor exists for the one who already has the password, and to them a login costs nothing. The per-challenge budgets remain, but the bound that holds is now the account’s (FR-AU-12): failures are counted across challenges, a correct password leaves the count alone, and the tenth locks the second factor for a period that doubles at each repeat, up to a day. The lock answers as a wrong code does and still lets the challenge’s own five run out, so it is not visible from outside. Its cost is the residual in the table: whoever holds the password can keep the owner locked out of the second step, which ends when the password is changed and the last lock runs out — at most a day.

5. TB-2 — An authenticated caller to another tenant’s data

Authentication runs in ClaimsOnly mode: the caller is rebuilt from the token’s claims and no data store is consulted, which is what keeps an ordinary request free of a per-request lookup. Everything in this section follows from that decision — a claim is a statement about the past, and the question each threat asks is what happens when the present disagrees with it.

TH-08 is the finding this section exists for, and it is now fixed. As first written the role was carried in the roleId claim and never re-read: ActorLivenessFilter asked only whether the person existed and was not deleted, and ScopeOwnershipChecker grants an unconditional bypass when the acting role is SystemAdmin, taken from the claim without a lookup.

So demoting a System Admin does not take effect until their token expires — an hour by default, and configurable upward. For that hour the demoted account keeps cross-tenant authority over every scope in the system, and the bypass means it does so without any query that could have noticed. This is the one case where the design’s decision to trust claims has a consequence that deletion does not: an account that is deleted is stopped within one request, and an account that is merely demoted is not stopped at all.

And the window is enough to make itself permanent. A role change is refused unless the acting role is System Admin — read, like everything else, from the claim — and the one transition the handler supports is a promotion to System Admin. A demoted account therefore spends its remaining token lifetime able to promote itself straight back, or to promote an account it controls, and that promotion is a database write that outlives every token involved. What looks like a bounded window of stale privilege is a path to an unbounded one, which is why TH-11 is Medium rather than Low: its own control is sound, and it inherits this one’s weakness through the claim it trusts.

The fix is the mechanism TH-09 and TH-12 were already Low for: ActorLivenessFilter was reading the Person row on every request anyway, so it now selects the role out of that row instead of asking whether it exists, and refuses the request when the claim disagrees. No extra query. A promotion is refused on the same rule as a demotion — a check that only rejected claims above the stored role would be the one worth writing carefully and then getting backwards.

Two things fell out of making it true. A token whose role is out of date now gets its own message rather than the deliberately vague one deletion gets, because a role change is not an existence question and the caller can act on it. And a functional test that had been minting a System Admin claim for a person stored as a User stopped passing — it was relying on exactly the forgery this closes, and now names an actor whose claim and row agree.

6. TB-3 — The API to its database

The threats here assume an attacker who can read the database and nothing else: a leaked backup, a compromised read replica, a restored snapshot, or an injection that yields rows. The question each one asks is what that reader can do with what they find.

TH-14 was a straightforward inconsistency, and it is now fixed. PasswordResetService and EmailVerificationService both used to write the token they had just generated straight into the row — Token = token — while a second-factor recovery code, which is weaker as an account-takeover primitive since it still requires the password, was stored as a hash, and a 2FA email code hashed and salted. A reader of the password_reset_token table could complete a reset for any account holding a live token, which did not break the Argon2id work protecting the password so much as walk around it.

Both now store a SHA-256 through SingleUseTokenHash, and the presented token is hashed and looked up against a unique index on the digest. Unsalted, deliberately: these are 48 characters from a CSPRNG, so there is no precomputed table for a salt to defend against, and a per-row salt would force a scan of every live token on every attempt — the caller presents the token alone, with nothing to narrow the candidates by. The migration computes the digest from the column it replaces rather than discarding rows, so links already sitting in inboxes keep working.

What it cost is worth recording, because it is the kind of loss a table of green ticks hides. Two functional tests used to drive issue-then-spend end to end by reading the token back out of the row. They cannot: the suite has no inbox and no seam to substitute a sender through. They now assert what UC-12 and UC-06 stored, and the spending half is covered where the plaintext is still in the test’s hands — the service tests capture it from the sender, the handler tests seed through the same helper. Both halves go through SingleUseTokenHash, so they would fail together if it changed.

TH-15 is Medium rather than Low for a reason worth stating. The TOTP secrets are encrypted, and since the key ring is persisted to the database so that a second instance can decrypt them (SRD §6.2), the ciphertext and the keys that open it now live in the same store. That was the right call for availability — before it, a recreated container silently locked every authenticator user out — but it means the encryption at rest defends against a stolen table and not against a stolen database. Naming that is the point of writing it down; moving the key ring to a separate secret store is a real change with its own operational cost, and is not being recommended here without one.

TH-18 was Medium because the audit log was append-only by convention. AuditLog had said “append-only: never updated or logically deleted after creation” since it was written, and nothing enforced it: the API’s own credentials were sufficient to rewrite the trail, so it was evidence against an ordinary caller and none at all against anyone who reached the database.

A trigger now refuses UPDATE, DELETE and TRUNCATE on the table. A trigger rather than a permission grant alone, because a grant depends on the deployment connecting as a role that lacks those rights, and this repository’s compose file, the functional suite and most development setups all connect as the owner; a trigger travels with the schema and holds for every role but the table’s owner and a superuser. TRUNCATE needs naming separately because it skips BEFORE DELETE entirely, and the triggers fire per statement rather than per row so that a DELETE matching nothing is refused too — otherwise the rule would depend on what the statement happened to hit.

It does not defend against somebody who can also run DDL: a superuser, or the table’s owner, can disable or drop the trigger, or replace its function, and then rewrite history. That is smaller than the hole it closes — it leaves a schema change behind, where an UPDATE left nothing — but it is not zero, which is why the row above is qualified rather than simply Low.

Who owns the tables decides what the triggers are worth. A table’s owner needs no superuser to change its triggers, so the triggers hold against a role only while it does not own the schema. The supported setup therefore separates the two (NFR-29). An owner role applies migrations — the entrypoint gives the bundle HEIMDALL_MIGRATIONS_CONNECTIONSTRING when it is set, or the operator migrates out of band — and the API connects as a role that owns nothing, with the grants the operations guide gives (“Database roles”). audit_log keeps UPDATE at table level for that role, because the retention pass writes the rows it clears whole; which updates are accepted stays the triggers’ decision, and the role cannot change them.

The grants were reviewed and checked by hand against PostgreSQL 18, in a throwaway database: as the runtime role, changing or disabling a trigger, replacing or dropping a trigger function, TRUNCATE, DELETE FROM audit_log, CREATE in any schema and SET session_replication_role were refused, and the API and its handlers ran their functional suite connected as it. No committed test applies them, so a migration that needs a new privilege is caught only by that review. The setup is the operator’s to apply, and the API cannot tell whether it has been, so the row above is rated by deployment.

6.1 The writes the trail now permits, and why it is still Low

NFR-21 narrowed the rule. AUDIT_LOG no longer refuses every UPDATE: it permits the actor attribution to be cleared and, since #184, a target that names a person or Google User — since #195 also one whose row was hard-deleted, recognised by its tombstone — and nothing else. That is a real reduction in what the triggers guarantee, and it is recorded here rather than left for a reader to discover in a migration.

Why it was necessary. actor_person_id holds a person’s PublicId. An indefinitely retained, unalterable row naming somebody who has exercised their right to erasure is personal data processed with no remaining basis, so a table that refused every write made erasure impossible by construction. The two obligations were in direct conflict, and one of them had to give ground. target_id raised the same conflict a second time: for a command somebody runs on their own account it is their own PublicId, and for an administrator’s action on a person it is that person, so an entry with its actor cleared could still name the person it was about.

Why the ground given is narrow. The trigger permits a write only when every column except actor_person_id, actor_role and target_id is identical, each of those is either unchanged or being set to NULL rather than to another value, and each clearing is due — the entry is older than thirty days, or the identity it names has been anonymised. A target may be cleared only when it is the PublicId of a PERSON or GOOGLE_USER row; one naming a scope, an application, a credential or a permission, or nobody at all, stays immutable. The one exception (#195) is an id that no row has any more but that ERASED_SUBJECT records as a hard-deleted person’s or Google User’s: that target may be cleared at any age, as an anonymised person’s may. DELETE and TRUNCATE remain refused outright, per statement.

The tombstone table is guarded too (#195, R1). A row in ERASED_SUBJECT is what makes a target with no row clearable, so a table anyone could write to would have reopened what the triggers close: insert a live scope’s id, then clear every target naming it, with the planted row removed by the retention pass a day later. A BEFORE INSERT OR UPDATE trigger on the table therefore refuses any row whose public_id is not, at that moment, a PERSON or GOOGLE_USER row’s. Every legitimate write passes, because a hard delete writes its tombstones before deleting, and so does the retry’s upsert, which only happens while the row survives. Checking UPDATE as well stops a legitimate tombstone being rewritten to another id afterwards.

What an attacker gains. Somebody holding the application’s database credentials — those of a runtime role that owns nothing, as above — can clear an attribution or a person target older than thirty days, or one of any age naming an identity they have first managed to anonymise. They cannot remove an entry, alter what it says, reassign its actor or its target to somebody else, clear a target that is not a person’s, or clear their own attribution, or the person they acted on, for something they did this week. Anonymising an identity through the API is itself an audited write, and doing it to their own account destroys their access.

The tombstone ground adds one path, and the guard bounds it, stated plainly. The same credentials can tombstone a person or Google User that exists and then delete their row with plain SQL, which the API would have audited and SQL does not; after that, the targets naming them clear at any age. That is the power they already had — delete a person outright, or anonymise them first and clear the same targets — exercised on the same people, and it is destructive and visible, since the person is gone. What the guard stops is tombstoning an id that is not a person’s, so two statements no longer make a target naming a scope, an application or a credential clearable, as they would have without it.

The ids are guarded too (#199). The guard, and #184’s rule before it, read a PERSON or GOOGLE_USER row’s public_id as proof that an id is a person’s, and until #199 that proof could be forged with DML alone: give a person or Google User row a scope’s, an application’s or a credential’s public_id, by rewriting an existing row or by inserting a new one, then anonymise or tombstone it and clear the targets naming that entity. Three rules now close every such path.

• Ids are immutable. A BEFORE UPDATE trigger refuses any change to public_id on PERSON, GOOGLE_USER, SCOPE, APPLICATION, APPLICATION_CREDENTIAL, SCOPE_PERMISSION, ROLE and PENDING_REGISTRATION, every table the identity check trusts. Every other column stays writable, so names, addresses, anonymisation and soft deletes are unaffected. Without it the check below could be walked round: move a scope off its id, insert a person with the freed id, clear the scope’s targets, move the scope back.
• Ids are not shared. A BEFORE INSERT trigger on the same eight tables refuses a public_id that a row of any other of them holds, soft-deleted or not, or that ERASED_SUBJECT records as a hard-deleted person’s or Google User’s; a table’s own unique index covers itself. It runs on every table, not only the identity ones, so the order of the two inserts does not matter: a person inserted first, or the tombstone it leaves when hard-deleted, refuses a scope inserted with its id after it. The tombstone matters because the target rule clears, at any age, a tombstoned id that no identity holds: without it, SQL alone could insert a person, tombstone it, delete it and put a scope on the id, and every entry later written about that scope would be cleared (#199, R4).
• An identity may not take an id the trail names. The same trigger refuses, for PERSON and GOOGLE_USER only, an id that an audit entry’s target_id names. After an ordinary hard delete of a scope, an application or anything else, no row holds its id any more, and an anonymised person planted with it would have made every entry about that entity clearable. Only the identity tables need it, because the target rule reads only them, and the tombstones, to tell a person’s id. It keeps nothing new, since the trail already holds the id, and once the trail no longer names it the id is free again.

The application only ever creates fresh random ids, and writes an identity’s own entries after its row, so no legitimate write is refused. IdentityPublicIdTests and EntityPublicIdTests pin each rule, each table, the tombstone path, and the rename-then-reuse chain end to end.

What remains is stated as plainly. No registry of issued ids is kept, because it would keep a removed person’s id for good, so an id that neither a row, a tombstone nor the trail holds any more may be taken again; it then names nothing the trail could clear. The triggers guard future writes and do not inspect rows already stored; Operations gives the queries to check them. The insert check takes no lock, so two concurrent transactions that both choose the same id can both pass it, and an actor controls both. That race reaches only a row the actor inserts by SQL at that moment, never one that already exists or that the API creates, whose id cannot be known in advance; entries written later about such a planted row could be cleared. Closing it would need one unique index across all eight tables, which is a registry, and is out of scope. And an actor who can run DDL, or disable triggers (ALTER TABLE … DISABLE TRIGGER, or session_replication_role as a superuser), can do anything here, as with the audit triggers themselves. That is the tables’ owner or a superuser, which the API’s role is not once the two-role setup under TH-18 is applied.

Residual risk: Low. The property this threat is about — that an action cannot be denied — is intact: with DML alone, a target can be cleared only when it names an identity that has held its id since it was created, or one the actor planted in the same moment as the entity it shares an id with. What became time-limited is attribution, which is what storage limitation requires of it, and the person an action was taken on is forgotten on the same terms. AuditActorClearingTests and AuditTargetClearingTests pin every case against real PostgreSQL, each refusal by its own reason, the tombstone cases included; ErasedSubjectsTests pins the tombstone table’s guard, and IdentityPublicIdTests and EntityPublicIdTests the public_id triggers.

7. TB-4 — The API to Google

TH-21 was the one gap this document opened against itself, and it has now been traced. The answer is that a Google sign-in cannot reach a password account, for three independent reasons: the account is looked up by Google’s sub within the scope and never by email, so a Person is never a candidate; the token names the Google User’s own PublicId, which is a different GUID from any Person’s; and UC-25 mints the User role unconditionally, which ActorLivenessFilter now enforces for any Google identity. Two tests pin it — one that the colliding sign-in creates a separate row and leaves the admin’s record untouched, one that the token it returns is refused by an endpoint the admin whose address it shares could reach.

What the trace did turn up is narrower, and is recorded here as accepted rather than as a defect. AF-25c asks whether the address is free within the scope, and asks the person half of that question only of persons holding a SCOPE_USER row. An admin has none — UC-06 path b creates them with no scope association — so an admin’s address does not read as taken and the sign-up proceeds. The address then exists twice across the two tables.

That is left as it is on purpose. The alternative is that any address belonging to a system-wide admin blocks Google sign-up in every scope, which is a worse rule than the one being avoided: it turns a system-wide account into a veto over per-scope sign-ups, for no gain that the three separations above do not already provide. Nothing in the system keys off an email across the two tables — login and password recovery read Persons, Google sign-in reads Google Users — so the duplicate is an operational surprise rather than a way in. It is written down because a reader of FR-GO-07 would not expect it.

8. TB-5 — An operator to configuration, logs and images

TH-43 follows from symmetric signing; asymmetric signing is planned, and until then the key is handled as TH-22 describes.

TH-22 was Medium because there was no rotation story, and it now has one. A leaked signing secret is total — it mints any identity at any role — and the only remediation available was a hard cutover: change the secret, and every token in flight dies at once. A remediation that is also an outage is one nobody performs pre-emptively, which is why the secret was in practice never rotated.

HEIMDALL_AUTH_TOKEN_SECRET_PREVIOUS is the other half. Both secrets are handed to JwtConfiguration.Keys, so a token signed with either is accepted while new tokens are signed with the current one. Rotating is three steps and no outage: set the previous variable to the secret in use, set the current variable to a new one, restart; then an hour later — one token lifetime — clear the previous variable and restart again. Withdrawing a key still invalidates its tokens immediately, which is what makes the shortened version of that procedure the right response to a leak.

No kid is written to the tokens, deliberately. The library supports it, but the identifiers here are positional — today’s “current” is tomorrow’s “previous” — so stamping one would make every token issued before a rotation name the wrong key afterwards and be refused, which is precisely the failure this closes. Deriving stable identifiers from the secrets instead would publish something computed from a signing key on every token, a poor trade for saving one HMAC against two keys. Validation tries both.

TH-23 now covers the address as well as the token, and the two halves differ in scope. The token control is environmental: Production refuses to start with delivery unconfigured, so the logging senders that write a token never run there. The address control is not environmental — no statement writes an address in any environment, and LogRedactionTests fails the build if one reappears. That closes a gap the original entry did not name: the token was only ever logged outside Production, but MailgunSender wrote the recipient’s address on every successful send in Production, into files that were then kept forever.

TH-23’s token control covers Production and by design does not cover anything else. A developer or staging deployment without Mailgun credentials logs verification tokens, reset tokens and 2FA codes in plaintext, which is deliberate and documented: the functional suite and a local run both need those flows to work without credentials or network. It is listed here because a staging deployment with real users’ addresses in it turns a convenience into an account-takeover primitive for anyone who can read a log. The development and homologation environments (the latter running as Staging) are exactly such deployments, which is why they hold made-up people only — §0.2 of the Operations & Infrastructure Document . Since NFR-28 (TH-42) such an instance, serving a public host, runs without EF Core’s sensitive logging and the developer exception page unless HEIMDALL_ALLOW_SENSITIVE_DIAGNOSTICS is true.

8.1 Detection

Every control in this model is preventive. Until NFR-26 there was nothing that noticed a control being tested — the audit trail recorded each refusal with its reason, the lockout counters tracked per-account guessing, and the hash gate shed under load, and none of it reached anybody. A trail nobody reads does not make anyone aware of anything, and awareness is what starts GDPR Art. 33’s seventy-two hours.

SecurityMonitoringService now reads those signals on a schedule and writes what exceeds its thresholds to the log with a matchable marker. It is deliberately not a decision procedure: what follows a signal is the Incident Response Document , because automating the declaration would put the notification clock in the hands of a threshold.

9. What this model does not cover

• Risk to the data subject. This model asks what an attacker can do to the system. What the system does to the people in it — including where a control works exactly as designed and is still a harm, as an account lockout is — is the Data Protection Impact Assessment . The two are complementary and neither substitutes for the other.

• No dynamic testing. Nothing here was found by attacking a running deployment. A design review finds missing and mismatched controls; it does not find the ones that are present and broken.

• Denial of service beyond TH-03. The load runs (SRD §6.3) establish what the API delivers under concurrency, not what it does under a hostile request pattern chosen to be expensive. TH-03 now records the one such pattern this review traced — a distributed flood keeping the hash gate full — as an accepted residual for the edge to bound; others have not been looked for.

• The infrastructure the API runs on. Container escape, host access, network position and PostgreSQL’s own configuration are all out of scope, and the Operations & Infrastructure Document is where they would belong.

• The api-client. The published client is not modelled here; every threat above is stated from the API’s side of the boundary.

• Supply chain beyond known advisories. scripts/vulnerabilities.py fails the build on a published advisory. It says nothing about a dependency that is malicious and not yet reported.

10. Adding a threat

The same rule as a use case and a non-functional requirement: it does not exist until something checks it.

A change that crosses a trust boundary in §3 — a new anonymous endpoint, a new claim trusted for authorization, a new table holding a secret, a new external identity source — needs a TH-nn entry before it merges, with a control and a verification method. If the method is “none”, that is permitted and it goes in §11, because an acknowledged gap is worth more than a table of green ticks that hides one. What is not permitted is the entry being absent.

11. Findings register

Every threat above now has a control and a verification method, so this table is empty for the first time since the document was written. That is a statement about coverage, not about safety: §9 lists what this model does not look at, and the register can only be as complete as §4 to §8 are.

11.1 A correction

An earlier revision of this section said TH-22 could not be closed in this repository and needed a change to ArturRios.Jwt and ArturRios.Util.WebApi first. That was wrong, and wrong in a way worth recording rather than quietly editing out.

It was based on reading JwtMiddleware as taking a single JwtConfiguration, and concluding there was no seam for a second key. There was: AuthenticationMiddleware runs a collection of ITokenValidators, that interface is public, and JwtHandler.IsTokenValidAsync already took the secret as a parameter — so this API could always have registered its own validator and rotated without either library changing at all.

The libraries were changed anyway, because the alternative was every consumer rebuilding the same validator, and because a rotation belongs where the tokens are signed. But the reason recorded here for not doing it sooner was a misreading, and a threat model that cites an obstacle should be right about the obstacle.

11.2 Closed

Kept rather than deleted, because a register that only ever lists open items gives no sense of what this document has been worth.

TH-14 and TH-08 were found by reading the code while writing this document, and neither was visible from the requirements they were supposed to follow from. TH-21 was found by this document admitting it did not know — the case for the rule that an unanswered question is written down rather than assumed safe. TH-03, TH-18 and TH-22 were known limits from the first draft, closed later once their cost was understood. Two of those are worth a second look: TH-03’s fix was worth measuring rather than reasoning about, since the obvious prediction — that bounding concurrency would slow login down — turned out to be wrong; and TH-22 sat open partly because this document had the reason for it wrong (§11.1).