Is it safe to give you my stream credentials?

Two formats, one path: the login is stored sealed

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. It stores your provider login and each stream URL sealed.

An Xtream login passes through twiga’s server in memory. Creating the source sends us one field in the clear: the panel’s host name, which is not a secret. To build your channel list, your login goes through our server and the catalogue is fetched from twiga’s exits, so your provider sees twiga’s IP, not your home one, and it comes back to your browser as raw bytes. Your browser builds the list and seals your login and each channel’s stream URL, so the stored copy of your login is ciphertext.

An M3U link takes the same path, 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 in the clear: not in the database, not in logs, not in headers, not in any cache. What we keep is a sealed copy, same as an Xtream login. The honest claim for M3U is “passes through once, stored only sealed”, not “never left your device”.

What lands on our side is the same for both: the channel names and groups in the clear, so your guide and search load fast, and the sealed login and stream URLs. Both are held the same way.

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 provider login and stream URLs, URL by URL, with AES-256-GCM. “Wraps” means the DEK is itself stored encrypted: at rest, the envelope stays sealed. When you sign in, your browser unwraps the DEK and hands the server a session copy. Your provider login is sealed in your browser with your key. The server stores ciphertext and opens it in memory while you’re signed in, then wipes it 30 minutes after your session goes quiet.

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: each signature works once, there’s no password to phish, and there’s 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: at rest, the server stores ciphertext, your public keys, wrapped key envelopes and the recovery verifier and locator for your vault.

What we can see — and what we can’t

What we can see, plainly. An email address, if you added one before twiga stopped taking them. When you sign in. How many sources you have, and how large the sealed blob is. Your channel names, groups, and logos, too — those stay in the clear so your guide and search work. So do your favourites and categories, your security events and your feedback; the quick answers on what a stolen copy of the database holds list the main kinds, and the Privacy Notice the rest. 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 no line at all for a stream URL; the relay’s short working log is the one place a channel is named.

What the design withholds at rest: your provider login, sealed, whether it came as an Xtream login or an M3U link; each channel’s stream URL, sealed; the inside of your streams, unreadable by the relay. The disclosed residual is in memory. The fetch that builds your channel list passes your login through the server.

If twiga is breached

Assume the worst: an attacker walks off with the whole database. They hold the records the quick answers below list, in the clear: sign-in records, channel names and groups, favourites and categories, security events, feedback, any email address added back when twiga took them, and the rest. And they hold a pile of vaults — ciphertext with public keys and wrapped envelopes beside it. That pile now includes the recovery material too: a second copy of each envelope wrapped under your recovery code, plus the verifier and the locator. The envelopes need your key, which your device generated; the second copy needs the recovery code; and the verifier that gates a restore can’t authorize a new key by itself. 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 — and not a way to mint a key into one, either.

We won’t pretend that’s nothing: your favourites and categories, your feedback and an email address, if you added one before twiga stopped taking them, are real data, and a breach would be disclosed as the incident it is. Your channel names would be visible — they always are, that’s how search and the guide work — but your provider login and every channel’s stream URL would leak as ciphertext. Which is to say: they wouldn’t.

If you lose your key

At setup you save a recovery code. Your browser stretches it with Argon2id and splits the result into a second KEK, which wraps a second copy of the DEK; a verifier; and a signing key. A hash of the code, the locator, lets the restore screen find your account without an email. The server stores the envelope, the verifier, the locator and the signing key’s public half. The verifier can’t be turned back into the code, but it is what your browser sends to restore, so whoever has it can ask for the envelope, and the envelope still takes the code to open. Either opener, your key or the code, unwraps the same DEK.

Lose only the key — code still in hand — and you’re not locked out. On the restore screen your device stretches the code and sends us the locator and the verifier, and we hand back the recovery-wrapped copy of your DEK; the code opens it, and your vault rotates onto a brand-new key and a fresh recovery code. Every old session is signed out. The swap is authorized by a signature only the old recovery code can make, so a stolen database can neither open the envelope nor forge the rotation. Nothing you’d sealed is re-encrypted — the same DEK carries over, your sources intact. Save the new code somewhere your new key isn’t.

Lose both and there’s no way back in — not for you, not for us, not for 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. You start over with a new invite. The copies of your provider login and stream URLs in our database are still ciphertext. 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 twiga’s 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?

Partially, and we’d rather say exactly which half. Channel names, groups, and logos sit in our database in the clear — that’s what lets your guide load and search work, and yes, it means an admin could see your account has a channel called “BBC One”. What is sealed at rest: your provider login and every channel’s actual stream URL. There is no admin view, no support tool, and no database query that unseals either one.

Do you store my Xtream password?

Only sealed. Your browser seals your username and password with your key, and that sealed copy is what we store. It’s what lets your channel list and guide refresh on their own. We open it in server memory while you’re signed in; the plain version is never written to our database or our logs.

Do you store my M3U playlist URL?

Only sealed. It does pass through once in the clear, and we’d rather say so. To fetch your channel list, the link reaches our server over an encrypted connection and is held in memory for that one request. What we store afterwards is the link sealed with your key, each stream URL sealed the same way, and channel names and groups in the clear so your guide and search work.

What happens if twiga’s servers are hacked?

A stolen copy of the database holds your account’s records in the clear, and the next two answers list the main kinds. It also holds sealed vaults: ciphertext, public keys and wrapped key envelopes, the recovery copies included. Without your key the envelopes stay shut, and the recovery copies need the recovery code. The verifier that gates a restore can’t authorize a new key by itself. So a stolen copy holds your provider login and every channel’s stream URL only as ciphertext. A breach of the running server is a different case, and the seal doesn’t cover it. Either breach would be disclosed as a real incident.

What does a stolen copy of the database hold about my account?

In the clear: your account’s id, how you sign in, public key, settings (region, home country, interests, preferred quality) and status flags (admin, email verified, two-step on, marketing opt-in, failed recovery tries, key and session version counters); the date it was made; its plan with the trial and paid-through dates; the versions of the Terms and Privacy Notice you accepted, with their dates; the invite codes it made; and a display name or avatar if you set one. Each signed-in device’s session token, stored as issued, and browser string are there too, and any email address added before twiga stopped taking them, whether on an account or kept apart from one, with a copy of each email twiga sent to it, sign-in codes included. So are your security events (each sign-in, with a coarse device name, and each change to your key, recovery, email, sessions or account freeze, with the time, plus any change waiting out its delay), what you sent us (feedback with our replies, journal comments under your handle), any World Cup picks you saved, and any entry in twiga’s operations log that names your account. An older account may still hold a password hash, a two-step secret with its backup-code hashes, and one-time tokens from the retired email sign-in.

What does a stolen copy of the database hold about my sources and channels?

Each source’s name, type, status, settings, provider host name, count of finished syncs, which of twiga’s exits carries it and the token in its playlist link, all in the clear; an older source may also hold check values made from its provider login. Your channels’ names, numbers, groups, logos, languages, tags and guide ids are there, with the outcome of any stream test twiga ran on one, and so is what you did with them: the channels in My Stream or your favourites, your own categories and their names, what you hid or renamed, your group order, lineups and filter presets. So is the programme guide for your channels, which is public schedule data, with any guide feed you typed in yourself, address and all, so a login typed into it sits there too. Beyond accounts, the copy holds stream-session records (start and stop times, bytes, startup timing, how the session ended, which exit carried it), player-quality and page-speed samples and app downloads, with no account, source or channel in them, and twiga’s own working records (settings, exit status, uptime counts, test summaries, payment invoices, prepaid-code records, the site’s pages), tied to no account. Sealed: your provider login and each channel’s stream URL, as ciphertext beside public keys and wrapped key envelopes (the recovery copies included), and check values, with their salts, made from your recovery code, your freeze code and your vault key. These answers name the main kinds of record, not every column; the Privacy Notice at twiga.tv/privacy sets out what twiga keeps.