Skip to content

Security: dibyx/concealment-docs

Security

SECURITY.md

Security Policy for Concealment

πŸ”’ Reporting a Vulnerability

At Concealment, we take security seriously. If you discover a security vulnerability, please report it responsibly rather than disclosing it publicly. Your help in protecting our users is deeply appreciated.

⚠️ What to Report

We're interested in reports of:

  • Cryptographic weaknesses (e.g., flawed key generation, improper encryption implementation)
  • Authentication bypasses (e.g., ways to access accounts without credentials)
  • Private key exposure (e.g., plaintext key storage, insecure passphrases)
  • Data leaks (e.g., plaintext messages stored on servers)
  • Zero-day vulnerabilities in dependencies (OpenPGP.js, Firebase, etc.)
  • Timing attacks or other side-channel attacks on crypto operations
  • XSS/Injection vulnerabilities in the web client
  • Denial of Service vectors that compromise service availability
  • Privilege escalation bugs (e.g., accessing other users' encrypted data)
  • Compliance issues (e.g., violations of GDPR, privacy frameworks)

βœ… Out of Scope

We appreciate your help, but the following are not security issues:

  • General UI/UX improvements or feature requests
  • Performance optimizations without security implications
  • Missing security headers (we handle these separately)
  • Third-party service misconfiguration (Firebase, Railway, etc.)
  • Social engineering or phishing attacks
  • Reports about competitors' security practices
  • Vulnerabilities in your own systems or dependencies you control

πŸ“‹ How to Report a Vulnerability

Step 1: Use the Secure Reporting Form

Please report all security vulnerabilities using this form:

πŸ”— Concealment Security Report Form

The form captures:

  • Your contact information (name, email)
  • Vulnerability description
  • Steps to reproduce (if applicable)
  • Proof of concept (if available)
  • Impact assessment
  • Suggested fixes (optional)

Step 2: What Happens Next

  1. Acknowledgment (within 24-48 hours)

    • We'll confirm receipt of your report
    • Assign a reference number for tracking
    • Ask clarifying questions if needed
  2. Investigation (1-2 weeks)

    • Our security team investigates the issue
    • We verify the vulnerability in our code
    • We assess the severity and impact
  3. Fix Development (severity-dependent)

    • Critical (CVSS 9-10): Fix within 7 days
    • High (CVSS 7-8): Fix within 14 days
    • Medium (CVSS 4-6): Fix within 30 days
    • Low (CVSS 1-3): Fix within 60 days
  4. Notification (before public disclosure)

    • We'll notify you when the fix is deployed
    • You'll receive security advisory details
    • We'll credit you in our security advisories (if desired)
  5. Public Disclosure

    • We publish a security advisory on GitHub
    • We update our dependencies
    • We document lessons learned

🚨 Severity Levels & Response Times

We use CVSS v3.1 to assess vulnerability severity:

Severity CVSS Score Response Time Example
Critical 9.0-10.0 24-48 hours Private key exposed in source code
High 7.0-8.9 1-2 weeks Bypass of encryption mechanism
Medium 4.0-6.9 2-4 weeks Weak passphrase validation
Low 0.1-3.9 4-8 weeks Minor UI information leak

πŸ›‘οΈ Security Contact Information

Note: We monitor the Google Form actively. If you don't hear back within 48 hours, please send an email to security@concealment.live as a backup.


🀝 Responsible Disclosure Guidelines

When reporting a vulnerability, please:

βœ… DO:

  • Report vulnerabilities directly via the secure form or email
  • Be clear and detailed in your description
  • Provide proof-of-concept code if possible
  • Give us time to fix before public disclosure (at least 90 days)
  • Encrypt sensitive communications with our PGP key (see below)
  • Test in a staging environment, not production

❌ DON'T:

  • Publicly disclose the vulnerability on social media, forums, or issue trackers
  • Access other users' encrypted data
  • Modify, delete, or exfiltrate data from our systems
  • Launch denial-of-service attacks
  • Demand payment or publicity (we credit you voluntarily)
  • Report via unencrypted channels for highly sensitive issues

πŸ” PGP Key for Secure Communication

For highly sensitive vulnerability reports, you may encrypt your submission using our PGP key:

-----BEGIN PGP PUBLIC KEY BLOCK-----

[Your PGP key block here]

-----END PGP PUBLIC KEY BLOCK-----

Key ID: ABCD 1234 5678 90EF GHIJ
Fingerprint: ABCD 1234 5678 90EF GHIJ KLMN OPQR STUV WXYZ


🎁 Bug Bounty & Rewards

Concealment is a non-commercial, community-driven security project. While we don't currently offer financial bounties, we:

  • Credit you publicly in our security advisories (if desired)
  • Feature you on our website as a security contributor
  • Provide early access to features and beta releases
  • Collaborate on deeper security research

If you've found a critical vulnerability and would like to discuss a bounty, please contact security@concealment.live directly.


πŸ“š Security Best Practices for Users

While we work hard to keep Concealment secure, users should also:

Key Management

  • βœ… Use strong, unique passphrases (12+ characters, mixed case, numbers, symbols)
  • βœ… Never share your passphrase or private key with anyone
  • βœ… Write down your passphrase in a safe place (we can't recover it)
  • βœ… Rotate keys periodically if you suspect compromise

Device Security

  • βœ… Keep your device OS and browser updated
  • βœ… Use device-level encryption (BitLocker, FileVault, LUKS)
  • βœ… Enable biometric locks or strong PINs
  • βœ… Be cautious of malware and keyloggers

Usage Patterns

  • βœ… Verify fingerprints out-of-band before trusting new contacts
  • βœ… Use self-destruct timers for sensitive conversations
  • βœ… Don't reuse passphrases from other services
  • βœ… Assume your device may be compromised and act accordingly

Threat Model Awareness

  • βœ… Concealment prevents content interception and server compromise
  • ⚠️ Concealment does NOT prevent device compromise or metadata leaks
  • ⚠️ Timestamps and participant IDs are still visible in Firestore
  • ⚠️ A malicious recipient can still read messages they decrypt

πŸ”„ Security Update Cycle

We follow these practices to keep Concealment secure:

Continuous Monitoring

  • Dependency scanning for vulnerable packages (npm audit, GitHub Dependabot)
  • Code review of all pull requests by security-trained developers
  • Static analysis (linting, type checking) on every commit
  • Security testing before major releases

Regular Updates

  • Monthly: Update dependencies and patch packages
  • Quarterly: Security audit of critical components
  • Annually: Third-party penetration testing (planned Phase 2+)
  • As-needed: Emergency patches for critical vulnerabilities

Deprecation Policy

  • We support the latest stable release and the previous major version
  • Security patches are released for the current and previous versions
  • Older versions should be upgraded immediately
  • End-of-life announcements are made 90 days in advance

πŸ§ͺ Testing & Verification

What We Test

  • βœ… Cryptographic operations – Key generation, encryption, decryption, signing
  • βœ… Authentication flows – Signup, login, session management
  • βœ… Access control – Users can only see their own conversations
  • βœ… Data encryption – Messages stored as ciphertext, never plaintext
  • βœ… Input validation – XSS, injection, and buffer overflow prevention
  • βœ… Dependency security – Vulnerable packages and known exploits

How to Verify

Users can verify Concealment's security:

  1. Inspect network traffic – Use browser dev tools to see encrypted payloads
  2. Review source code – All client-side crypto is visible in browser DevTools
  3. Check Firestore rules – Review security rules in Firebase Console
  4. Audit dependencies – Run npm audit or flutter pub outdated
  5. Test encryption – Generate a key, encrypt a message, verify ciphertext

πŸ“– Security Documentation

For deeper security details, see:

Threat Model

Concealment Protects Against:

  • βœ… Server compromise – Attacker reads Firestore; still sees only ciphertext
  • βœ… Man-in-the-middle – Attacker intercepts messages; encrypted with PGP
  • βœ… Passive surveillance – Network observer sees only encrypted blobs
  • βœ… Malicious admins – Admins cannot decrypt messages without private keys
  • βœ… Future compromise – RSA-4096 keys remain secure for 20+ years

Concealment Does NOT Protect Against:

  • ❌ Device compromise – Malware on your device can read plaintext
  • ❌ Metadata leaks – Timestamps and participant IDs are visible
  • ❌ Malicious recipient – They can read messages they decrypt
  • ❌ Quantum computers – Future quantum attacks on RSA (Phase 3 will add post-quantum)
  • ❌ Social engineering – Tricking you into sharing your passphrase

πŸš€ Roadmap: Future Security Improvements

  • Phase 2: Post-quantum cryptography (Kyber, Dilithium)
  • Phase 2: Third-party security audit
  • Phase 3: Hardware security module (HSM) support
  • Phase 3: Decentralized infrastructure options
  • Phase 3: Zero-knowledge proofs for metadata privacy

πŸ“ž Questions or Concerns?

If you have questions about this policy, security practices, or vulnerability reporting:

πŸ“§ Email: security@concealment.live
πŸ”— Form: Concealment Security Report
πŸ’¬ GitHub Discussions: https://github.com/dibyx/concealment-docs/discussions


πŸ“‹ Version History

Version Date Changes
1.0 2025-12-24 Initial security policy

πŸ™ Thank You

We deeply appreciate the security community's support in keeping Concealment safe. Your responsible disclosure helps us protect millions of users' privacy and security.

Together, we're building encryption that works. πŸ”


Last Updated: December 24, 2025
Status: Active
Next Review: June 24, 2026

There aren't any published security advisories