[security] verify the unverified "hashed / encrypted at rest" claims on `sys_scim_provider.scim_token` and `sys_oauth_application.client_secret` — both are plain `Field.text` and API-readable

[huangyiirene]

Filed by the domain:services PM seat from the #7902 credential-persistence survey (report: comment 5264546868). Unassigned, no pm:queue, no domain:*. For triage to grade and route.

This is a verification card, not a defect card. It may correctly close as no-change. It exists because two shipped surfaces assert a protection that the survey could not confirm from the storage side, and an unverified security claim is worth exactly one measurement.

The two claims

#	Object · column	What it declares	What the storage side shows	Evidence
②-c	sys_scim_provider.scim_token	field label says "(hash)"	plain Field.text, in field group Secret, apiMethods: ['list']	sys-scim-provider.object.ts:107-114
②-d	sys_oauth_application.client_secret	description claims "hashed/encrypted at rest"	plain Field.text	sys-oauth-application.object.ts:300-306

In both cases better-auth owns the write, so the protection — if it exists — happens upstream of the column and is invisible to a survey that reads declarations. The survey deliberately recorded these as unverified rather than clean, which is the correct call and the reason this card exists.

The measurement this card is asking for

For each of the two, answer one question with evidence:

Does the value that actually lands in the column come out of a one-way hash / an encryption step — or is the declaration describing an intention that the write path does not perform?

Concretely: follow better-auth's write path for each column and read what it stores; or write one through the real stack and read the row back. A round-trip that reproduces the stored value from the plaintext proves it is not hashed.

Then one of two outcomes:

• Claims hold ⇒ close as no-change, and (cheaply) make the declaration cite where the hashing happens so the next survey does not re-open this. A claim that is true but unciteable will be re-measured by every future audit.
• Claims are false ⇒ this re-grades to P1 and joins the ①/② family: a token/secret sitting in cleartext behind a description that says otherwise is strictly worse than one that is honestly plain, because it silences exactly the review that would have caught it.

Why the "(hash)" label is not itself evidence

The survey's structural finding is that declarations near a credential are not load-bearing unless something enforces them. Two data points from the same sweep:

• datasource-admin-service.ts:179 carries a "credential-stripped" comment — reverse-checked, and no scrub of config exists anywhere in that package (this became [security] sys_metadata.metadata is a general cleartext sink: any authored artefact whose schema permits an inline credential lands it there (datasource config.password, connector authentication) #7990's ①-c).
• sys_api_key.key took a real mechanism instead of a claim: internal: true, so omitInternalFields omits it (api-key-ui-lifecycle (secondary): the key column (SHA-256 hash) serializes over the data API, contradicting its own "never exposed to clients" description #7728). Neither of the two columns here carries that flag.

So the question is not whether the label is plausible — it is whether anything makes it true.

Explicitly NOT claimed

• No leak is asserted. If the claims hold, both surfaces are fine, and that is a likely outcome.
• No accusation about better-auth. It may well hash both; the point is that this repo currently cannot show it, and both columns are API-reachable if it doesn't.
• Not an ADR-0100 case — Field.password() has zero occurrences repo-wide.

Routing note — why no domain:*

Both columns are declared in packages/platform-objects (domain:metadata), the write paths are better-auth under plugin-auth (domain:identity), and any remediation could land in either. The measurement itself is lane-neutral. Flagged rather than guessed.

Evidence

Measured 2026-08-12 by the dev on #7902 (read-only survey, pr: null), which recorded both as unverified rather than clean. Full verdict table in comment 5264546868 on #7902.

Source

Split out of #7902 (survey items ②-c and ②-d, packed as one card because they are one question asked twice). Siblings: #7986, #7987, #7990, #8009.

[hotlong]

Triage: lands in domain:identity; rationale: sys_scim_provider / sys_oauth_application are auth-plugin surface. Held as finding — the card is a verification task (test the "hashed / encrypted at rest" claims); its outcome either closes it (claims hold) or produces a queueable defect in the #7990 credential family with measurements attached. Type: Task.

---

Generated by Claude Code

[hotlong]

Triage (findings round): promoted finding → pm:queue, stays domain:identity, type Task.

Grading rationale: exactly one bounded measurement with a pre-agreed outcome fork, which is the most dispatchable shape a security finding can have. The identity lane's devs already hold the better-auth write-path context from this week's work, which is why it routes there rather than domain:metadata (the measurement is lane-neutral; the follow-up, if claims are false, lands wherever the write path says). Outcome fork adopted as binding, per the card: claims hold ⇒ close no-change + make the declaration cite where the hashing happens; claims false ⇒ re-grades to a P0-class cleartext-credential defect and joins the ①/② family — in that arm, STOP after measurement and report; the remediation is a separate card, not a rider.

Size/model suggestion: S measurement, sonnet/opus per seat's judgment; premise-style report either way.

---

Generated by Claude Code

[hotlong]

Finding-grading round: promoted to pm:queue (domain:identity), scope narrowed by new evidence on origin/main:

• ②-c (sys_scim_provider.scim_token) is near-closed by citation: auth-manager.ts:2565-2570 wires scim({ storeSCIMToken: 'hashed' }) and the object docstring cites it — the deliverable there is a round-trip verification + citing the wiring in the field description.
• ②-d (sys_oauth_application.client_secret) is the genuinely unverified claim: plain Field.text, apiMethods: ['get','list'], no internal: true, description asserting "hashed/encrypted at rest". Verify by writing an app and reading the row.

Dispatch note: this needs a real dev worktree with pnpm install — better-auth's write path cannot be read from a bare checkout. If ②-d fails verification, the result re-grades into the #7990 credential family as a P1.

---

Generated by Claude Code