[BUG] Plaintext Password Storage in Share Feature

Resolved 💬 2 comments Opened Apr 2, 2026 by ian038 Closed May 11, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Share Passwords Stored in Plaintext

Impact: Exposure of sensitive user passwords via logs, memory dumps, or monitoring tools

Problem:

  • Passwords are stored directly in plaintext despite being labeled as a hash.
  • Verification is done using direct string comparison instead of secure methods.
  • This creates multiple risks:
  • Accidental logging of sensitive data (e.g., observability tools)
  • Exposure through crash dumps or memory leaks
  • Increased impact of any server compromise
  • The current implementation explicitly acknowledges the shortcut, indicating it was not intended for production-grade security.

Fix:

  • Replace plaintext storage with secure hashing:
  • Use a strong, adaptive hashing algorithm such as bcrypt or scrypt.
  • Generate and store a unique salt per password.
  • Use constant-time comparison for verification:
  • Prevent timing attacks by avoiding direct string comparison.
  • Ensure secure handling throughout lifecycle:
  • Never log raw passwords or derived hashes.
  • Sanitize sensitive fields in monitoring/telemetry tools.
  • Minimum acceptable fallback (if stronger hashing is not yet implemented):
  • Use a one-way cryptographic hash (e.g., SHA-256) instead of plaintext storage.

---

Risk Summary

  • High likelihood of accidental exposure in real-world environments
  • Severe impact if logs or memory are compromised
  • Violates basic password handling security standards

What Should Happen?

Implementing the fix will:

  • Eliminate plaintext password exposure risks
  • Align with standard security best practices
  • Reduce blast radius in case of system compromise
  • Improve overall trust and reliability of the share feature

Error Messages/Logs

Steps to Reproduce

  1. Create a password-protected conversation share using the share feature.
  2. Enter any password when creating the share link.
  3. Inspect the server-side share storage (in-memory store, database, or logged object).
  4. Observe that the stored value labeled as passwordHash contains the original plaintext password instead of a hashed value.
  5. Attempt to verify the password for the share.
  6. Observe that verification succeeds via direct string comparison rather than hash verification.
  7. Trigger a server log, error report, or crash dump (e.g., via logging, monitoring tools, or exception).
  8. Inspect logs or memory snapshot and confirm the plaintext password is present.

Expected Result

Passwords should be stored as salted hashes and verified using constant-time comparison.

Actual Result

Passwords are stored in plaintext and verified using direct string comparison, making them vulnerable to exposure through logs, memory dumps, or monitoring tools.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.9

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗