Zero-Knowledge Encryption

Your data is encrypted on your device before reaching our servers. We have zero knowledge of your password, encryption keys, or personal information. Even we can't decrypt your data.

What is Zero-Knowledge Encryption?

Zero-knowledge encryption means we have literally zero knowledge of your password, encryption keys, or decrypted data. Everything is encrypted client-side before reaching our servers.

Instead of sending your password, you use cryptographic signatures to prove you know it without revealing it. Think of it like proving you have a key without showing the key itself.

  • Password stays on your device, always

  • Data encrypted client-side before upload

  • Even we cannot access your encrypted data

  • Server breach cannot expose your information

The Zero-Knowledge Principle

What we can and cannot see

We NEVER See:

  • Your password (plaintext or encrypted)

  • Your encryption keys

  • Your identity details (names, birthdates, addresses)

  • Your credentials (credit cards, IDs, licenses)

  • Any decrypted data - everything is encrypted client-side

We Only See:

  • A hash of your authentication proof (cannot be reversed)
  • Your unique salt for key derivation
  • Encrypted data blobs (unreadable to us)
  • Phone numbers encrypted server-side (required for SMS and call routing)
  • Anonymous usage patterns (no personal identifiers)
Zero-Knowledge Proof

How Zero-Knowledge Login Works

A cryptographic process that proves your identity without revealing your password

1

Request Salt

Client requests your unique salt (random bytes) needed to derive encryption keys from your password.

2

Derive Key

Your device derives a master encryption key from your password using PBKDF2 with 600,000 iterations. This computationally expensive process protects against brute-force attacks.

3

Generate Proof

Your device creates a cryptographic proof using HMAC-SHA256 with your derived key. This proof can only be generated by someone who knows your password.

4

Verify Proof

Server compares your proof hash against the stored hash from registration. If they match, authentication succeeds - all without seeing your password.

5

Create Session

Session tokens are stored as HttpOnly cookies, preventing JavaScript access and XSS attacks.

Why This Matters

Traditional authentication sends your password (encrypted in transit) to the server where it's checked. If the server is compromised during transmission or storage, passwords are at risk. With zero-knowledge, your password never travels anywhere. Attackers intercepting network traffic or breaching our servers get nothing useful - just cryptographic proof hashes that can't be reversed to reveal your password.

Technical Details

Cryptographic Implementation

Key Derivation

  • PBKDF2 with 600,000 iterations

  • SHA-256 hash function

  • 32-byte unique salt per user

  • Separate keys for auth and encryption

Password Authentication

  • HMAC-SHA256 cryptographic proof generation

  • Zero-knowledge proof verification

  • SHA-256 hashed proof storage

  • Timing-safe comparison

Data Encryption

  • AES-256-GCM authenticated encryption

  • Client-side encryption only

  • Zero server knowledge of plaintext

  • Unique IV per operation

Session Security

Protecting Your Session

How we prevent session hijacking and XSS attacks

Session Protection Layers

Multiple security mechanisms work together to protect your authenticated session:

HttpOnly Cookies

Session tokens stored in HttpOnly cookies cannot be accessed by JavaScript, preventing XSS theft

SameSite Policy

SameSite=Lax prevents cookies from being sent in cross-site requests, blocking CSRF attacks

Secure Flag

Cookies only transmitted over HTTPS, preventing man-in-the-middle interception

CSRF Tokens

State-changing operations require CSRF tokens that cannot be forged by attackers

Session Expiration

Sessions automatically expire after 24 hours, limiting window of compromise

Encrypted Master Key

Master encryption key encrypted with session-specific key, cleared on logout

Why This Matters

XSS Protection

Even if an attacker injects malicious JavaScript into your browser, they cannot access your session tokens because HttpOnly cookies are not exposed to JavaScript.

CSRF Protection

Attackers cannot trick your browser into making authenticated requests to our API because SameSite cookies and CSRF tokens block cross-site requests.

Defense in Depth

Multiple layers of protection mean that if one security mechanism fails, others are still in place to protect your session.

Cookie Security

  • HttpOnly flag prevents JavaScript access

  • Secure flag enforces HTTPS

  • SameSite=Lax blocks cross-site requests

  • Explicit domain scoping

Learn more about our cookie policy

Session Storage

  • Master key encrypted with session key

  • AES-256-GCM encryption

  • Automatic expiration

  • Secure memory cleanup on logout

Learn more about our cookie policy

Frequently Asked Questions

What does zero-knowledge actually mean?
Zero-knowledge means we have zero knowledge of your password or encryption keys. You never send us your password - instead, you prove you know it using cryptographic signatures. Even if someone breaches our servers, they can't access your data because we don't have the keys to decrypt it.

How is this different from traditional password authentication?
Traditional systems send your password (even if encrypted in transit) to the server where it's hashed and checked. With zero-knowledge, your password never leaves your device. Instead, you derive a cryptographic key from your password and generate a proof. The server verifies this proof matches what was computed during registration - your actual password is never transmitted or stored.

How does zero-knowledge password verification work?
When you log in, your device derives an encryption key from your password using PBKDF2 (600,000 iterations). It then creates a cryptographic proof using HMAC-SHA256 with this key. The server compares a hash of this proof against what was stored during registration. Your password never leaves your device - only a proof that you know it.

How do you prevent session hijacking?
We use multiple layers of session protection: HttpOnly cookies prevent JavaScript from accessing session tokens (blocking XSS attacks), SameSite=Lax prevents cookies from being sent in cross-site requests (blocking CSRF), Secure flags enforce HTTPS-only transmission, and CSRF tokens protect state-changing operations. Even if an attacker injects malicious code, they cannot steal your session.

Where are my encryption keys stored?
Your master encryption key is derived from your password using PBKDF2 with your unique salt (600,000 iterations). It's never stored in plaintext - only encrypted with a session-specific key in sessionStorage. When you close the browser or log out, all keys are securely erased from memory.

What if WIGGWIGG gets hacked?
Even if attackers breach our servers completely, they can't decrypt your data. We don't store passwords - only hashes of authentication proofs that can't be reversed. We don't store encryption keys - you derive them from your password. All your sensitive data is encrypted client-side before it reaches our servers. The worst they could get is encrypted blobs they can't read.

Ready to Experience True Privacy?

Join WIGGWIGG and experience zero-knowledge security firsthand.

Get Started Back to Security