[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
bcryptorscrypt. - 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
- Create a password-protected conversation share using the share feature.
- Enter any password when creating the share link.
- Inspect the server-side share storage (in-memory store, database, or logged object).
- Observe that the stored value labeled as
passwordHashcontains the original plaintext password instead of a hashed value. - Attempt to verify the password for the share.
- Observe that verification succeeds via direct string comparison rather than hash verification.
- Trigger a server log, error report, or crash dump (e.g., via logging, monitoring tools, or exception).
- 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_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗