Resilience to a personal-data leak

What this is

Any connector between an application and a messenger has to answer one question: which account in the messenger is this user? The usual answer is to write the native identifier down — a Telegram id, a phone number, a mail address — and keep it next to the account for as long as the account lives.

That column is the most toxic thing such a database holds. A password can be rotated and a session expires; a reachability link cannot be either. It is a permanent, externally addressable connection between a person and a place where that person can be reached — and a dump of it is a ready-made list for spam, for phishing that already knows which service the victim uses, and for matching the same person across services that never shared anything.

Veriqa is being designed so that this link is not in the database in the first place.

A derived value instead of the native identifier. The record will hold a one-way keyed hash of the identifier rather than the identifier itself. The same person always derives to the same value, so the account is recognised on every sign-in exactly as before — but the value does not convert back into a Telegram id or a mail address.

The secret is not next to the data. Deriving that value takes a secret, and the design keeps it in a key-management service or a secret store — self-hosted deployments included, with no weaker fallback. This is the whole mechanism, not a hardening tip: the set of possible inputs is small enough to be enumerated, so a secret sitting in the same snapshot as the database would let an attacker simply recompute the function. Where there is no secret store to hold it, the mode is designed to stay off rather than degrade.

Different values for different integrators. The tenant is part of the input, so the same person becomes a different value in every integrator's database. Two leaked databases do not join with each other, and neither joins a purchased marketing list.

And, where the flow allows it, no value at all. When users always arrive from the channel themselves, the messenger hands the identifier over with every confirmation — so there is nothing to keep between transactions. The strongest form of this property is not "encrypted well" but "never written down". The same pass trims the profile that travels with the identity: a name, a username, an avatar, a phone number are stored because they were once convenient, not because the sign-in needs them.

What it is for

• Services that answer for personal data. Both the scale and the price of a breach fall, and so does the volume of what has to be protected at all: a column that carries no reachable identifier is a column an attacker cannot act on.
• Products where the user list is itself the sensitive fact — medicine, finance, HR, dating, anything where "this person uses this service" is what must not become public. That fact escapes through the reachability link far more often than through a name.
• Integrators who cannot promise an unbreakable perimeter — nobody can — and would rather be able to say what exactly an attacker walks away with.

One thing this does not do, and it matters for anyone who will have to defend the answer: it does not take the data out of scope of GDPR or of national personal-data law. Pseudonymisation is a protective measure there (GDPR art. 4(5) and art. 32(1)(a)), not anonymisation — the data stays personal, and the obligations of a controller stay in place. What changes is how much of it is left to lose.

The mode is the integrator's decision — a per-tenant mode turned on deliberately, not a default that changes behaviour for everyone. Two consequences come with it, and both follow from the property rather than qualify it. Looking a user up by their Telegram id or mail address stops being possible — that is precisely what is being paid for. And a scenario that has to push a confirmation into a channel on its own still needs the native identifier back, so there it will live encrypted under a key from the same key service — reversible, unlike the hash: stronger than keeping it in the open, weaker than the mode that keeps nothing at all.

Where this stands

We are working on this: what works out will appear in releases as it is developed; if the direction does not hold up, this page will say so.