Security Recommendations

Note

When using ALTCHA Sentinel, challenge expiration and rate limiting are already integrated.
However, you should still implement a registry for used server signatures when using cryptographic libraries to prevent replay attacks.

Replay Attacks

To defend against replay attacks, where a client resubmits a previously valid solution, your server must ensure that each challenge is single-use.

Maintain a registry (e.g., an in-memory store or database) of solved challenges and reject any attempt to reuse a challenge that has already been accepted.

It is recommended to use a short challenge expiration to ensure that challenges are invalidated after they expire. In combination with expiration, your registry of used challenges can automatically discard entries after the same duration. As a general guideline, set the expiration time between 20 minutes and 1 hour.

Replay Attacks with Server Signatures

When using Sentinel, your backend receives a server signature instead of a proof-of-work solution. This signature must be cryptographically verified.

To prevent reuse, maintain a registry of used payloads. Use the unique id parameter included in the payload and the signed verificationData object as a key in this registry.

Sentinel assigns a default challenge expiration time of 20 minutes, which can be adjusted using the expires parameter in the Security Group settings. The registry of used payloads should retain entries for the same duration as the challenge expiration time.

verify.js

// Use LRU cache or Redis-backed registry instead
const registry = new Map();

const { verificationData, verified } = await verifyServerSignature(payload, apiKeySecret);

if (verified) {
  if (registry.has(verificationData.id)) {
    throw new Error("Payload already used.");
  }
  registry.set(verificationData.id, true);
  // Verification successful - process the submission
}

Alternatively, you can use the POST /v1/verify/signature endpoint, which includes built-in protection against replay attacks.

Challenge Expiration

Challenge expiration prevents challenges from being reused after a certain period. This adds a layer of security by limiting the window of opportunity for an attacker.

A simple and effective approach is to embed a server-side timestamp into the challenge’s salt when generating it.

Use the ?expires=<unix_ts> parameter in the salt, as described in the salt parameters section. The widget will automatically detect this parameter. Your server must then verify that the current time has not passed the expires timestamp during challenge verification.

Rate Limiting

Implement rate limiting to reduce the risk of brute-force or denial-of-service (DoS) attacks. This ensures that malicious clients cannot overwhelm your system with repeated requests.