Segurança
O portal expõe dados de dívida na internet aberta — no acesso por link, sem sequer um login — então cada camada de proteção importa. Esta página documenta o modelo de segurança do acesso por link para você responder com precisão a auditorias e questionamentos de clientes. A conta persistente (e-mail e senha) tem as suas próprias proteções, descritas na página dela.
Token de acesso
- O link carrega um token aleatório de 256 bits. O banco guarda apenas o hash (SHA-256) — nem a sua equipe nem um vazamento de banco expõem o link original.
- Expiração: 30 dias. Cada uso registra o último acesso.
- Revogação: um link pode ser revogado a qualquer momento; o "não sou eu" revoga automaticamente todos os links da pessoa.
- Rotação: emite um novo token e revoga o anterior, mantendo a linhagem (qual token deu origem a qual) para fins de auditoria.
Verificação de identidade em duas fases
Antes da verificação, a resposta do portal é mínima e mascara PII: primeiro nome, documento como ***1234, e-mail como jo***@dominio.com. Valores, cobranças e acordos só aparecem depois que a pessoa confirma os 4 últimos dígitos do CPF/CNPJ.
A confirmação cria uma sessão curta de 30 minutos (token assinado por HMAC, sem estado no servidor), enviada em um header próprio. Expirou, verifica de novo. Todas as ações sensíveis — simular, aceitar acordo — exigem sessão verificada.
Limites de tentativas (rate limiting)
| Superfície | Limite |
|---|---|
| Navegação (consultas) | 30 requisições/minuto por IP |
| Ações (simular, aceitar, "não sou eu") | 20 por 15 minutos por IP |
| Verificação de identidade | 10 tentativas por 15 minutos por token |
O limite da verificação é por token, independente do IP — um atacante que forja o endereço de origem (x-forwarded-for) não ganha tentativas extras para adivinhar os 4 dígitos. Os contadores vivem em armazenamento compartilhado entre as instâncias do sistema, então não há como "escapar" do limite trocando de servidor.
Anti-enumeração
Token inválido, expirado ou revogado recebem exatamente a mesma resposta (404 genérico). Quem tenta adivinhar links não descobre nem se um token existiu, nem por que deixou de funcionar. Na verificação de identidade, a resposta de erro também é genérica — não revela se o documento existe ou o que está errado.
Validação server-side de propostas
O aceite de acordo não confia no navegador: desconto e número de parcelas são conferidos contra as ofertas ativas do credor no servidor. Proposta adulterada é rejeitada e o incidente fica registrado com o motivo (tampered_discount, tampered_installments), o valor pedido e o teto permitido.
Trilha de acesso
Toda interação com o portal gera um log de acesso: ação, sucesso/falha, IP, user-agent e metadados. As ações juridicamente relevantes — aceite de acordo, "não sou eu" e falha de verificação de identidade — entram também na trilha de auditoria probatória da organização. Se um dia for preciso provar que o devedor aceitou aquele acordo, você tem o quê, quando, de qual IP e sob quais termos.
"Não sou eu" sem verificação — por quê?
É a única ação disponível sem confirmar identidade, por design: um terceiro que recebeu a cobrança por engano não tem (nem deve ter) os dígitos do documento do devedor. O botão só remove contato — cria supressão total, suprime envios pendentes e revoga os links — e nunca expõe dados, então não há o que abusar.