Threat Analysis

Security Model & Threat Analysis

What CryptoCloud's zero-knowledge architecture protects against, what it doesn't, and honest analysis of security tradeoffs.

What "Zero-Knowledge" Means

Zero-knowledge means the server operator (backend + database + storage) has zero knowledge about your actual data.

Server CANNOT See:

Your actual password
Your master encryption key
File contents (encrypted client-side)
Individual file encryption keys
Your RSA private key

Server CAN See:

Username and email (plaintext)
File metadata (name, size, upload time)
Encrypted blobs in S3
Encrypted file keys (wrapped)
Share relationships (who shared with whom)
Access patterns (login times, IP addresses)

✅ Protected Against

Curious Server Operator

Even malicious server admins cannot read file contents. Database access reveals only encrypted data and metadata.

Database Breach

Attacker gets encrypted blobs, encrypted keys, and metadata. Without user passwords, data remains unreadable.

S3 Storage Breach

S3 bucket leak exposes AES-256-GCM encrypted files. No decryption keys stored alongside files.

Network Eavesdropping

All communication encrypted via TLS. Even if TLS is broken, additional client-side encryption protects files.

Malicious Insider

Insider with database access cannot decrypt files without user passwords. Cannot impersonate users (JWT expiration + 2FA).

Compromised Backend (Limited)

Attacker can steal encrypted data but cannot decrypt existing files. Master keys never touch server memory.

❌ NOT Protected Against

Important: These Are Inherent Limitations

These vulnerabilities are fundamental to web-based E2EE systems. They require user awareness and cannot be fully mitigated without native applications.

🔴 Compromised Client Device

If user's browser or device is compromised, attacker can steal keys from memory or use keyloggers to capture passwords during entry.

Risk Level: CRITICAL

Mitigation: Antivirus, OS updates, trusted devices only

🔴 Malicious Frontend Code (Supply Chain Attack)

If Next.js app is compromised, attacker controls crypto logic. Server could serve modified JavaScript to steal keys from future logins.

Risk Level: CRITICAL

Mitigation: Subresource Integrity (SRI), code audits, browser extension, open-source transparency

⚠️ Metadata Analysis

Server sees file sizes, access patterns, folder structures. Sophisticated traffic analysis could infer behaviors.

Risk Level: MEDIUM

Tradeoff: Metadata visibility enables server-side features (search, sorting, quota)

⚠️ Password Guessing (Weak Passwords)

PBKDF2 with 100k iterations slows attacks but doesn't prevent them. bcrypt makes offline cracking difficult but not impossible.

Risk Level: MEDIUM

Mitigation: Enforce strong passwords, 2FA, rate limiting

⚠️ Denial of Service

Server can refuse service, delete data, or lock accounts. User must trust server availability (not confidentiality).

Risk Level: LOW

This is inherent to any centralized service

⚠️ Social Engineering

Phishing attacks to steal passwords or trick users into running malicious code. No technical defense.

Risk Level: LOW-MEDIUM

Mitigation: User education, 2FA

Scenario: Database Breach

What Attacker Gets:

User records: username, email, bcrypt hashed passwords, encrypted RSA private keys, RSA public keys
File metadata: filenames, sizes, upload times, folder structure, encrypted file keys
Share records: who shared with whom, encrypted file keys for recipients
Public share links: tokens, expiration times, password hashes (if set)

What Attacker CANNOT Do:

Decrypt files (encrypted keys require master key derived from password)
Derive master keys (requires original password + PBKDF2 derivation)
Crack passwords easily (bcrypt + SHA-256 pre-hash slows brute force significantly)
Access RSA private keys (encrypted with master key)

Possible Attacks:

Offline password cracking: bcrypt slows this significantly (cost factor 12+ makes each attempt expensive)
Metadata analysis: who uploaded what, file sizes, sharing patterns, timing analysis
Correlation attacks: linking users based on share patterns and access times

Scenario: S3 Storage Breach

What Attacker Gets:

Encrypted file blobs (AES-256-GCM ciphertext)
S3 keys (paths like uploads/user_id/uuid)

What Attacker CANNOT Do:

Decrypt files (no encryption keys stored in S3)
Link blobs to specific users (UUIDs are random)
Extract metadata (stored in separate database)

Known Weaknesses & Limitations

⚠️ CRITICAL: Frontend Trust Problem

Users must trust the JavaScript code served by the server. Compromised server could serve malicious frontend to steal keys.

Mitigation: Browser extension, Electron app, or code signing required for true zero-trust

⚠️ Static PBKDF2 Salt

All users with same password derive same master key. Enables rainbow table attacks.

Fix: Generate random salt per user, store in database, send to client before login

⚠️ No Secure Memory Wiping

JavaScript cannot securely zero memory. Keys may remain in RAM after logout.

Mitigation: Close browser tab to clear memory, use private browsing

⚠️ No JWT Revocation

Stolen tokens valid until expiration. No blacklist or logout mechanism.

Fix: Implement token revocation list in Redis

⚠️ Password Reset = Data Loss

Zero-knowledge means lost password = lost data. No recovery mechanism possible.

Intentional: Core tradeoff of zero-knowledge architecture. User education critical.

Design Tradeoffs

✅ Benefit

Metadata in plaintext enables server-side search, sorting, quota management, and folder navigation.

⚠️ Cost

Server can see filenames, sizes, folder structures, and access patterns. Enables traffic analysis.

✅ Benefit

JWT authentication is stateless, scales horizontally, no session store needed.

⚠️ Cost

Cannot revoke tokens before expiration. Stolen tokens remain valid until timeout.

✅ Benefit

Public link file key in URL fragment (#key=...) enables zero-knowledge public sharing without server seeing key.

⚠️ Cost

URL fragment could leak via browser history, copy-paste to insecure channels, or screen sharing.

Security Recommendations

For Users:

• Use a strong, unique password (20+ characters)
• Enable 2FA (TOTP) for all accounts
• Use trusted devices only
• Close browser tabs after use
• Verify HTTPS certificate before login
• Don't share public links via unencrypted channels

For Developers:

• Implement per-user PBKDF2 salt
• Add JWT revocation with Redis
• Deploy Subresource Integrity (SRI)
• Add Content Security Policy headers
• Implement rate limiting
• Set up immutable audit logs

Continue Reading

← Architecture

Backend design, MongoDB schemas, upload/download pipelines

Cryptography →

AES-GCM, RSA-OAEP, PBKDF2 implementation details

What "Zero-Knowledge" Means

Zero-knowledge means the server operator (backend + database + storage) has zero knowledge about your actual data.

Server CANNOT See:

Your actual password
Your master encryption key
File contents (encrypted client-side)
Individual file encryption keys
Your RSA private key

Server CAN See:

Username and email (plaintext)
File metadata (name, size, upload time)
Encrypted blobs in S3
Encrypted file keys (wrapped)
Share relationships (who shared with whom)
Access patterns (login times, IP addresses)

✅ Protected Against

Curious Server Operator

Even malicious server admins cannot read file contents. Database access reveals only encrypted data and metadata.

Database Breach

Attacker gets encrypted blobs, encrypted keys, and metadata. Without user passwords, data remains unreadable.

S3 Storage Breach

S3 bucket leak exposes AES-256-GCM encrypted files. No decryption keys stored alongside files.

Network Eavesdropping

All communication encrypted via TLS. Even if TLS is broken, additional client-side encryption protects files.

Malicious Insider

Insider with database access cannot decrypt files without user passwords. Cannot impersonate users (JWT expiration + 2FA).

Compromised Backend (Limited)

Attacker can steal encrypted data but cannot decrypt existing files. Master keys never touch server memory.

❌ NOT Protected Against

Important: These Are Inherent Limitations

These vulnerabilities are fundamental to web-based E2EE systems. They require user awareness and cannot be fully mitigated without native applications.

🔴 Compromised Client Device

If user's browser or device is compromised, attacker can steal keys from memory or use keyloggers to capture passwords during entry.

Risk Level: CRITICAL

Mitigation: Antivirus, OS updates, trusted devices only

🔴 Malicious Frontend Code (Supply Chain Attack)

If Next.js app is compromised, attacker controls crypto logic. Server could serve modified JavaScript to steal keys from future logins.

Risk Level: CRITICAL

Mitigation: Subresource Integrity (SRI), code audits, browser extension, open-source transparency

⚠️ Metadata Analysis

Server sees file sizes, access patterns, folder structures. Sophisticated traffic analysis could infer behaviors.

Risk Level: MEDIUM

Tradeoff: Metadata visibility enables server-side features (search, sorting, quota)

⚠️ Password Guessing (Weak Passwords)

PBKDF2 with 100k iterations slows attacks but doesn't prevent them. bcrypt makes offline cracking difficult but not impossible.

Risk Level: MEDIUM

Mitigation: Enforce strong passwords, 2FA, rate limiting

⚠️ Denial of Service

Server can refuse service, delete data, or lock accounts. User must trust server availability (not confidentiality).

Risk Level: LOW

This is inherent to any centralized service

⚠️ Social Engineering

Phishing attacks to steal passwords or trick users into running malicious code. No technical defense.

Risk Level: LOW-MEDIUM

Mitigation: User education, 2FA

Scenario: Database Breach

What Attacker Gets:

User records: username, email, bcrypt hashed passwords, encrypted RSA private keys, RSA public keys
File metadata: filenames, sizes, upload times, folder structure, encrypted file keys
Share records: who shared with whom, encrypted file keys for recipients
Public share links: tokens, expiration times, password hashes (if set)

What Attacker CANNOT Do:

Decrypt files (encrypted keys require master key derived from password)
Derive master keys (requires original password + PBKDF2 derivation)
Crack passwords easily (bcrypt + SHA-256 pre-hash slows brute force significantly)
Access RSA private keys (encrypted with master key)

Possible Attacks:

Offline password cracking: bcrypt slows this significantly (cost factor 12+ makes each attempt expensive)
Metadata analysis: who uploaded what, file sizes, sharing patterns, timing analysis
Correlation attacks: linking users based on share patterns and access times

Known Weaknesses & Limitations

⚠️ CRITICAL: Frontend Trust Problem

Users must trust the JavaScript code served by the server. Compromised server could serve malicious frontend to steal keys.

Mitigation: Browser extension, Electron app, or code signing required for true zero-trust

⚠️ Static PBKDF2 Salt

All users with same password derive same master key. Enables rainbow table attacks.

Fix: Generate random salt per user, store in database, send to client before login

⚠️ No Secure Memory Wiping

JavaScript cannot securely zero memory. Keys may remain in RAM after logout.

Mitigation: Close browser tab to clear memory, use private browsing

⚠️ No JWT Revocation

Stolen tokens valid until expiration. No blacklist or logout mechanism.

Fix: Implement token revocation list in Redis

⚠️ Password Reset = Data Loss

Zero-knowledge means lost password = lost data. No recovery mechanism possible.

Intentional: Core tradeoff of zero-knowledge architecture. User education critical.

Design Tradeoffs

✅ Benefit

Metadata in plaintext enables server-side search, sorting, quota management, and folder navigation.

⚠️ Cost

Server can see filenames, sizes, folder structures, and access patterns. Enables traffic analysis.

✅ Benefit

JWT authentication is stateless, scales horizontally, no session store needed.

⚠️ Cost

Cannot revoke tokens before expiration. Stolen tokens remain valid until timeout.

✅ Benefit

Public link file key in URL fragment (#key=...) enables zero-knowledge public sharing without server seeing key.

⚠️ Cost

URL fragment could leak via browser history, copy-paste to insecure channels, or screen sharing.

Security Recommendations

For Users:

• Use a strong, unique password (20+ characters)
• Enable 2FA (TOTP) for all accounts
• Use trusted devices only
• Close browser tabs after use
• Verify HTTPS certificate before login
• Don't share public links via unencrypted channels

For Developers:

• Implement per-user PBKDF2 salt
• Add JWT revocation with Redis
• Deploy Subresource Integrity (SRI)
• Add Content Security Policy headers
• Implement rate limiting
• Set up immutable audit logs