Security
The portal exposes debt data on the open internet — in the link-based access, without even a login — so every layer of protection matters. This page documents the security model of the link-based access for you to answer audits and customer questions precisely. The persistent account (email and password) has its own protections, described on its page.
Access token
- The link carries a random 256-bit token. The database stores only the hash (SHA-256) — neither your team nor a database leak exposes the original link.
- Expiration: 30 days. Each use records the last access.
- Revocation: a link can be revoked at any time; "not me" automatically revokes all of the person's links.
- Rotation: issues a new token and revokes the previous one, keeping the lineage (which token originated which) for audit purposes.
Two-phase identity verification
Before verification, the portal's response is minimal and masks PII: first name, document as ***1234, email as jo***@dominio.com. Amounts, charges and agreements only appear after the person confirms the last 4 digits of the CPF/CNPJ.
Confirmation creates a short 30-minute session (HMAC-signed token, stateless on the server), sent in a dedicated header. Expired, verify again. All sensitive actions — simulating, accepting an agreement — require a verified session.
Attempt limits (rate limiting)
| Surface | Limit |
|---|---|
| Browsing (reads) | 30 requests/minute per IP |
| Actions (simulate, accept, "not me") | 20 per 15 minutes per IP |
| Identity verification | 10 attempts per 15 minutes per token |
The verification limit is per token, independent of IP — an attacker who spoofs the source address (x-forwarded-for) gains no extra attempts to guess the 4 digits. The counters live in storage shared across the system's instances, so there is no "escaping" the limit by switching servers.
On top of the per-window limit there is a permanent link lockout: after 10 accumulated failures since the last success, the link is revoked and the debtor is told to ask the creditor for a new one. Without it, 10 attempts every 15 minutes over the link's 30-day validity would be enough to go through all 10,000 possible 4-digit values.
Anti-enumeration
Invalid, expired and revoked tokens receive exactly the same response (a generic 404). Someone guessing links learns neither whether a token ever existed nor why it stopped working. On identity verification, the error response is also generic — it does not reveal whether the document exists or what is wrong.
Server-side proposal validation
Agreement acceptance does not trust the browser: discount and number of installments are checked against the creditor's active offers on the server. A tampered proposal is rejected and the incident is logged with the reason (tampered_discount, tampered_installments), the requested value and the allowed ceiling.
Access trail
Every interaction with the portal generates an access log: action, success/failure, IP, user-agent and metadata. The legally relevant actions — agreement acceptance, "not me" and failed identity verification — also enter the organization's evidentiary audit trail. If one day you need to prove the debtor accepted that agreement, you have the what, when, from which IP and under which terms.
"Not me" without verification — why?
It is the only action available without confirming identity, by design: a third party who received the charge by mistake does not have (and should not have) the digits of the debtor's document. The flow (the "I'm not [name]" link on the verification screen, with a confirmation dialog and an optional comment) only removes contact — it creates a full suppression, suppresses pending sends and revokes the links — and never exposes data, so there is nothing to abuse. The flag has no reversal from the interface: new links and account creation for that person start being refused.