This document outlines the security policy for AccountSafe, including supported versions and vulnerability reporting procedures.

Only the latest minor release receives security updates. Users are expected to maintain current versions.

AccountSafe implements a zero-knowledge architecture. Understanding this model is essential for accurate vulnerability assessment.

The server never has access to your plaintext credentials. Here's how it works:

Master Password (client-side only)
        │
        ▼
    Argon2id (memory-hard KDF)
        │
   ┌────┴────┐
   ▼         ▼
auth_key   enc_key
   │         │
   │         └──► AES-256-GCM Encrypt ──► Ciphertext ──► Server stores blob
   │
   └──► SHA-256 ──► auth_hash ──► Server verifies identity

Key Points:

• enc_key (encryption key) never leaves the browser
• auth_hash (authentication hash) is derived separately and only used for identity verification
• Server stores only encrypted blobs; a database breach yields no usable data

AccountSafe supports a secondary "duress password" that reveals a decoy vault containing fake, low-value credentials. If you are forced to reveal your password:

1. Enter your duress password instead of your master password
2. You will be logged in normally (no visible difference)
3. The vault displays fake credentials (Netflix, Spotify, etc.)
4. Your real vault remains completely hidden
5. Optionally, an SOS email is silently sent to a trusted contact

Security Consideration: The duress password should be memorable but distinct from your master password. It should appear plausible under coercion.

Canary Traps are "honey credentials" you can plant in exports or share intentionally. If an attacker attempts to use them:

1. The service receiving the login attempt triggers an alert
2. You receive an email notification with:
   • Timestamp of the access attempt
   • IP address and geolocation
   • User-agent of the attacker's browser
3. You know your data has been compromised before any real damage occurs

WARNING: Do NOT use canary credentials on real services. They are designed to trigger alerts when accessed. Using a canary password on a real account will lock you out.

If you are auditing AccountSafe and discover credentials that appear to trigger alerts, logging mechanisms, or "phone home" behavior-this is by design.

What you may observe:

• API endpoints at /api/security/traps/ that create, list, and trigger honeytokens
• Database entries in CanaryTrap model with fake service names
• Email alerts sent when specific credentials are "used"
• Logging entries with [CANARY TRIGGER] prefixes

These are NOT security vulnerabilities. They are:

1. User-created honeypot credentials for breach detection
2. Part of the documented Active Defense feature set
3. Managed via backend/api/features/security/ module

When to report (real vulnerabilities):

• Ability to trigger another user's canary traps without their credentials
• Canary trap data leakage to unauthenticated users
• Bypass of authentication to access canary management endpoints
• Information disclosure of real credentials via canary mechanisms

If in doubt, reference tests/CANARY_TRAP_TESTING.md for implementation details before filing a report.

Similarly, if you discover a secondary authentication path that reveals different vault contents-this is the Duress Mode (Ghost Vault) feature.

What you may observe:

• DuressSession model tracking special authentication tokens
• is_duress_session() checks throughout vault endpoints
• Fake credential generation for duress logins
• Silent SOS email dispatch functions

These are NOT backdoors. They are:

1. A coercion-protection feature allowing users to reveal fake vaults under duress
2. Documented in user-facing help and this security policy
3. Cryptographically separated from real vault data

When to report (real vulnerabilities):

• Ability to force another user into duress mode
• Real vault data leakage during duress sessions
• Duress mode SOS alerts disclosing sensitive information
• Privilege escalation from duress session to real session

The following are considered security-relevant:

• Client-side encryption implementation (frontend/src/utils/encryption.ts)
• Zero-knowledge authentication (backend/api/features/auth/zero_knowledge.py)
• Key derivation and management
• Authentication and session handling
• Authorization and access control
• Server-side input validation
• Cryptographic parameter choices
• Secret storage and transmission
• Duress mode implementation
• Canary trap trigger mechanism
• Cross-site scripting (XSS) vectors
• Cross-site request forgery (CSRF)
• SQL injection and ORM misuse
• Information disclosure in API responses
• Rate limiting and brute-force protection

The following are not considered vulnerabilities in AccountSafe:

• Attacks requiring physical access to user device
• Social engineering attacks
• Denial of service via resource exhaustion (report separately)
• Vulnerabilities in dependencies (report to upstream)
• Self-XSS requiring user to paste malicious code
• Issues in development/debug configurations
• Theoretical attacks without practical exploit

• Open a public GitHub issue
• Disclose on social media or public forums
• Exploit the vulnerability beyond proof-of-concept
• Access data belonging to other users

Report vulnerabilities privately using one of these methods:

Option 1: GitHub Security Advisories (Preferred)

1. Navigate to the repository on GitHub
2. Click "Security" tab
3. Click "Report a vulnerability"
4. Complete the advisory form

Option 2: Direct Contact

Email: pankajbind30@gmail.com

Use the following PGP key for encrypted communication (optional):

[PGP key to be added]

Include the following in your report:

1. Summary: One-sentence description of the vulnerability.

2. Severity Assessment: Your estimation (Critical/High/Medium/Low) with justification.

3. Affected Component: File path, endpoint, or feature.

4. Reproduction Steps: Minimal, numbered steps to reproduce.

5. Proof of Concept: Code, screenshots, or HTTP requests demonstrating the issue.

6. Impact Analysis: What an attacker could achieve.

7. Suggested Fix: Optional, but appreciated.

Summary: IDOR allows unauthorized access to other users' profiles

Severity: High - Authenticated users can read any profile

Affected Component: /api/profiles/{id}/ endpoint

Steps to Reproduce:
1. Authenticate as user A
2. Note user A's profile ID (e.g., 42)
3. Request GET /api/profiles/43/ (another user's profile)
4. Observe: Response returns profile belonging to user B

Impact: Any authenticated user can enumerate and access all profiles
in the database, exposing encrypted credential blobs.

Suggested Fix: Add owner verification in ProfileViewSet.get_queryset()

We follow a coordinated disclosure process:

1. Reporter submits vulnerability privately.
2. We acknowledge receipt and begin assessment.
3. We develop and test a fix.
4. We prepare a security advisory.
5. We release the patch.
6. We publish the advisory with credit to reporter.
7. Reporter may publish their own writeup after advisory.

Security researchers who report valid vulnerabilities will be credited in:

• The security advisory
• The CHANGELOG
• The project's security acknowledgments (if maintained)

Credit format: Name/handle and optional affiliation, as specified by reporter.

If you wish to remain anonymous, indicate this in your report.

Security patches are released as:

1. Patch releases: Increment the patch version (e.g., 1.2.3 -> 1.2.4)
2. Security advisories: Published via GitHub Security Advisories
3. CHANGELOG entries: Documented with [SECURITY] prefix

Subscribe to repository releases to receive notifications.

• Use HTTPS exclusively; enable HSTS
• Keep Docker images and dependencies updated
• Use strong, unique SECRET_KEY (64+ characters)
• Enable rate limiting at reverse proxy
• Restrict CORS to production origin only
• Run containers as non-root user
• Enable database connection encryption

• Regular encrypted backups
• Monitor authentication logs for anomalies
• Rotate secrets periodically
• Review active sessions
• Keep client browsers updated

For security matters: pankajbind30@gmail.com

For general support: Open a GitHub issue (non-security matters only)