Rootproof

Idioma

Tema

Legal · Seguridad

Seguridad

Versión: 2026-05-11 · Última actualización: 11 de mayo de 2026

Esta página resume nuestras prácticas técnicas y operativas. Para un detalle contractual, consulta el DPA y los Términos.

1. Filosofía

Diseñamos el producto bajo dos principios contradictorios pero importantes: (a) la información sensible NO necesita estar en nuestros servidores para que el servicio funcione, y (b) lo que sí almacenamos lo cifrarías de todas formas. La consecuencia: minimizamos lo que tenemos, maximizamos lo que verificamos públicamente.

2. Criptografía en uso

Operaciones y algoritmos en producción:

  • check_circleTLS 1.3 en todo el tráfico HTTP (Vercel + Cloudflare).
  • check_circleSHA-256 para huellas de documentos (BIP-340 compatible).
  • check_circleHMAC-SHA256 para firmas de webhooks (X-Rootproof-Signature).
  • check_circleHMAC-SHA256 para tokens de sesión y verificación de email.
  • check_circleComparaciones constant-time (timingSafeEqual) para verificación de MACs.
  • check_circleHash + pepper para contraseñas de organización (SHA-256 + secret server-side, validación constant-time).
  • check_circleAnclaje on-chain vía EAS (Ethereum Attestation Service) sobre Rootstock — secured by Bitcoin mining.

3. Autenticación y autorización

Tres flujos coexisten según el actor:

  • check_circleOwner de organización: contraseña + sesión HMAC en cookie HttpOnly. Lockout por IP tras 8 intentos fallidos.
  • check_circleMiembros invitados: magic link único + OTP de 6 dígitos vía email (Resend), confirmación contra Redis para impedir replay.
  • check_circleProgramático: API keys bearer, hasheadas en reposo, mostradas en plano una sola vez al crear.
  • check_circleAdmin global: contraseña + 2FA TOTP opcional (en roadmap: obligatorio).
  • check_circleCookies: HttpOnly + Secure + SameSite=Lax, scope al path, expiración 7 días.
  • check_circleRoles por organización: admin / issuer / viewer con matriz de capacidades verificada en middleware.

4. Almacenamiento

Datos minimizados y separados:

  • check_circleVercel Blob: PDFs emitidos, JSON de configuración por org. Cifrado en reposo por defecto.
  • check_circleUpstash Redis: sesiones, OTPs, rate-limit counters, locks. TTL agresivos (≤ 7 días para sesiones, 5–10 min para OTPs).
  • check_circlePara certificación documental, los archivos del cliente NUNCA se transmiten — el hash SHA-256 se calcula localmente en el navegador (SubtleCrypto). Solo el hash llega al servidor.
  • check_circleSin cookies de tracking, sin pixel de remarketing. Vercel Analytics agregado y anónimo.

5. Rate limiting y abuso

Sliding window por IP en endpoints públicos y de write costoso:

  • check_circle5 req/min: /api/certify-doc, /api/contact, generación de certs.
  • check_circle10 req/min: /api/send-otp, /api/chat, signup, doc-pdf, verify-pdf.
  • check_circle60 req/min: verify pública, metrics, status, certificates read.
  • check_circleBloqueo por (slug, IP) tras 8 intentos fallidos de login (15 min lockout).
  • check_circleToken de OTP single-use (Redis SET NX).
  • check_circleToken de invitación a miembros single-use (fingerprint en Redis).

6. Monitoreo y observabilidad

Visibilidad en producción:

  • check_circleSentry: captura de excepciones server-side y client-side con scrubbing de PII.
  • check_circleVercel Analytics: métricas agregadas de tráfico, sin PII.
  • check_circleAudit log por organización: cada acción mutativa queda registrada (actor + timestamp + detalles).
  • check_circle/api/admin/health: diagnóstico operativo interno (env vars, RPC, wallet balance, blob, redis).
  • check_circle/api/public/status + /status: subset público sin secretos, con auto-refresh 30 s.

7. SSRF y validación de inputs

Defensa contra ataques de network internal scan:

  • check_circleValidación SSRF en cualquier URL de cliente (logoUrl, webhookUrl, website): bloqueo de IPs privadas (RFC1918), loopback, localhost, link-local.
  • check_circleCarga de PDFs: tamaño máx 5 MB, content-type validado.
  • check_circleJSON body: tamaño máx por endpoint (8 KB para signup, 32 KB para CRM, etc).
  • check_circleSlug y certificateId: regex estricto (lowercase alfanumérico + guiones).
  • check_circleHash SHA-256 entrada: regex 64 hex chars antes de cualquier lookup.

8. Webhooks salientes

Eventos cert.issued / cert.revoked se firman con HMAC-SHA256 usando el secret configurado por la org (mínimo 16 chars). Header: X-Rootproof-Signature: t=<ms>,v1=<hex>. El cliente debe validar timestamp (rechazar > 5 min) y MAC constant-time. Sin secret configurado, los webhooks no se envían.

9. Independencia blockchain

La integridad criptográfica del certificado NO depende de Rootproof. Los datos públicos que sobreviven a cualquier evento que nos afecte:

  • check_circleHash SHA-256 del PDF (en la attestation EAS).
  • check_circleAttestation UID + transaction hash en Rootstock.
  • check_circleDID:web del emisor (resolvable independientemente).
  • check_circleVerificación posible en cualquier explorador de bloques o cliente EAS oficial.

10. Respuesta a incidentes

Cuando detectamos o nos reportan un incidente que potencialmente afecte datos de clientes:

  • check_circleConfirmación inicial dentro de 1 h hábil.
  • check_circleNotificación a clientes afectados dentro de 72 h (alineado con GDPR Art. 33).
  • check_circlePostmortem público para incidentes P1 dentro de 5 días hábiles.
  • check_circleReportes de degradación se publican en /status dentro de 15 min.

11. Divulgación responsable

Si encontrás una vulnerabilidad, escribinos a security@rootproof.io (o vía /contact con asunto "Security" si preferís un formulario). El canal está documentado en /.well-known/security.txt según RFC 9116. Garantizamos: respuesta inicial en 48 h, sin acciones legales contra el reportante mientras se respete buena fe y proporcionalidad, mención (opcional) en el hall of fame de abajo una vez parchada. Aún no operamos un bounty monetario, pero lo evaluamos para 2026 Q4.

13. Hall of fame

Investigadores que reportaron vulnerabilidades de forma responsable y aceptaron ser mencionados aquí. Si reportaste y querés aparecer (o no aparecer), avisanos.

  • check_circle— Aún sin reportes públicos. Sé el primero.

12. Qué NO afirmamos

Para ser honestos sobre lo que aún no logramos:

  • check_circleNo estamos certificados SOC 2 todavía. Apuntamos a Type II durante 2027.
  • check_circleNo tenemos ISO 27001 todavía. Implementamos prácticas alineadas, pero sin auditoría externa formal aún.
  • check_circleNo corremos pen-tests anuales por firma externa todavía. Sí ejecutamos revisiones internas y dependency-scan continuo.
  • check_circleCualquier badge que veas en nuestro sitio que no esté respaldado por la certificación correspondiente es un error — reporta y lo removemos.