Consumer Wallet Identifier-Based Lookup Elimination Automation: A Tax ID Is Not a Secret

A lookup form built around "enter your tax ID or phone number to see your balance" treats that value as if only the rightful owner could produce it — the same assumption a password rests on. A Brazilian tax ID does not carry that property: it is printed on receipts, held in ordinary business records, and has appeared, like countless other identifiers, in data breaches unrelated to the business asking for it. A phone number is even more freely known. Building a lookup around either one is building a security boundary out of information that was never designed to be secret in the first place — and the fix a team reaches for first, rate-limiting the endpoint, raises the cost of guessing at scale without doing anything for the specific, targeted case, which is exactly the case that matters when the value being guessed is not actually hidden from anyone in particular.

Centriu Loop's consumer-facing portal let a customer check their own cashback balance without installing an app or creating an account — a genuine convenience, built around a public form asking for a tax ID or phone number. The query behind that form checked the submitted value against several different customer-record columns without distinguishing which kind of identifier had actually been entered, so a tax ID, a generic "document" value, a phone number, or a messaging-app number all opened the identical result: the customer's name, their current balance, and their purchase history.

The defect was not the convenience — it was treating a widely-known identifier as though it functioned as a secret. A tax ID is printed on receipts a customer might discard in public, kept in a store's own records, and has surfaced, like countless personal identifiers, in data breaches entirely unconnected to Centriu Loop or to the business using it. None of that makes the tax ID Centriu Loop's own security failure to fix at its source — but building a balance lookup around it, with no additional proof of ownership required, extended that pre-existing public knowledge directly into account access. Rate limiting the lookup by IP address was a real, working defense against one specific threat — someone with a long list of identifiers, scraping the lookup at scale — but it did nothing for the threat that matters more in practice: a single person targeting one specific, already-identified individual, submitting one value, exactly once, with no volume for a rate limit to ever notice.

The fix replaces the lookup entirely rather than trying to add a second factor on top of it. Each consumer now receives a 192-bit credential, generated once. The database stores only a SHA-256 hash of that credential — the plaintext value exists for exactly one moment, in the response that first issues it, and is never written anywhere in a form the database itself could disclose. The credential travels to the consumer as a link whose secret portion lives in the URL fragment — the part of a web address that follows a `#` character, which every modern browser is specifically designed to keep local and never transmit to any server, including Centriu Loop's own. The consumer-facing page reads that fragment, exchanges it for a short-lived session token, and then deliberately erases the fragment from the visible address bar before making its very first request to any server — specifically so that a slow network response, a browser crash, or simply closing the tab partway through does not leave the raw secret sitting in browser history where it could later be read by anyone else with access to that device. What remains after that exchange is an ordinary, short-lived HttpOnly cookie, valid for fifteen minutes, which cannot be read by page scripts and expires or can be explicitly revoked, immediately invalidating every session it had opened.

A further, deliberate hardening: the application stopped requesting the tax-ID column from the underlying customer-record table for this entire flow — not merely reading it and declining to display it, but never asking the database for it in the first place. Not requesting a sensitive column is a stronger guarantee than requesting and discarding one, because it removes the column from the flow's own reachable surface entirely, rather than depending on every future line of code in that flow to keep discarding it correctly.

Before the fix, a discarded store receipt showing a customer's tax ID — a routine, unremarkable piece of paper — was, on its own, enough for anyone who found it to look up that customer's cashback balance and full purchase history through Centriu Loop's public portal, with no further verification of any kind. After the fix, the identical receipt discloses nothing usable against the portal: balance access requires the 192-bit credential issued directly to that consumer, which never appears on a receipt, in a store's records, or anywhere a tax ID or phone number routinely surfaces.

Centriu Loop's consumer balance portal no longer grants access based on a publicly-knowable identifier of any kind — access now requires a 192-bit credential issued directly to the consumer, delivered and exchanged in a way specifically designed so the secret itself is never sent to a server, never persisted in the database in readable form, and never left exposed in browser history by an interrupted page load.

This automation governs the internal identity mechanism behind Centriu Loop's own consumer-facing balance portal — it does not change how a business's own staff access customer records through the operator dashboard (a separately authenticated, logged-in flow), and does not affect what identifying information a business collects from its own customers for its own records outside of this specific public lookup.

Using an identifier a business already has on file — a tax ID, a phone number, an account number — as the key to a public lookup is a natural first design, because the value is already there and the business already associates it with the right customer. The risk is specific and easy to overlook precisely because the identifier IS legitimately useful for record-keeping: an identifier good enough to find the right customer internally is not automatically good enough to prove, to a public-facing form, that the person asking IS that customer. A credential minted specifically and only for this one purpose — never printed on a receipt, never stored in plaintext, never reused for any other function — carries no such ambiguity.