Repository navigation
Require server-verifiable CAPTCHA policy at authentication entry points #183
Description
Follow-up to #156/#157; source 385e7679fabc60b80cd65cf0a1aa4cdf3d592514, reviewed 2026-10-23. The security inventory records bounded evidence, not deployed-site clearance.
Priority: P1 abuse-control correction. This is not an account-session bypass by itself.
Evidence: the verifier accepts any six-character uppercase alphanumeric string. The sweep's isolated probe returned arbitraryCaptchaAccepted: true; that code is unchanged. Password login and signup also skip verification when no payload is supplied. REST magic-link/reset routes use the same verifier.
Bounded reproduction: invoke the helper locally with a matching synthetic code never issued by a challenge service; it returns true. Direct GraphQL login without captchaPayload reaches password verification. A correct password is still necessary. No hosted request or email delivery was tested.
PR #171 already implements failed password-attempt/IP limits and alias concurrency; do not reopen the historical missing-limiter finding. Its process-local deployment limit remains explicit.
Acceptance criteria:
- Specify which authentication actions require a challenge and enforce that policy server-side for direct REST/GraphQL requests.
- Remove format-only success. Validate authentic proof, expiry and action; bound replay according to the chosen protocol. Reject missing/forged/expired proofs before identity issuance or email delivery. Reject the known ALTCHA signing-key fallback in production configuration.
- Add isolated helper/API negative tests and one valid challenge flow; preserve password/IP-limit and alias/concurrency regressions.
- Update the UI to obtain the same verifiable proof and test accessible retry/error handling. Record exact source, negative controls and limits in the repo.
No new provider, external account, permission expansion, shared DB or live-site probe is required for this fix.
Activity
mvalancy commentedon Oct 27, 2026
Claimed for implementation in owned branch/worktree
fix/server-captcha-20261027/core-server-captcha-20261027, based on live devef495eff15ed7aac51e72dc7a1db1bb96d2b3695. Please coordinate before editing the CAPTCHA helpers, auth resolver or sign-in/reset forms; #184 token/OAuth work remains separately available.The new negative regression fails against the original helper because
ABC123is accepted. The implementation removes format-only success, binds server-issued ALTCHA proofs to action and expiry, enforces production login/signup policy, rejects replay atomically, caps outstanding challenges including concurrent issuance, and rejects the old signing-key fallback. Default signing keys are random per process; restart invalidates outstanding challenges, and a multi-instance deployment would need a shared/sticky challenge contract. No provider account is needed.Current local evidence: nine helper/policy cases, ten existing password-limit cases, 21 existing production-secret cases and three actual HTTP GraphQL/SQLite cases pass. Three UI component tests pass for proof expiry/reset and accessible policy failure/retry. Production-mode REST/browser validation and independent review are in progress. No deployment or completion is claimed. The UI preserves Cloud's existing advertised backend contract; this does not establish hosted parity or close #182.
mvalancy commentedon Oct 28, 2026
Server-verifiable, action-bound, expiring, single-use CAPTCHA policy and its accessible client challenge flow are integrated through #195. Direct API/helper negative controls, valid proofs, replay limits and production signing-key rejection are recorded in that PR and canonical repo evidence.
Verified integrated
devhead:780a7599d1d7949d5e0fac56091f0b07bb0e6e0d, complete treecffa8b8a7903b9609603f1c42978511d900678f6, identical to independently reviewed and tested source525ca4e5aa5bd4a918ad85165d0f2a0e8caf59ac.Final integrated CI and Comprehensive Tests passed every applicable job. Downloaded strict reports contain smoke 6, new-user 42, LOD 2, routes 7, mobile 27 and performance 3 passing cases, with zero failures, warnings, skipped cases, evidence errors, timeouts or nonzero exits. Both supported Node versions, real Neo4j, all three runtime images, effects and showcase passed. The main/nightly-only production job was inapplicable to this dev run; it is not credited as a pass. Earlier failures and cancelled intermediate runs remain retained.
Integration used the owner's standing dev-only native admin authorization after independent exact-head review; that is not a non-author GitHub approval. Main remains
775362eace0723c57b7ba3c7936645c9d0d36cb4. No release, deployment or protection change occurred. Closing this bounded implementation issue after final branch acceptance, not claiming hosted or deployed-site clearance.