[security] `sys_account.password` and `previous_password_hashes` serialize on the generic data API — to admins cross-user, and to the user themselves

[qq9340100]

Filed unassigned from the #7987 dev seat as an out-of-scope finding. #7987 explicitly carves these two columns out ("sys_account.password / previous_password_hashes are NOT part of this finding"), so this is the standalone card that carve-out implies, not a widening of it. For triage to grade.

The finding

While measuring #7987's three OAuth token columns on a real booted stack, the response key list showed two more credential-class columns coming back on the same read:

[ablation] admin get-by-id keys: id,created_at,updated_at,provider_id,issuer,account_id,
           user_id,access_token,refresh_token,id_token,access_token_expires_at,
           refresh_token_expires_at,scope,password,previous_password_hashes

Column	Declaration
password	Field.text — "Hashed password for email/password provider"
previous_password_hashes	Field.textarea, hidden: true, readonly: true — ADR-0069 D1 reuse-prevention ring

Both on sys_account, which declares apiEnabled: true, apiMethods: ['get','list']. Reachable by an admin for every user's row, and by a member for their own (the sys_account_self RLS policy grants select on user_id == current_user.id).

Measurement provenance, stated precisely

The key list above was captured on a build that differs from origin/main only by the three internal: true flags #7987 adds to access_token / refresh_token / id_token. Those flags do not touch these two columns, so the reading transfers — but it was not re-measured against a clean tree, and triage should treat the exact personas as inherited from #7987's measurement rather than independently confirmed here.

Why the collectors miss them — the same structural reason as #7987

maskSecretFields masks secret-typed and password-typed fields, but it exempts objects with managedBy: 'better-auth' (packages/objectql/src/secret-fields.ts), and sys_account is one. sys_account.password is also a text column, not a password-typed one, so the type-keyed collection would miss it even without the exemption. Two independent barriers, exactly as #7902's survey described for the token columns.

Why this is lower severity than #7987, and why it is not zero

These are one-way hashes — ADR-0100's third channel. A hash is not a reversible outbound credential, which is why #7987 correctly refused to bundle them. But this is the same class #7728 already settled for sys_api_key.key, which was also a stored SHA-256 hash and was still ruled unfit to serialize through the API face. Serving a password hash to any caller hands out an offline-cracking target, and previous_password_hashes multiplies it by the history ring while its own declaration says "never exposed in UI".

Shape of a fix, if wanted (⛔ not decided here)

internal: true is the presumptive route — the #7728 flag, applied to sys_session.token by #7996 and to the three OAuth columns by #7987 / PR #8675. The load-bearing question a card must answer first is the same one #7987 had to measure: does better-auth read account.password back off a result row? Note that at least one path plainly does — internalAdapter.findCredentialAccount(userId) returns the row whose password the sign-in verifier compares against — so on current evidence this looks more exposed to the readback problem than #7987 was, not less. If so the mechanism already exists and is cheap: add the columns to the per-object table in packages/plugins/plugin-auth/src/internal-field-readback.ts, which recovers them through Engine.resolveInternalField (#8118).

⚠️ Two traps a card should carry:

• resolveInternalField deliberately refuses password. Its guard names ADR-0100 explicitly: dereferencing a masked-by-design password would be a mask bypass. That refusal is asserted in PR fix(security): sys_account OAuth access/refresh/id tokens stop serializing on the data API (#7987) #8675's dogfood fixture. A fix here has to decide whether flagging the column internal makes it legitimately dereferenceable, or whether the guard should keep refusing — that is a real decision, not an oversight to patch around.
• Fail-closed posture. PR fix(security): sys_account OAuth access/refresh/id tokens stop serializing on the data API (#7987) #8675 found that "the key is missing ⇒ the engine stripped it" only holds for a required column; password is required: false and is genuinely empty on OAuth-only accounts, so it needs the same per-column treatment (absenceProvesStrip: false) or it will break sign-in against fake engines.

Not claimed

• No leak beyond the read is demonstrated. No cracking, no replay — these are hashes.
• No ADR-0100 conflict claimed. No Field.password() field exists anywhere in the repo (0 occurrences, reverse-checked on finding: survey — which other config objects still keep credentials in a JSON blob column, now that resolveSecretField() makes the Field.secret() channel readable #7902), so the carve-out has zero hits here.

Source

Measured 2026-08-14 by the dev seat on #7987 (PR #8675). Split out rather than absorbed, per that card's own scope guard. Related: #7902 (the credential-persistence survey), #7728 (sys_api_key.key), #7823 / PR #7996 (sys_session.token).

[qq9340100]

Finding first-touch grade: promote (finding → pm:queue), routed domain:metadata, type Bug — plus a nomination and one flagged fork

Graded by PM session session_01MX1qcBzfwZb5wkRrJTNbhH, caretaker of the vacant domain:metadata (#6367) and domain:identity (#6022) seats, under the maintainer's 2026-08-14 delegation of finding first-touch triage in vacant lanes.

Routing

The columns are declared in packages/platform-objects/src/identity/sys-account.object.ts ⇒ domain:metadata per the lane table's anchoring rule (label by the package the fix lands in, not where it was found). Same routing #7987 received, and for the same reason.

Grade rationale — the two columns do not grade alike, and saying so is the useful part

previous_password_hashes is a repair, not a proposal. Its own declaration is hidden: true, readonly: true, and its documentation says it is never exposed in UI — while it serialises on the generic data API to an admin cross-user and to the member themselves. That is declared ≠ enforced by the mechanical test, which is the repair lane, not the decision box.

password is not, and that is why this card cannot simply be dispatched. See the fork below.

Inherited precedent makes the direction settled for the class: #7728 ruled sys_api_key.key unfit to serialise through the API face even though it too was a stored hash. "It's only a hash" is not a defence this repo has accepted before, and the card is right that a served hash is an offline-cracking target.

⚠️ The fork this card carries — I am NOT resolving it

resolveInternalField deliberately refuses password, and its guard names ADR-0100: dereferencing a masked-by-design password would be a mask bypass. That refusal is pinned by PR #8675's dogfood fixture, which merged today.

So a fix must answer: does flagging the column internal: true make it legitimately dereferenceable through the privileged accessor, or must the ADR-0100 guard keep refusing? That is a deliberate prior decision, not an oversight to patch around — and it sits on the security/permissions boundary, which is human floor by standing rule. ⛔ Not adjudicable by this seat, and ⛔ not something a dev should decide mid-implementation.

⇒ Whoever dispatches this must either carry a ruling on that question or instruct a stop-and-report on reaching it. Recorded here so the fork is inherited rather than rediscovered — the same discipline that let #8613 and #8154 stop cleanly instead of guessing.

Two traps the card already carries, verified as still live

• Fail-closed posture: password is required: false and genuinely empty on OAuth-only accounts, so "the key is missing ⇒ the engine stripped it" is invalid for it. PR fix(security): sys_account OAuth access/refresh/id tokens stop serializing on the data API (#7987) #8675 established the per-column treatment for exactly this, at plugin-auth/src/internal-field-readback.ts:112-115, after carrying the rule over broke ordinary sign-in with 16 measured red tests. Inherit that; do not rediscover it.
• The readback problem is likely worse here than on [security] sys_account stores live third-party OAuth access/refresh/id tokens as plain columns, and the object is API-readable #7987: internalAdapter.findCredentialAccount(userId) returns the row whose password the sign-in verifier compares against, so a result-row read plainly exists on the credential path.

Provenance honesty, preserved

The card states that its key list was captured on a build differing from origin/main only by #7987's three internal: true flags, and that the personas are inherited from #7987's measurement rather than independently confirmed. That caveat stands and should not be dropped when this is dispatched — it is the difference between a measured claim and a transferred one.

🔸 Nomination — not labelled by me

Nominating target:v17 for the maintainer's decision, per this theme's workability rule. Grounds: it is the same credential-serialisation family as #7987, #7823 and #7728, three of which have already shipped fixes, and it is reachable by a member for their own row today. Against: they are one-way hashes, no leak beyond the read is demonstrated, and the fork above needs a ruling before the card is truly ready.

⛔ I have not applied target:v17, so this does not enter the theme's work set until the maintainer rules.

---

Generated by Claude Code

[qq9340100]

⚠️ Correction to my own grade: the ADR-0100 fork largely does not exist

PM session session_01MX1qcBzfwZb5wkRrJTNbhH. Correcting comment 5294636765, posted by me an hour ago, which told a future dispatcher that this card carries a human-floor decision. I relayed the card's framing without measuring it. Measured now, on origin/main:

resolveInternalField has exactly ONE refusal predicate, and it is not about passwords

packages/objectql/src/engine.ts:5371 —

if (!collectInternalReadFields(schema).includes(field)) { throw INVALID_FIELD }

and collectInternalReadFields (secret-fields.ts:239-247) filters on def.internal === true only. It does not inspect the field's type at all.

⇒ The ADR-0100 / "password is masked deliberately" language is prose inside the error message, explaining why a non-internal field has other channels. It is not a second predicate. Declare sys_account.password as internal: true and it enters collectInternalReadFields, and the accessor accepts it. There is nothing to collide with.

And ADR-0100's subject is a different kind of field

ADR-0100 governs Field.password()-typed fields — masked-by-design plaintext. sys_account.password is declared Field.text() (sys-account.object.ts:264) holding a hash, and this card's own reverse-check found zero Field.password() fields repo-wide. So the carve-out the guard's prose refers to has no instances, here or anywhere.

What that leaves — a repair, not a decision

The one real question is whether better-auth reads these columns back off a result row, which would break sign-in under internal: true. That is the same question #7987 already answered and solved: internalAdapter.findCredentialAccount(userId) does exactly that, and PR #8675 landed the per-object readback table plus the per-column required: false fail-closed treatment for precisely this shape. The card even names the file.

⇒ This is the third application of an established mechanism, not a new contract question. My earlier "human floor, do not dispatch without a ruling" was wrong, and it would have parked a cheap repair behind a ruling nobody needed to make.

The grade stands; the framing changes

pm:queue + domain:metadata + Bug are unchanged and correct. What changes:

• ⛔ No ADR-0100 ruling is needed before dispatch.
• The dispatch still carries the two real traps: the readback path must be recovered through internal-field-readback.ts (a strip without recovery breaks sign-in), and password is required: false, so the "key missing ⇒ strip ran" inference is invalid for it — inherit absenceProvesStrip: false, measured on [security] sys_account stores live third-party OAuth access/refresh/id tokens as plain columns, and the object is API-readable #7987 at the cost of 16 red tests.
• The provenance caveat stands: the persona readings are inherited from [security] sys_account stores live third-party OAuth access/refresh/id tokens as plain columns, and the object is API-readable #7987's measurement, not independently confirmed here.

Nomination for target:v17 unchanged and now better supported — the cost is lower than I represented it.

---

Generated by Claude Code

[qq9340100]

target:v17 applied — maintainer ruling. Queued in normal order, held on a collision.

Maintainer, 2026-08-14, verbatim, untranslated, in the PM session, approving the nomination and recommendation in comment 5294636765 as corrected by 5294658534:

同意

The recommendation approved was: apply target:v17, queue in normal order, ⛔ do not jump the queue. These are one-way hashes with no demonstrated leak beyond the read, so they rank below #8287 (P0) and #8613 (a one-click installation-wide lockout risk).

The card enters this theme's work set. pm:queue + domain:metadata + Bug unchanged.

⚠️ Held on a file collision, not on doubt

#8287 (P0) is in flight and will regenerate the same four platform-objects i18n translation bundles that a change to sys-account.object.ts moves — the sibling PR #8675 touched all four (en, es-ES, ja-JP, zh-CN) for exactly this reason. Two agents regenerating one generated-artifact family in parallel is the collision the batch rule exists to prevent, and generated files conflict silently rather than loudly.

⇒ #8676 goes the moment #8287 lands. Nothing else blocks it: plugin-auth/src/internal-field-readback.ts is file-disjoint from #8613's last-admin-guard.ts and from #8287's managed-extension-fields.ts.

What the dispatch will carry (recorded now so it is not re-derived)

• ⛔ No ADR-0100 ruling is required. Measured: resolveInternalField's only predicate is internal === true (engine.ts:5371 → secret-fields.ts:239-247); the ADR-0100 sentence is error-message prose, not a guard, and sys_account.password is Field.text() with zero Field.password() fields repo-wide.
• The readback must be recovered, not merely stripped — findCredentialAccount(userId) reads password off a result row on the sign-in path. The mechanism is the per-object table in plugin-auth/src/internal-field-readback.ts, landed by PR fix(security): sys_account OAuth access/refresh/id tokens stop serializing on the data API (#7987) #8675.
• password is required: false and genuinely empty on OAuth-only accounts, so "key missing ⇒ the strip ran" is invalid for it. Inherit the per-column absenceProvesStrip: false treatment — [security] sys_account stores live third-party OAuth access/refresh/id tokens as plain columns, and the object is API-readable #7987 measured that cost at 16 red tests.
• Provenance caveat preserved: the persona readings are inherited from [security] sys_account stores live third-party OAuth access/refresh/id tokens as plain columns, and the object is API-readable #7987's measurement, not independently confirmed. Whoever implements should re-measure rather than quote.

---

Generated by Claude Code

[qq9340100]

Correction to the hold rationale — the collision is real, but it is loud, not silent

PM session session_01MX1qcBzfwZb5wkRrJTNbhH. Amending comment 5294674316, which held this card and justified it with "generated files conflict silently rather than loudly."

I measured that claim instead of leaving it standing, and it is wrong for these files. .gitattributes on origin/main assigns merge=os-regen to packages/spec/** artifacts, docs/protocol-upgrade-guide.md, docs/audits/…counts.md and content/docs/references/**. packages/platform-objects/src/apps/translations/*.objects.generated.ts is not on that list. So a clash there produces an ordinary git conflict with markers — the merge queue surfaces it, and nothing is dropped without someone seeing it.

The hold stands, on a smaller and more honest reason

Not "silent loss", but avoiding a predictable conflict and a forced regeneration round on a P0 that is already mid-flight. #8287 will regenerate those bundles; so will this card. Running them in parallel buys nothing and costs a queue rejection plus a re-run.

⇒ Unchanged in effect: #8676 dispatches once #8287 lands. Only the stated reason is corrected.

Related — a miss on my part, recorded because it is the same class

The same check should have been applied to #8149 (in flight, PR #8705): it modifies en.objects.generated.ts, and when I dispatched #8287 I recorded #8149's surface as "plugin-email / messaging" — inferred from the card's subject rather than from what it touches. sys_email is declared in platform-objects, which my own claim comment on #8149 said. #8287's dev has been told, with the measured severity above; the queue will arbitrate if it comes to that.

---

Generated by Claude Code