[SEC] Implement SEP-10 Challenge-Response Authentication for Stellar Wallet Verification

[Queenode]

🔴 Priority: Critical
Difficulty: Hard
Estimated Effort: 3-4 days
Relevant Files: src/services/stellar.service.ts, src/controllers/bot.controller.ts, src/routes/bot.routes.ts
Labels: security, enhancement, priority:critical, stellar

Requirements

1. SEP-10 Challenge-Response Implementation
   Implement the full SEP-10 authentication flow to cryptographically prove wallet ownership before any financial operation:

   • Challenge Phase (POST /auth/challenge)

     • Generate a challenge transaction signed by a server-owned "auth server" Stellar account
     • Include a cryptographically random nonce (at least 32 bytes of crypto.randomBytes() entropy)
     • Set timeBounds with min = now - threshold and max = now + threshold (threshold defaults to 300 seconds)
     • Store the nonce in Redis with a TTL matching the challenge expiry
     • Return the XDR-encoded challenge transaction to the client

   • Verify Phase (POST /auth/verify)

     • Accept the signed challenge transaction XDR from the client
     • Decode the XDR and extract the client's signature
     • Verify the signature against the Stellar network using @stellar/stellar-sdk
     • Validate that the nonce matches a stored, unused challenge
     • Validate that the challenge is within the timeBounds window
     • Delete the used nonce from Redis (single-use enforcement)
     • Link the verified Stellar public key to the user's Prisma User record

2. Clock Skew Tolerance

   • Handle up to 60 seconds of clock skew between the server and the Stellar ledger
   • Log a warning if clock skew exceeds 30 seconds
   • Reject challenges where now - threshold > tx.timeBounds.min or tx.timeBounds.max > now + threshold

3. Network Resilience

   • Circuit breaker pattern for Horizon API calls: if Horizon returns 5xx or times out 3 times consecutively, stop making requests for 30 seconds
   • Timeout handling: Horizon calls must timeout after 5 seconds. Return 503 Service Unavailable if Horizon is unreachable
   • Retry logic: Retry failed Horizon signature verification up to 2 times with exponential backoff (1s, 2s)

4. Network Awareness

   • Support both testnet and mainnet network passphrases via config.STELLAR_NETWORK
   • The auth server account must be different for testnet vs mainnet
   • Network passphrase must come from config, not hardcoded

5. Security Hardening

   • Challenge nonces must be at least 32 bytes of crypto.randomBytes() entropy
   • Nonces expire after 5 minutes (configurable via CHALLENGE_TTL_SECONDS)
   • Used nonces are deleted immediately after verification (single-use)
   • Failed verification attempts are logged with the attempting wallet address
   • Implement rate limiting on the verify endpoint: max 10 failed attempts per wallet per minute

6. Testing Requirements

   • Unit tests: Mock @stellar/stellar-sdk — test challenge generation, signature verification, nonce lifecycle
   • Integration tests using supertest with mocked Horizon responses for:
     • Valid login flow (challenge → sign → verify → link wallet)
     • Expired challenge (should reject)
     • Already-used nonce (should reject)
     • Wrong network passphrase (should reject)
     • Forged signature (should reject)
     • Horizon timeout (should return 503)
   • Target: >80% code coverage on auth module

---

[OpensrcLord]

Hello @maintainer, I’d like to work on this issue. I have experience handling similar tasks and can start immediately. And I will deliver at the shortest possible time.

[devprom6]

I'd like to work on this issue because it implements one of the most important security features in a Stellar-based application: cryptographically proving wallet ownership using the SEP-10 authentication standard. A correct implementation protects every subsequent financial operation and requires careful handling of signatures, replay protection, network failures, and operational resilience.

My approach would be to implement the complete challenge-response lifecycle in line with the SEP-10 specification. For challenge generation, I'd create a server-signed challenge transaction using a dedicated authentication account selected from configuration based on the configured Stellar network. Each challenge would include a cryptographically secure nonce generated with crypto.randomBytes(), appropriate timeBounds, and a configurable expiration. The nonce would be stored in Redis with a matching TTL so it can be validated exactly once during verification.

For verification, I'd decode the signed XDR using @stellar/stellar-sdk, verify the client's signature against the configured network passphrase, validate the challenge time window while allowing the specified clock skew tolerance, confirm the nonce is valid and unused, and immediately delete it after successful verification to prevent replay attacks. Once verification succeeds, the authenticated Stellar public key would be linked to the corresponding user record. Failed verification attempts would be logged with the attempted wallet address, and I'd enforce per-wallet rate limiting on repeated failures to reduce brute-force attempts.

To improve reliability, I'd build resilience into the Horizon integration by introducing request timeouts, bounded retries with exponential backoff, and a circuit breaker that temporarily stops outbound verification requests after repeated server failures. This ensures the authentication service fails predictably when Horizon is unavailable rather than blocking requests indefinitely or overloading an unhealthy endpoint.

Finally, I'd add comprehensive unit and integration tests covering challenge creation, nonce lifecycle, replay prevention, expired challenges, incorrect network passphrases, forged signatures, Horizon failures, and the complete successful authentication flow using mocked Stellar SDK and Horizon responses. After implementation, I'd run the project's full test suite to verify the feature integrates cleanly and meets the requested coverage target without introducing regressions.

[Primex-hub]

I would love to solve this issue and I can submit within 24hrs