René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[BUG] Password-protected deployment auth tokens can be forged","articleBody":"**Describe the bug**\n\nPassword-protected chat and form deployments use a base64-encoded authentication token that is not signed or bound to a server-side secret. The token format is:\n\n```text\ndeploymentId:type:timestamp:truncatedPasswordHash\n```\n\nThe password hash is `sha256(encryptedPassword).substring(0, 8)`, which gives only 32 bits of search space. `validateAuthToken()` accepts any token whose deployment ID matches, whose timestamp is within 24 hours, and whose 8-character password hash matches the current encrypted password value. Because the token is not authenticated with an HMAC/signature, a token can be created outside the server once the 32-bit hash value is guessed.\n\nAffected code:\n\n- `apps/sim/lib/core/security/deployment.ts`\n  - `hashPassword()` truncates SHA-256 to 8 hex characters.\n  - `encryptAuthToken()` returns plain base64 of the token fields.\n  - `validateAuthToken()` validates field equality but does not verify a server-side signature.\n- `apps/sim/app/api/chat/utils.ts`\n  - `validateChatAuth()` trusts `chat_auth_\u003cdeploymentId\u003e` when `validateAuthToken()` returns true.\n- `apps/sim/app/api/form/utils.ts`\n  - `validateFormAuth()` trusts `form_auth_\u003cdeploymentId\u003e` when `validateAuthToken()` returns true.\n- `apps/sim/app/api/chat/[identifier]/route.ts` and `apps/sim/app/api/form/[identifier]/route.ts`\n  - GET handlers return full deployment configuration when the forged cookie validates.\n\nThis was verified on commit `7b572f1f61a8bbcee31fd7389097814a71f8f094` and the same vulnerable implementation is still present in fetched `origin/main` at `e532e0a6da6fd22eee98310ba44e4fe50dec174a`.\n\n**To Reproduce**\n\nUse only a local/synthetic deployment ID and encrypted password value. Do not run this against production systems.\n\n1. Inspect `apps/sim/lib/core/security/deployment.ts`.\n2. Compute the same password hash used by the application:\n\n```js\nconst { createHash } = require('crypto')\nconst encryptedPassword = 'synthetic-encrypted-password-ciphertext'\nconst pwHash = createHash('sha256').update(encryptedPassword).digest('hex').substring(0, 8)\n```\n\n3. Construct a token outside the server:\n\n```js\nconst deploymentId = 'dep_safe_local_test'\nconst token = Buffer.from(`${deploymentId}:password:${Date.now()}:${pwHash}`).toString('base64')\n```\n\n4. Pass the token to the same validation logic:\n\n```js\nvalidateAuthToken(token, deploymentId, encryptedPassword) === true\n```\n\n5. A wrong hash is rejected and an expired timestamp is rejected, confirming that the acceptance condition is exactly the forgeable 8-character hash plus a fresh timestamp.\n\nLocal verification result:\n\n```text\nhash_bits=32\ncandidate_space=4294967296\nforged_fresh_valid=true\nwrong_hash_valid=false\nexpired_valid=false\n```\n\n**Expected behavior**\n\nDeployment authentication cookies should be unforgeable by clients. A token should only validate if it was issued by the server and protected with a server-side secret, such as an HMAC-signed payload, authenticated encrypted token, signed JWT with strict claims, or an opaque server-side session ID.\n\nThe password hash should not be used as a bearer capability. If a stateless token is required, validation should verify a cryptographic signature using constant-time comparison and should bind the token to the deployment ID, auth type, expiration, and any relevant session/version state.\n\n**Screenshots**\n\nNot applicable. The issue is in token construction and validation logic.\n\n**Additional context**\n\nSecurity impact:\n\n- Unauthorized access to password-protected chat/form deployments is possible if an attacker knows the deployment identifier and can find the 32-bit truncated password hash.\n- The public deployment identifier is exposed through deployment URLs.\n- A valid forged cookie can make protected GET routes return full deployment configuration and can allow POST flows to proceed as authenticated.\n- Since the timestamp is client-controlled and only checked for recency, an attacker who finds the hash can mint fresh tokens until the password/encrypted password value changes.\n\nRecommended remediation:\n\n- Replace plain base64 tokens with HMAC-signed tokens or opaque server-side session IDs.\n- Remove the truncated password hash from client-controlled token material.\n- Add rate limiting and monitoring for failed deployment-auth attempts.\n- Consider rotating deployment auth/session material after deploying a fix.\n\nDisclosure note:\n\nThe repository contains `.github/SECURITY.md`, which asks reporters to email `security@sim.ai` and not disclose vulnerabilities publicly. This file follows the repository's bug-report template for private maintainer handling rather than public issue publication.","author":{"url":"https://github.com/3em0","@type":"Person","name":"3em0"},"datePublished":"2026-05-27T12:32:31.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/4759/sim/issues/4759"}