Cada día vamos añadiendo más funcionalidades a nuestro servicio Latch, y las últimas que hemos anunciado tienen que ver con cosas que ya están en producción en algunos de nuestros clientes. Hoy os quiero hablar de una de ellas para que las podáis probar en vuestra app de Latch y, si queréis, después implementar en vuestros propios servicios. Recuerda, que primero debes tener una cuenta de Latch tal y como se explica en este artículo: Cómo comenzar a utilizar Latch en tu vida digital.
 |
| Figura 1: Prueba un sistema de Adaptive Authentication en nuestro banco |
La característica que hemos añadido a Latch son lo que llamamos "Instancias". Una Instancia en Latch no es nada más que una Operación (OperationID) personalizada para un Usuario Concreto (AccountID) de la Aplicación (ApplicationID). Es decir, en Latch antes podías crear en la web de desarrolladores las operaciones que estarán disponibles para todos los usuarios de esa aplicación, pero ahora, si quieres que cada usuario tenga sus propias operaciones puedes crearlas dinámicamente en forma de Instancias. Vamos a ver cómo funciona esto en un ejemplo de uso.
Autenticación Adaptativa en base a dispositivo con Latch
Por ejemplo, podríamos crear a cada usuario una "Instancia" por cada dispositivo al que se conecta, aplicando así una política de Adaptive Authentication. Vamos a utilizar Nevele Bank como ejemplo, así que primero sácate una cuenta de Nevele Bank tal y como se explica en este artículo: Probar las operaciones de Latch con Nevele Bank. En el vídeo se explica con detalle todo el proceso.
Figura 2: Uso de Latch en Nevele Bank
En el caso de Nevele Bank hacemos eso mismo de forma muy sencilla para esta demostración utilizando el valor del campo User-Agent del dispositivo de conexión a la web. Cada vez que se hace un login exitoso desde un dispositivo, la web de Nevele Bank comprueba el valor User-Agent y si no está en la lista de dispositivos de confianza le pregunta al usuario si es o no un nuevo dispositivo de confianza que quiera registrar para el sistema de Adaptive Authentication.
 |
| Figura 3: Nuevo dispositivo detectado |
Si lo registra, automáticamente la web de Nevele Bank lo meterá en la lista de dispositivos de confianza que el usuario podrá comprobar desde la misma web y eliminar en cualquier momento. Si no lo registra seguirá siendo un dispositivo "Desconocido".
 |
| Figura 4: Lista de dispositivos de confianza en una cuenta de Nevele Bank |
Pero además, creará una instancia en la aplicación de Latch para ese usuario en concreto dentro de la operación Login, por lo que a partir de este momento el usuario podrá configurar su política de Adaptive Authentication en función - en este caso - del dispositivo que esté usando. Podría configurar que para el dispositivo de confianza el Login está abierto, pero para los desconocidos el login está cerrado.
 |
| Figura 5: Instancias creadas para este usuario en función de sus dispositivos de confianza |
Esto abre posibilidades a que también el usuario pueda configurar las opciones de apertura programada con el Schedule de cada Operación, o poner un OTP para unos dispositivos y para otros no, o configurar el Autolock por tiempo o por uso para unos dispositivos sí y otros no. Estas configuraciones permiten configurar un balance de decision entre lo que quiere el usuario y lo que quiere la web del banco.
Autenticación Adaptativa en base a método de identificación
Para nosotros, un sistema de identificación debe cumplir un equilibrio en cuatro escalas que el responsable del sistema de identidad tendrá que evaluar. Deberá elegir para cada aplicación o cada parte de ella, aquellos sistemas que cumplan los requisitos de:
- Universalidad: Que sean utilizables por la mayor cantidad de usuarios en la mayor cantidad de situaciones.
- Robustez: Que cumpla con los mínimos de seguridad que se ha estimado para ese sistema o aplicación.
- Usabilidad: Que haga la vida lo más fácil posible al usuario posible dentro de los requisitos de robustez y cumplimiento regulatorio que se exijan.
- Cumplimiento Regulatorio: Que cubran los requisitos marcados por la legislación, la política de seguridad o las certificaciones que tenga el sistema o la aplicación.
Dicho esto, podría darse el caso que para una aplicación muchos sistemas de autenticación cumplieran con los valores marcados para él en los 4 ámbitos anteriores o por el contrario solo uno lo permitiera. Todo esto lo tenéis mejor explicado en el WhitePaper que explica nuestra estrategia de identidad.
Por ejemplo para una web de información no importante, a lo mejor con usuario y contraseña valdría, pero si el riesgo reputacional exige mayor robustez o el cumplimiento de una regulación exige un segundo factor de autenticación, tal vez hubiera que moverse a una autenticación con Usuario+Contraseña+OTP o Usuario+Contraseña+Latch o a usar un DNIe con PIN, o una SmartCard+Biometría, etcétera. Este es un ejemplo con SmartID.
Por ejemplo para una web de información no importante, a lo mejor con usuario y contraseña valdría, pero si el riesgo reputacional exige mayor robustez o el cumplimiento de una regulación exige un segundo factor de autenticación, tal vez hubiera que moverse a una autenticación con Usuario+Contraseña+OTP o Usuario+Contraseña+Latch o a usar un DNIe con PIN, o una SmartCard+Biometría, etcétera. Este es un ejemplo con SmartID.
Figura 7: Autenticación robusta con DNIe, Biometría, NFC, Latch y SmartCards con SmartID
Al final, lo suyo es que el sistema permita tantos sistemas de autenticación como sea posible que cumplan los requisitos de Robustez y Cumplimiento Regulatorio. Al abrir el abanico de posibilidades al usuario, aumenta por supuesto la Usabilidad (cada uno eligirá el más cómodo para él) y la Universalidad, al abrirse más el número de posibilidades.
Autenticación con Mobile Connect en Nevele Bank
En la web de Nevele Bank, además de con Usuario y Contraseña, de Usuario y Contraseña + Latch, de Usuario + Contraseña + Latch + Verificación de dispositivo, hemos añadido la posibilidad de autenticarte con Mobile Connect, lo que permite a todos los usuarios cuya operadora haya lanzando ya Mobile Connect (como es el caso de Movistar) el poder asociar su número de teléfono a su cuenta de usuario y después seleccionar Mobile Connect como forma de autenticarse.
 |
| Figura 8: Pareado de cuenta de Nevele Bank con Mobile Connect |
Primero hay que conectarse a la web de Nevele Banck y parear con Mobile Connnect, luego ya basta con poner el número de teléfono en la parte de login y aceptar el proceso.
En este vídeo tenéis una demostración de cómo funciona con una demo que hice en el programa Likes de #0.
 |
| Figura 9: Login con Mobile Connnect |
 |
| Figura 10: Autenticación con Mobile Connect en el terminal |
En este vídeo tenéis una demostración de cómo funciona con una demo que hice en el programa Likes de #0.
Figura 11: Autenticación Adaptativa con Latch, Mobile Connect y Biometría
Al final, como se ve en el vídeo, con Mobile Connect también se pueden elegir diferentes métodos de autenticación, basados en Click OK, o en PIN o incluso en el uso de biometría de huella dactilar usando FIDO. Es la web la que, en base a los parámetros definidos anteriormente la que debe dar al usuario las posibilidades que son válidas y que el usuario decida cuál le es más cómoda en cada instante.
¿Y tus sistemas? ¿Siguen utilizando solo usuario y contraseña? DO the BASICS!
Saludos Malignos!
No hay comentarios:
Publicar un comentario