Is it safe to give you my stream credentials?

Two formats, one rule: nothing readable at rest

We’re new, and we know exactly what pasting an IPTV login into a website you found last week feels like. So the vault assumes you won’t trust us: your subscription isn’t safe because we’re careful — it’s safe because it reaches us already sealed, or not at all.

An Xtream login is the clean case. Creating the source sends us one field: the panel’s host name, which is not a secret. Your browser fetches the catalogue, builds the channel list on your device, and seals it — username and password included — before anything is uploaded. What lands on our side is that sealed list: ciphertext we can’t open. Your login in the clear is never written anywhere — no readable row, no log line. Catalogue calls and stream dials do route through us — they have to leave from our VPN exits, or your provider would see your home IP — but they pass through in memory and land nowhere.

An M3U link is the awkward case, so we’ll be exact. The URL itself usually carries your username and password, and the playlist behind it has to be fetched before there’s anything to seal. So the link reaches our server once: held in RAM, used for one outbound TLS request, relayed back as raw bytes for your device to parse and seal. Never stored — not in the database, not in logs, not in headers, not in any cache. The honest claim for M3U is “never stored”, not “never left your device”. If you’re offered both formats, pick Xtream — sealed on your device beats passing through ours, even once.

How the sealing works, end to end

“Encrypted” on a pricing page can mean anything from a TLS certificate to a database column with the key taped next to it. Here is ours, mechanism by mechanism. Your browser generates a 256-bit key with WebCrypto — the browser’s own cryptography, run on your device. That key is the account. There is no password.

HKDF-SHA256 derives a key-encryption key — a KEK — from it, and the KEK wraps the DEK, the data-encryption key that seals your channel list, URL by URL, with AES-256-GCM. “Wraps” means the DEK is itself stored encrypted: an envelope only your key opens. We keep the envelope. We can’t open it.

Sign-in is the same key doing a second job. Your device derives an Ed25519 keypair and sends us the public half. The server sends a nonce — a number used once — your browser signs it, we check the signature against your public key. That’s challenge–response: nothing reusable crosses the wire, so there’s nothing to phish — and nothing for us to reset. A service that can email you a password reset holds something it can read. We can’t, so we don’t.

Add it up: the server’s complete holding for your vault is ciphertext, your public key, and wrapped key envelopes. Each is safe to show a stranger. That was the design test — not “is this protected” but “would it matter if it leaked”.

What we can see — and what we can’t

What we can see, plainly. The email you registered with. When you sign in. How many sources you have, and how large the sealed blob is. While you watch: that bytes are flowing through the blind relay to your player — it reads the few framing bytes needed to cut the stream into pieces and forwards the rest unread. No decoder on the box; what’s inside isn’t something we decline to look at, it’s something the machine can’t parse. The byte path’s access log keeps a timestamp and a token, nothing about what you watched.

What the design withholds: your Xtream password, never stored; your M3U link at rest, ciphertext; your channel list, same; the inside of your streams, unreadable by the relay. The disclosed residual is the in-memory moments above — the one playlist fetch, the dial that opens a channel URL for the instant it takes to connect, then drops it. Moments in RAM, nothing at rest. We’d rather draw that line precisely than draw it flattering.

If Twiga is breached

Assume the worst: an attacker walks off with the whole database. They hold account emails, sign-in records, and a pile of vaults — ciphertext with public keys and wrapped envelopes beside it. The envelopes need your key, which was generated on your device and never sent to us. AES-256-GCM without the key isn’t a puzzle that yields to effort. A stolen copy of our database is a box of locked envelopes, not a list of logins.

We won’t pretend that’s nothing: your email is real data, and a breach would be disclosed as the incident it is. But your provider login and channel list would leak as ciphertext. Which is to say: they wouldn’t.

If you lose your key

At setup you save a recovery code. It derives a second KEK, which wraps a second copy of the DEK; we store that envelope and a verifier — a one-way fingerprint that confirms you know the code without us ever holding it. You hold two openers. We hold zero.

Lose both and the list can’t be unsealed — not by you, not by us, not by anyone we could be compelled to help. No reset email, because there’s no password; no back door, because a door for you is a door for whoever shows up dressed as you. We know “we can’t help you” is a strange sentence to put on a trust page. It’s also the entire proof: the inability that locks you out of a lost vault locks us out of every vault. Your account and email survive; the list doesn’t. Keep the code somewhere your key isn’t — a password manager works for both.

The receipts

Plain language is cheap; here’s where to check it. The manifesto lays out the five theses and the architecture that carries them. The privacy page lists what is logged and what is never logged, with your rights beside it. The wiki entries on AES-256-GCM, the blind relay, and VPN exits each go a layer deeper than this page. Find a claim that doesn’t hold? Write to [email protected] — not a courtesy line, the bug tracker for this page.

Quick answers

Can Twiga employees see my channel list?

No. The list sits in our database as ciphertext sealed under keys derived from a key only you hold, and that key never reaches us. There is no admin view, no support tool, and no database query that returns your channels in the clear — reading the list takes your key, on your device.

Do you store my Xtream password?

No. Creating an Xtream source sends us the panel’s host name and nothing else. Your username and password are sealed into the vault on your device; the requests that use them pass through our relay in memory only, so they can leave from our VPN exits instead of your home IP. Neither is ever written to our database or our logs.

Do you store my M3U playlist URL?

No — but it does pass through once, and we’d rather say so than round it off. The link has to reach our server to fetch your channel list: one outbound TLS request, held in RAM, never stored — not in the database, not in logs, not in headers, not in caches. What the database holds afterwards is ciphertext sealed with a key only you hold.

What happens if Twiga’s servers are hacked?

The attacker gets what we have: account emails, sign-in records, and sealed vaults — ciphertext, public keys, and wrapped key envelopes. Without your key the envelopes stay shut and the ciphertext stays ciphertext, so your provider login and channel list leak in no readable form. Your email is the real exposure, and a breach would be disclosed as a real incident.