critical: signature challenge is not domain-bound — raw-nonce and SEP-0043 fallback accept cross-service signature replay

[EmeditWeb]

Problem

AuthService.verifySignature() (src/modules/auth/auth.service.ts, lines 112–132) accepts TWO different message formats:

1. Raw Ed25519 over Buffer.from(dto.nonce) — the nonce alone, hex bytes.
2. SEP-0043 fallback: 'Stellar Signing Key: ' + dto.nonce — string concatenation, no domain, no URI, no timestamp.

Neither challenge binds the signature to StepFi. A signature over a raw 64-char hex nonce is trivially obtainable in other contexts (any dApp that asks a user to sign arbitrary data, phishing prompts, other services using the identical raw scheme). An attacker who captures one (nonce, signature) pair valid under either format can authenticate as the victim on StepFi as long as they can insert the same nonce into the nonces table — which they control via generateNonce(): generate a nonce, harvest a matching signature elsewhere, then self-issue the challenge here. The server picks which format to try, so the weakest accepted format defines the security floor.

SEP-0043 exists precisely to fix this: its envelope includes domain, URI, version, issued-at, and expiration. The current implementation uses none of that structure.

Ground Rules

1. Read context/architecture-context.md, context/code-standards.md, context/progress-tracker.md in full
2. Read the full auth flow: generateNonce, verifySignature, generateTokens (auth.service.ts)
3. Preserve mobile-client compatibility OR provide an explicit, documented migration window — state your choice in the PR

What To Build

1. Define a canonical StepFi challenge envelope containing: domain (API origin), wallet, nonce, issued-at, expires-at — signed as UTF-8 text.
2. Implement strict SEP-0043 verification for browser wallets (validate domain == our host, URI, not-expired).
3. For native clients, adopt the canonical envelope and deprecate the raw-hex format behind a config flag with a sunset date.
4. Bind nonce rows to their challenge content: store a hash of the exact expected message alongside the nonce and verify the signature against the stored message only — never against client-supplied alternatives.
5. Tests: legacy-format signatures fail once flag off; SEP-0043 happy path passes; wrong-domain SEP-0043 rejected; expired envelope rejected; replay across environments impossible.

Files To Touch

• src/modules/auth/auth.service.ts
• src/modules/auth/dto/verify-request.dto.ts
• src/config/env.ts / config plumbing for the flag
• tests
• relevant docs/progress tracker

Acceptance Criteria

• Every accepted signature provably signs a StepFi-bound challenge
• Nonce row stores and enforces the exact expected message
• Migration/deprecation path documented and tested
• Suite green

Mandatory Checks Before Opening PR

Standard checklist applies. PRs failing any check will be closed without review.

[mimi-esc]

I'd like to apply for issue.I will fix the signature challenge domain binding vulnerability in auth.service.ts.Ready to start working on this immediately!

[Marvelg256]

Hi! I'd like to work on this issue. I've reviewed the requirements and believe I have a good understanding of what's needed. I'm confident I can implement a clean solution, test it thoroughly, and submit a PR within 48 hours. If assigned, I'll keep the issue updated with my progress.

[sheyman546]

I am interested in this issue because reliability is critical for a system that handles sessions, real-time communication, idempotency, and especially financial data. A failure in Redis or PostgreSQL should not bring down the entire system.

My experience with backend and Web3 development has involved working with databases, APIs, smart contracts, TypeScript, Git/GitHub, and systems where data consistency and reliability are important. I am comfortable investigating an existing codebase, understanding how its services depend on Redis and PostgreSQL, and identifying failure points.

For this issue, I would focus on implementing reliable health checks, automated failover, safe primary promotion, and split-brain prevention. I would also test failure scenarios to ensure the system can recover without corrupting sessions, cached data, idempotency state, or the money ledger.

I am motivated by the opportunity to work on a critical infrastructure problem and deliver a solution that improves the system's resilience, availability, and data safety.

[grantfox-oss]

🦊 GrantFox — @Marvelg256 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #118)
2. Your PR will be reviewed by the StepFi-app maintainers

Good luck! Track your progress on GrantFox.