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.
Além do limite por janela, há um bloqueio definitivo do link: depois de 10 falhas acumuladas desde o último acerto, o link é revogado e o devedor vê a orientação de pedir um novo link ao credor. Sem isso, 10 tentativas a cada 15 minutos durante os 30 dias de validade do link bastariam para percorrer os 10.000 valores possíveis de 4 dígitos.
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 fluxo (link "Não sou [nome]" na tela de verificação, com diálogo de confirmação e comentário opcional) 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. A marcação não tem reversão pela interface: novos links e a criação de conta para a pessoa passam a ser recusados.