Cada intento automatizado te cuesta dinero
Un bot que llega a tu formulario puede disparar SMS de OTP reales. Es el fraude que la industria conoce como SMS pumping o tráfico artificialmente inflado, y lo pagas tú.
Twilio, What is SMS Pumping Fraud
Seguridad para apps móviles
Detén el credential stuffing contra tu API de login
ShieldCert emite un certificado mTLS único por dispositivo. Tu backend solo acepta el handshake de tu app real: un bot o una app recompilada no llega al endpoint de login aunque tenga credenciales válidas. Sin CAPTCHA y antes del 2FA.
1 de cada 4
inicios de sesión analizados fue un ataque de credential stuffing.
Okta, The State of Secure Identity Report 2023Por qué tu endpoint de login es el objetivo
El 2FA llega tarde
El segundo factor solo actúa cuando la contraseña ya se ha validado: para entonces el atacante ya sabe qué credenciales funcionan. ShieldCert corta la conexión en el handshake TLS, antes de que tu aplicación procese la petición.
Qué hace ShieldCert
Identidad criptográfica por dispositivo, aplicada en el borde de tu infraestructura.
Protege el endpoint de autenticación
Evita que bots y apps recompiladas prueben combinaciones de usuario y contraseña contra tu API de login, antes de que intervenga el 2FA.
Bloqueo del abuso automatizado
El tráfico de credential stuffing no completa el handshake, así que no consume ni ciclos de tu backend ni SMS de verificación.
Identidad única por dispositivo
Cada instalación registrada recibe su propio certificado, que acredita que la app es legítima y no ha sido manipulada.
Integración con tu infraestructura actual
Funciona con tu backend tal como está: se configura en Nginx para exigir certificado en los endpoints sensibles.
mTLS sin fricción para el usuario
Autenticación mutua entre app y backend sin CAPTCHA, sin pasos extra y sin cambios en el flujo de acceso.
Rotación y revocación automáticas
Certificados de corta duración que rotan solos. Un agente en tu propia infraestructura lee el syslog, detecta si un certificado ha sido comprometido y lo notifica para que quede bloqueado, sin intervención manual.
Cómo funciona
Integras el SDK en tu app móvil y exiges mTLS en tu backend. A partir de ahí el flujo es este:
- Registra tu app móvil en ShieldCert.
- Integra el SDK de Android en tu app móvil.
- ShieldCert emite un certificado único por dispositivo, almacenado de forma segura.
- Configura tu backend (por ejemplo Nginx con mTLS) para exigir certificados válidos en el endpoint de login.
- Los bots y las apps no autorizadas quedan bloqueados aunque tengan credenciales correctas.
- Consultas los intentos bloqueados y los dispositivos sospechosos desde el panel.
Objeciones técnicas
Las preguntas que hace un equipo de seguridad antes de meter esto en producción.
¿Por qué mTLS y no un CAPTCHA o un WAF?
Un CAPTCHA y un WAF deciden a posteriori y sobre señales estadísticas: reputación de la IP, huella del cliente, ritmo de peticiones. Un atacante con proxies residenciales y un cliente bien configurado pasa esos filtros, y quien paga la fricción es el usuario legítimo. mTLS no puntúa ni estima: o el cliente presenta un certificado emitido para ese dispositivo y firmado por tu cadena de CA, o el handshake TLS no se completa. El rechazo ocurre en la capa de transporte, antes de que tu aplicación vea la petición, y no hay nada que el usuario tenga que resolver.
¿Funciona en iOS y Android? ¿Y en apps híbridas?
El SDK es nativo y cubre las dos plataformas principales: Android e iOS. Para las híbridas (React Native, Flutter y Capacitor) todavía no hay soporte: estamos investigando cómo darlo y no hay fecha comprometida, así que preferimos decirlo antes de que integres nada. Si tu app es híbrida, indícalo al pedir acceso a la beta: nos sirve para priorizar cuál abordamos primero.
¿Si ShieldCert se cae, se queda mi login fuera de servicio?
Conviene separar las dos comprobaciones. La validación de la cadena de confianza la hace tu propio Nginx contra tu CA, sin salir de tu infraestructura. La comprobación de revocación sí es en línea: Nginx se configura con ssl_ocsp on y consulta al respondedor OCSP. Para acotar ese acoplamiento, las respuestas OCSP se cachean un minuto, lo que reduce el volumen de consultas y absorbe una interrupción breve del respondedor. Una caída más larga que esa ventana sí afecta a los handshakes nuevos: es el precio de verificar la revocación en línea en lugar de dar por bueno un certificado hasta que caduque, y es un compromiso que preferimos explicar antes que esconder.
¿Cómo se revoca un certificado comprometido y cuánto tarda en propagarse?
Hay dos caminos. El manual: marcas el certificado del dispositivo como revocado desde el panel, el respondedor OCSP deja de darlo por válido y la siguiente validación en tu backend lo rechaza; con la caché OCSP de un minuto, la propagación tarda como mucho esa ventana. El automático: un agente desplegado en tu propia infraestructura lee el syslog, determina si un certificado ha sido comprometido y lo notifica para que se bloquee, sin que nadie tenga que estar mirando un panel. Además los certificados son de corta duración y rotan solos, lo que acota la ventana de un certificado filtrado aunque nadie llegue a revocarlo a mano.
En qué punto está ShieldCert
Estamos en beta cerrada. En vez de logos de clientes que todavía no podemos nombrar, esto es lo que puedes comprobar por ti mismo:
Beta cerrada, con acceso por solicitud
El acceso se concede caso por caso para poder acompañar cada integración. No hay lista de espera anónima.
Documentación técnica pública
La referencia de integración es pública y se puede leer antes de pedir acceso, sin hablar con comercial.
La validación vive en tu infraestructura
Es tu Nginx el que exige el certificado y lo valida contra tu cadena de CA. La comprobación de revocación consulta al respondedor OCSP, con las respuestas cacheadas un minuto.
mTLS estándar, sin protocolo propietario
Por debajo es TLS mutuo del que ya entiende tu stack. Si mañana te vas, el mecanismo de autenticación sigue siendo estándar.
¿Lo probamos contra tu API de login?
Déjanos tu email y te damos acceso a la beta cerrada y a la documentación de integración.
¿Prefieres el correo? Escríbenos a [email protected]