Hoy quería responderos a esta pregunta que he puesto en el título. Imagina que un atacante tiene acceso a tu cuenta. Ha conseguido acceder a tu correo electrónico, a tu cuenta del banco, a tu cuenta de la empresa, a tu cuenta de Facebook o de Instagram. Ha conseguido acceder a tu ERP o a tu CRM. Piensa en ello. Lo ha conseguido porque te ha hecho un Session Hijacking, ha conseguido tus credenciales con un malware, o te ha robado un Token OAuth. O simplemente ha encontrado un bug en el código de la aplicación que ha conseguido explotar y tiene acceso a toda tu cuenta.
Figura 1: Si un atacante tiene acceso a tu cuenta... ¿Qué no te gustaría
que pudiera hacer? ¿Te gustaría poder bloquearle acciones?
Imagínatelo por un instante. Imagínatelo delante de tu cuenta bancaria, con acceso tu cuenta. Delante de tu cuenta de la empresa. Delante de tu correo electrónico. Piensa en ello. ¿Te da un escalofrío? Imagínatelo delante de tu cuenta de almacenamiento de fotos. Delante de tu iCloud. De tu Google Drive viendo tranquilamente una tras otra todas tus fotos. O todos tus documentos. O todos los mensajes que has enviado y recibido por Instagram.
Seguro que te da mal rollo.
Y es que, si tenemos toda la protección basada en un el sistema de Login, en la autenticación de la cuenta, estamos perdidos cuando llega una de esas situaciones. Cuando alguien consigue saltarse esa protección todo el sistema de privacidad se cae abajo.
Por eso inventamos Latch.
Por eso creamos un canal paralelo de autenticación que protege todos los datos y todas las acciones aún cuando un atacante se haya hecho con tus credenciales, con una cookie de sesión, o con un token OAuth de tu plataforma. Gracias que con Latch tienes un 2nd Factor Authorization puedes cerrar determinadas capacidades de tu cuenta aún cuando alguien esté dentro de ella.
La idea es tan sencilla como que mires tu aplicación o servicio y analices justo lo que dice el título de esta entrada: Si una atacante tiene un acceso a tu cuenta, ¿qué no te gustaría que pudiera ver, acceder, hacer, ejecutar? Y a cada una de esas cosas, le pones un Latch. Tan sencillo como eso.
Imagina que tienes una cuenta de administración de una servicio de gestión de una empresa en el que te autenticas con Login/Password y un Second Factor Authentication (que puedes ser un TOTP o un SMS-OTP, o incluso un Latch).
Una vez que pases el proceso de autenticación te encuentras con todas las opciones del menú, y entre ellas tienes que pensar cuáles son las que no te gustaría que tuviera acceso un atacante si tuviera acceso a tu cuenta. Por ejemplo, te hago esta lista:
- No me gustaría que pudiera borrar la cuenta.
- No me gustaría que pudiera editar mi perfil.
- No me gustaría que pudiera mandar mensaje en mi nombre.
- No me gustaría que pudiera eliminar mis mensajes.
- No me gustaría que pudiera hacer transferencias de dinero.
- No me gustaría que pudiera acceder a mis mensajes.
Lo que quieras. Y luego decides qué pestillos configuras para cada una de esas acciones. Nosotros, por ejemplo, en el proyecto de WordPress in Paranoid Mode que luego portamos a Joomla! también, definíamos esas acciones y las agrupábamos en tres modos. Hicimos tres pestillos (que se llaman operaciones) dentro de un Latch, así que cuando tenías una cuenta de WordPress, la pareabas con tu cuenta de Latch, y tenías tres operaciones dentro de Latch que eran Modo Read-Only, Modo Edición y Modo Administración.
Figura 3: Un Latch con tres Operaciones en forma de pestillos
Así, independientemente de que una cuenta fuera el Administrador del WordPress - ya sea legítimamente o por haber conseguido acceso de manera ilegítima -, cada vez que se iba a realizar una operación dentro de una tabla de WordPress se miraba si esa operación era de Edición o Administración y si era así, se comprobaba el estado del pestillo de Edición o Administración. Si está cerrado, se bloquea la operación y listo. Así, aunque te roben tus cuentas de WordPress, tu plataforma está segura contra modificaciones o accesos no deseados.
Figura 4: Presentación de My WordPress in Paranoid Mode
Si has hecho una plataforma para gestión de lo que sea, piensa en eso. Piensa en qué zonas de la cuenta de tu usuario no te gustaría que una persona con acceso ilegal a una cuenta pudiera tocar. Y pon un pestillo en ellas. Así, el dueño legítimo de la cuenta, que tiene control de sus pestillos desde el canal de Latch, siempre puede tenerlos cerrados hasta que vaya a hacer uso de esa capacidad y él conscientemente abra el pestillo.
Por ejemplo, en MyPublicInbox integramos Latch, y la operación de Desparear Latch, está protegida. Sólo si el pestillo de Latch está abierto se puede desparear, como se puede ver en la imagen anterior, y seguimos haciendo más operaciones para proteger más partes de tu cuenta con nuevas operaciones. Para esto, Latch es único, porque te ayuda a evitar que un atacante pueda acceder a tu privacidad, tus datos, tu información, tus funciones, incluso si te han robado el acceso a tu cuenta.
Figura 6: Cómo integrar Latch en aplicaciones .NET
Si quieres saber cómo funcionan estas operaciones en Latch, te recomiendo que te veas un Webinar de cómo configurar Operaciones en Latch. Aquí tienes uno que te explica cómo integrar Latch en aplicaciones .NET. Tienes de más lenguajes de programación, pero son todos muy similares.
Y si necesitas ayuda para implementar Latch, contacta con nosotros en Latch.tu.com y te ayudamos con el proceso de integración en tu plataforma, o en los sistemas de tu empresa. Si no tienes esta protección en tus plataformas de call-center, de ERP, de correo, de administración, de lo que sea, no te sorprendas el día que te roben una cuenta y quede todo totalmente expuesto o te hagan un destrozo completo en tu sistema.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)
No hay comentarios:
Publicar un comentario