Seguridad
El portal expone datos de deuda en internet abierta — en el acceso por link, sin siquiera un login — por eso cada capa de protección importa. Esta página documenta el modelo de seguridad del acceso por link para que respondas con precisión a auditorías y consultas de clientes. La cuenta persistente (e-mail y contraseña) tiene sus propias protecciones, descritas en su página.
Token de acceso
- El link lleva un token aleatorio de 256 bits. La base de datos guarda solo el hash (SHA-256) — ni tu equipo ni una filtración de la base exponen el link original.
- Expiración: 30 días. Cada uso registra el último acceso.
- Revocación: un link puede revocarse en cualquier momento; el "no soy yo" revoca automáticamente todos los links de la persona.
- Rotación: emite un nuevo token y revoca el anterior, manteniendo el linaje (qué token dio origen a cuál) para fines de auditoría.
Verificación de identidad en dos fases
Antes de la verificación, la respuesta del portal es mínima y enmascara la PII: primer nombre, documento como ***1234, e-mail como jo***@dominio.com. Valores, cobros y acuerdos solo aparecen después de que la persona confirma los 4 últimos dígitos del CPF/CNPJ.
La confirmación crea una sesión corta de 30 minutos (token firmado por HMAC, sin estado en el servidor), enviada en un header propio. Si expiró, se verifica de nuevo. Todas las acciones sensibles — simular, aceptar un acuerdo — exigen sesión verificada.
Límites de intentos (rate limiting)
| Superficie | Límite |
|---|---|
| Navegación (consultas) | 30 solicitudes/minuto por IP |
| Acciones (simular, aceptar, "no soy yo") | 20 por 15 minutos por IP |
| Verificación de identidad | 10 intentos por 15 minutos por token |
El límite de la verificación es por token, independiente del IP — un atacante que falsifica la dirección de origen (x-forwarded-for) no gana intentos extras para adivinar los 4 dígitos. Los contadores viven en almacenamiento compartido entre las instancias del sistema, así que no hay forma de "escapar" del límite cambiando de servidor.
Anti-enumeración
Un token inválido, expirado o revocado recibe exactamente la misma respuesta (404 genérico). Quien intenta adivinar links no descubre ni si un token existió, ni por qué dejó de funcionar. En la verificación de identidad, la respuesta de error también es genérica — no revela si el documento existe ni qué está mal.
Validación server-side de propuestas
La aceptación del acuerdo no confía en el navegador: el descuento y el número de cuotas se verifican contra las ofertas activas del acreedor en el servidor. Una propuesta adulterada es rechazada y el incidente queda registrado con el motivo (tampered_discount, tampered_installments), el valor solicitado y el tope permitido.
Pista de acceso
Toda interacción con el portal genera un log de acceso: acción, éxito/falla, IP, user-agent y metadatos. Las acciones jurídicamente relevantes — aceptación de acuerdo, "no soy yo" y falla de verificación de identidad — entran también en la pista de auditoría probatoria de la organización. Si algún día hay que probar que el deudor aceptó ese acuerdo, tienes el qué, cuándo, desde qué IP y bajo qué términos.
"No soy yo" sin verificación — ¿por qué?
Es la única acción disponible sin confirmar identidad, por diseño: un tercero que recibió el cobro por error no tiene (ni debe tener) los dígitos del documento del deudor. El botón solo remueve contacto — crea una supresión total, suprime envíos pendientes y revoca los links — y nunca expone datos, así que no hay nada que abusar.