Security

How meetings, recordings, accounts and data are protected — and how we test it.

Security is designed into Deewan rather than added on: encryption happens in the browser, every database table enforces who may read each row, and attack suites run against the live platform. This page says exactly what each protection does, including where its limits are.

Meeting encryption

Every meeting is encrypted in each participant's browser before anything leaves the device, and our media servers and relays forward ciphertext only. Each room chooses who holds the key:

• How strict mode works. The first person in a session creates a random 256-bit key in their browser. Each newcomer receives it from someone already inside, sealed to a key pair their browser made for that connection (ECDH P-256 → HKDF-SHA-256 → AES-256-GCM). Our server only relays the sealed envelopes and cannot open them.
• People who leave are locked out. When someone leaves, the key is replaced and handed only to those who stayed, so they can't follow what is said afterwards.
• Security code. Everyone sees a 20-digit code derived from the key and every participant's connection key. If the codes match when read aloud, nobody extra received the key and no key was swapped in transit.
• Nothing is sent without a key. Until a device has the meeting key, its camera, microphone and chat are held back rather than sent unencrypted.
• Tested against ourselves. Our test puts a hidden listener in a strict meeting, holding every secret our servers have. It decodes nothing, while the same listener does decode a standard meeting — which proves the test itself works.

Recordings

• End-to-end encrypted. Recordings are composed in the host's browser and encrypted there with a fresh AES-256-GCM key before upload. Storage holds ciphertext only.
• Only the people allowed to watch can open them. The key is sealed separately to each allowed viewer's personal key, which is unlocked in their browser with their password or recovery phrase. Deewan never has the password, the phrase or the key.
• A way back that stays yours. Workspace owners can create a recovery key they keep outside Deewan, so recordings survive people leaving.
• Tamper-evident. Each part of a recording is bound to its recording and position, so parts can't be swapped or reordered without decryption failing.

Accounts and sign-in

• Strong passwords. At least 12 characters, checked for strength, and refused if they appear in known data breaches (checked with k-anonymity: only 5 characters of a hash ever leave our server).
• Brute-force limits. Sign-in is limited to 5 attempts per 5 minutes, password resets to 3 an hour, and two-factor codes to 5 per 5 minutes. Limits are kept in the database, so a restart doesn't reset them.
• Two-factor authentication with any authenticator app, plus single-use backup codes.
• Safe resets. Reset links expire after 15 minutes, and a reset signs the account out everywhere.
• Sessions. Secure, HTTP-only cookies. Sign in with Google uses state and PKCE, and Google tokens are stored encrypted.
• Verified email is required before an account can be used.

Your data stays yours

• Row-level security on every table. The database itself decides which rows each person may read or change. All 47 tables enforce it, and the application connects with a restricted role that can't bypass it, so a bug in one screen can't expose another workspace's data.
• Staff access is separate and audited. Platform administrators can only reach customer data inside a dedicated admin console, and every action there is logged.
• Injection-safe by construction. Every database query uses bound parameters and every API input is validated against a strict schema. Pages escape all user content and send strict security headers (HSTS, frame-ancestors, nosniff and a restrictive permissions policy).
• Keys at rest. We store only a keyed hash of each API key. Webhook secrets are encrypted with AES-256-GCM.
• Least privilege for integrations. API keys are scoped to one workspace and to the scopes you pick, and stop working when their creator loses the right to manage them.
• Data residency. Data and media servers run in Frankfurt, Germany (EU). HTTPS only.

Abuse protection

• Rate limits on sign-in, joining, the API (120 requests a minute per key) and in-meeting actions.
• Waiting rooms and locks. Hosts admit people one by one, can lock a room, and can mute or remove anyone. Guests always wait for a host.
• Idle sessions end. Someone alone in a meeting is asked after 30 minutes and removed after 90. A waiting room lets people go after an hour.
• Short-lived media credentials. Meeting passes last minutes, and relay (TURN) credentials expire and can't be reused elsewhere.
• Safe webhooks. Webhook calls are signed (HMAC-SHA-256 with a timestamp) and can never be pointed at private or internal network addresses.

How we test it

These suites run against the live platform, not a copy. Latest results, 21 September 2026:

Your side

• Use strict end-to-end encryption for meetings whose content must stay between the people in them.
• Turn on two-factor authentication, and create a workspace recovery key for recordings.
• Keep API keys in a secrets manager or environment variables, never in code or clients.
• Create links and tokens only after your own authorization check, one per person.
• Verify webhook signatures and timestamps on every request.
• Treat a recording's download key like a password.
• Revoke keys you no longer use; rotate them periodically.

Found a vulnerability? Write to support@deewan.io. Please don't test against other customers' data or degrade the service.