lunes, octubre 31, 2016

Latch Cloud TOTP versus Google Authenticator

Cuando hablamos de un Segundo Factor de Autenticación, los tokens TOTP (Time One-Time Password) son unos de los más populares. Servicios tan populares como Google, Microsoft, Dropbox o Facebook tienen la posibilidad de configurar una protección extra de la cuenta añadiendo una verificación del código TOTP que el usuario tiene configurado. Hoy os quiero hablar de Latch Cloud TOTP que es otra de las novedades de las que hablamos en el pasado Security Innovation Day 2016 y de cuáles son los detalles y el pensamiento que nos ha llevado a crearlo. Que nadie piense que esto es un "combate" ni nada parecido a ver qué solución es mejor, sino solo una explicación de cuáles son los detalles que de Google Authenticator que nos hicieron crear Latch Cloud TOTP.

Figura 1: Latch Cloud TOTP vs. Google Authenticator

La idea del TOTP es tan sencilla como que un algoritmo, con la misma semilla de parametrización, genera en el lado del servidor y en el lado del cliente un código dependiente del tiempo. Es decir, en el lado del servidor y en el lado del cliente, cada cierto tiempo, se genera el mismo número - el mismo token -. Cuando un usuario va a realizar un proceso de login, primero debe proveer correctamente el usuario y la contraseña, y después de que se verifique que esta es correcta, se debe proporcionar el valor TOTP correcto.

Figura 2: Demo de Latch Cloud TOTP en Dropbox con Latch para iPhone y Lath para Apple Watch

La herramienta más popular para gestionar los tokens TOTP es Google Authenticator, y es válida para usar en servicios como Google, Microsoft, Dropbox o Facebook. Basta con configurar esta protección en tu cuenta y utilizar Google Authenticator para capturar el código QR que transmite la semilla al algoritmo TOTP que generará el código TOTP constantemente.

TOTP en Google Authenticator

Durante mucho tiempo hemos estado jugando con los códigos TOTP de Google Authenticator, y hemos estado haciendo muchas pruebas que paso a contaros, porque creo que son relevantes para entender por qué decidimos hacer un Cloud TOTP en Latch.
1) No garantiza un único dispositivo: Cuando estás configurando un código TOTP en el cliente de Google Authenticator u otro similar, realmente al servidor no se le avisa de en cuantas apps se ha capturado la semilla. Es decir, podrías generar en la misma app de Google Authenticator 4 entradas con la misma semilla y al mismo tiempo copiar en cuatro dispositivos con Google Authenticator la misma semilla, y al mismo tiempo en otras apps. 
2) La semilla se podía robar del backup: Antiguamente, cuando se hacía un backup del sistema operativo, de este se podían sacar los ficheros de las semillas y conseguir regenerar el algoritmo correcto para tener los TOTP en cualquier otro dispositivo. Esto tenía un lado positivo y un lado negativo. 
El lado positivo es que podrías migrar de tu iPhone 6 a tu iPhone 6S todo un backup, y las entradas de Google Authenticator seguían intactas, lo que era una ventaja si se te había perdido el terminal o te lo habían robado, por lo que si tenías el backup podrías recuperar tu Google Authenticator con todas las entradas. 
Figura 3: Robar semillas TOTP de bakup de iOS
El lado negativo es que alguien podría extraer del backup tus ficheros de Google Authenticator y recrear en una app controlada por él tus valores y tener los TOTPs de todas tus cuentas. Además, para que este ataque fuera un poco más sencillo, se unen dos debilidades que pueden aprovecharse que os describo en los puntos 3 y 4.
3) En Google Authenticator se indica el usuario: En cualquiera de las entradas de los TOTP se puede leer con claridad la cuenta de correo a la que está asociada esa entrada TOTP, lo que pone bastante fácil saber a quién hay que robarle la contraseña. De hecho, lo más fácil era hacerse con el backup de Google Authenticator, ver cuáles eran las semillas de los algoritmos TOTP que se habían robado, y hacerles un ataque de phishing a esos para robarles el último factor que hacía falta - la password -.
Figura 4: En cualquier Google Authenticator se ven los tokens TOTP y los usuarios
4) En Google no implementan correctamente las alertas TOTP: Como ya he dicho en otras ocasiones, si te roban la password en Google y entran en tu cuenta, saltaría la verificación del token TOTP, pero no queda ninguna alerta de seguridad en el log si no se intenta poner ningún token, por lo que al atacante no se le detecta a la primera. En el caso de Microsoft, esto se implementa mejor.
Figura 5: En el log de Google no queda que se ha puesto correctamente la password
y no se ha introducido ningún token TOTP durante la verificación en dos pasos.
5) Ahora no migra de un terminal a otro: Para fortificar las semillas, en Google Authenticator ahora, estas se cifran en el keychain con una clave del dispositivo, por lo que es posible recuperar las semillas si y solo si es en el mismo dispositivo. Esto es un problema serio si has perdido el terminal, porque entonces solo te salvarán las Recovery Keys que se obtienen cuando se configura la protección TOTP o si tienes también puesto el número de teléfono, por el SMS (lo que vuelve a convertir el SMS en el primer factor de autenticación). Dependiendo del servicio, se podrían utilizar otros mecanismos como en el caso de Google que se permiten las llaves, los click-OK o los códigos impresos, pero no es lo habitual para todos los servicios protegidos con servicios TOTP, ni además son muy populares en su uso.
6) No protección local de Google Authenticator: En Google Authenticator, si alguien tiene acceso al terminal y abre la app, puede ver los valores de los tokens y a qué cuentas pertenecen porque no hay forma de ponerle una password a nivel de aplicación, tal y como se ve en la Figura 4.
Cloud TOTP en Latch

Sabiendo cómo funciona bien Google Authenticator, decidimos hacer una implementación que funcionara de manera distinta usando Latch a la que hemos llamado Cloud TOTP, que tiene las siguientes características:
1) Asociada a tu cuenta Latch: Cuando se pone un token TOTP en Google Authenticator, este se almacena en uno o varios dispositivos y - ahora - no puede salir de ahí, pero al servidor no se le garantiza ni que se haya puesto en un terminal concreto ni que se haya puesto solo en uno. En este caso, cambiamos el paradigma y lo ponemos en una cuenta de Latch que puede ser abierta en cualquier dispositivo móvil siempre que tengas tu cuenta de Latch (no asociada a tu cuenta protegida con el token TOTP)
2) Sin identificar nombre de cuenta asociada: Aunque en la primera versión utilizamos el mismo funcionamiento de Google Authenticator y mostrabamos la cuenta de usuario, hemos decidido que se pueda renombrar durante el proceso de configuración y después, para que en lugar de poner micuenta@google.com pueda poner algo genérico como "Mi cuenta de Google" o "Mi cuenta de Dropbox", con lo que se disasocia en Latch Cloud TOTP el valor del token del valor de la cuenta y del valor de la contraseña.
Figura 6: El token no se muestra hasta que no se solicita. Queda en el log

3) Con log de acceso al código:
Hemos decidido que en Latch Cloud TOTP, el valor del token no se muestre nada más que durante un instante. Para eso el token TOTP de cualquier semilla estará oculto y se deberá solicitar su muestra. Esto implica que se generará una entrada en el log de Latch que el usuario podrá consultar en el futuro para saber si desde esa app, en un momento concreto, se mostró o no se mostró el código TOTP. No evita las malas implementaciones del servidor, pero sí que permite guardar información que podría ser útil en un posible análisis de logs cruzado con los datos del servidor.
4) Protección de acceso local a Latch: Además de que el código TOTP de una cuenta no se muestra por defecto y debe solicitarse manualemente, dejando un rastro en el log, la app de Latch tiene dos protecciones: Una primera la autenticación contra el servidor, y una segunda la autenticación a nivel de app (integrada con Touch ID en iPhone e iOS). Esto hace que, aunque se tenga el terminal desbloqueado en un descuido, no se pueda acceder a ella sin poner la password o pasar una autenticación biométrica vía Touch ID.
Figura 7: La app de Latch se protege en local con autenticación y por Touch ID en iOS

Con esta aproximación de Latch Cloud TOTP lo que hemos buscado es cubrir un hueco en el uso de tokens TOTP. Dotamos al sistema de una mayor flexibilidad al permitir que los tokens se puedan recuperar desde cualquier dispositivo, y añadimos mayores opciones de seguridad en aspectos como el acceso local vía descuido, la asociación de token TOTP a nombre de cuenta o el control de los tokens TOTP que se entregan, ya que no es un proceso continuo sino discreto bajo demanda que deja rastro en el log.

Figura 8: Cloud TOTP y Latches en la misma app de seguridad

Ahora está disponible en la nueva versión de Latch para Android, y en breve estará disponible en la nueva versión de Latch para iOS. Poco a poco os iré contando por aquí como sacarle provecho a todas las características de este Cloud TOTP en diferentes servicios y entornos. Y lo mejor es que puedes tener en una sola app tanto tus tokens TOTP como tus cuentas protegidas por Latch.

Saludos Malignos!

17 comentarios:

fbueno.net dijo...

Comparar Latch Cloud TOTP con Google Authenticator es, un poco, como comparar peras con manzanas. Ambas son frutas, sí, pero diferentes, luego partimos de productos no equivalentes. A mi me gustaría haber visto una comparativa con Authy, que también tiene la funcionalidad de almacenamiento en la nube, por lo que también es multidispositivo y ahora sí tendríamos dos productos equivalentes para comparar.

Chema Alonso dijo...

Hoy justo son peras con peras. Lee el artículo y luego me comentas. Saludos!

EME dijo...

¿Y el que el TOTP sea accesible desde la nube no desvirtúa la autenticación en dos pasos? Si un atacante se hace con los credenciales de Latch y de, por ejemplo, la cuenta de Google, podría entrar en esta última aun con la verificación en dos pasos, ya que puede obtener el código iniciando sesión desde un móvil en la cuenta de Latch. Es verdad que el usuario sería advertido con una notificación en su teléfono, pero mientras no compruebe su móvil el atacante puede obtener toda la información de la cuenta de la víctima.

EME dijo...

Por cierto, Google Authenticator ahora sí que deja cambiar el nombre asignado a las cuentas.

Chema Alonso dijo...

Te has dado tu la respuesta. Dos cuentas, dos pasos.

Chema Alonso dijo...

True. Lo han metido.

RCO raul dijo...

Me parece muy buen producto Latch.

Lo que no me acaba de convencer es que parece que no tiene el mantenimiento que se merece un producto así.
Por ejemplo, owncloud no se actualiza desde 2015 compatible con la versión 7.0.3 y ya van por la 9.1 la cual no es compatible. Wordpress lo mismo, última revisión hace 6 meses, versión 4.4.2 y la actual es la 4.6.1. En jenkins lo mismo...

En el entorno profesional estos detalles me crean incertidumbre de si actualizo depende que software deje de funcionar y puede darme algún dolor de cabeza.

Por todo esto no me crea una seguridad para usarlo habitualmente. Si habilito la verificación en 2 pasos de varios servicios personales y por falta de actualización se me bloquea no me haría gracia.

Saludos

diego dijo...

latch o google autenticator usa o extrae algun dato del telefono como para que asocien numero de telefono o imei con un mail de gmail¿ o es solo una apareamiento de datos

Inseguro y Navegando dijo...

Buenas,
Me parece estupendo y sobre todo que ya se pueda en Facebook teniendo en cuenta que dependiendo de la configuracion de privacidad del navegador, ni tan siquieras podras activar el 2FA con G-Authenticator hasta pasado unos dias, tiempo en la que tu cuenta mediante dicho metodo de seguridad sera imposible protegerla y asi lo expresan en una ventana emergente.

Tengo una cuenta de Facebok para pruebas, a ver si ocurre lo mismo o algo similar con Latch, ya dire cosas...

Saludos y gracias ;-)

David dijo...

Hola Chema, desde que leí este artículo no dude ni un sólo instante en instalar y configurar Latch y estoy mucho más feliz y tranquilo, sin embargo en mí teléfono no me deja bloquear los TOTP para impedir el acceso a mis servicios, por lo tanto a mí personalmente me encantaría que si el servicio lo tengo bloqueado pues qué el servidor de Latch no me envíe el TOTP, así garantizo más que el servicio efectivamente sí quedó bloqueado en caso de cualquier cosa que pueda llegar a ocurrir

David dijo...
Este comentario ha sido eliminado por el autor.
Chema Alonso dijo...

@David, no avisa si no introduces ningún TOTP. Es decir, el atacante prueba la password y cuando le sale la verificación TOTP no introduce nada. SaludoS!

Unknown dijo...

@David
Lo del pais no es un problema, te recomiendo que leas el siguiente articulo para comprender un poco mejor el compartamiento del G-Authenticator:
Saltar el bloqueo de cuentas Google es un juego de niños

Si es cierto que a día de hoy, te pide el password cada vez que abres un nuevo servicio de la cuenta todo Google, cosa sigue sin tener mucho sentido, desde mi punto de vista debería de pedir el password de la cuenta y el código de 6 dígitos (2-FA)

Saludos!

David dijo...

@Unknown no tienes el contexto ni la visibilidad de lo que pasa por detrás cuando haces esos tests que mencionas en el articulo. Lo de que te deje entrar .crom o .pot o hotMIAL en lugar de hotmail o gmail es a propósito, dado que ya te ofrecen, para proveedores de email conocidos como gmail o hotmail, el dominio en la pregunta, así que no es que sea un problema saber que es lo correcto y permitir leves fallos de escritura cuando estas exponiendo el dominio correcto es simplemente para mejorar la usabilidad, no añade ninguna seguridad adicional.

En cuanto a la localización, muchos de esos "challenges" no son para tu vecino intentando hackear tu cuenta. De hecho muchos, si no todos, los phishing kits de hoy en dia capturan tu IP y la geolocalizan, usando luego un proxy para intentar acceder con tus credenciales. Por eso se anima a los usuarios en general a utilizar doble factor de autenticacion, cosas como las security keys (https://support.google.com/accounts/answer/6103523?hl=es), a utilizar Password Alert (https://support.google.com/a/answer/6197508?hl=es) y a utilizar dispositivos o # de telefono asociados a la cuenta para poder avisar al verdadero dueño de la cuenta y demás medidas que la gente en general no usa.

Tengo la seguridad de que muchas de las cosas que se han mencionado aquí son muy útiles (por ejemplo el mostrar intentos de OTP fallidos) y bueno, creo que deberían implementarse y que en un momento dado se implementaran. También hay que tener en cuenta que como cualquier otra empresa, da igual Google, Microsoft, Twitter o Facebook, se da prioridad a los proyectos de acuerdo al impacto global. Y si por ejemplo un nuevo sistema de detección de , tiene mas impacto que mostrar los intentos fallidos, pues se dejara lo de los intentos para mas tarde para dedicar los recursos a lo que tenga mas impacto.

De todos modos, esta siempre bien que se destaquen las carencias o fallos de los sistemas porque eso ayuda a mejorar.

Gracias por eso.

Jonathan Novel dijo...

@David
Buenas, creo que a lo que se refería Unknown es al desafío de seguridad que lanzaba en su día Google y no al comportamiento del Google Authenticator, actualmente si compara el email, por lo visto si era un error por parte de Google decir que se iba a comparar con el almacenado en su base de datos y no hacerlo, por lo tanto si es importante pero si es cierto que lo del país y muchas mas información que se solicitaba en el desafío en su día no era una gran barrera para cualquiera con un poco de ingenio, como dice en el texto del articulo con buscar un poco en la redes sociales basta...

Saludos!

David dijo...

@Jonathan lo que no comparaba es la parte del dominio y sigue sin hacerlo, pero solo para dominios que son mostrados ya como parte de la pregunta y con una desviación de pocos caracteres, por ej. gmial.com podria funcionar pero ginmail.com no.

De todos modos, Chema tenia razon en que no se avisa cuando hay un OTP fallido o abandonado, pero creo que es algo que veremos muy pronto.

Jonathan Novel dijo...

@David
En una de estas lo probare de nuevo, ahora mismo he intentados con varias Ips de distintos países para que me lanzara el desafío pero me deja pasar sin problemas >.< hace poco lo probe y si no recuerdo mal, tienes razón, creo que solo cambie el ".crom"

Entonces lo único que han cambiado es que te pide el password al abrir un servicio nuevo de la cuenta todo Google, pero que chorrada, no? si ya estas dentro? lo sabes y dicha cuenta no esta protegida con el 2.FA, así que al igual que tu, me siento mas tranquilo con Latch, todo es muy reciente, tiempo al tiempo.

Saludos! ;-)!

Entrada destacada

Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación de @0xWord

Desde hoy está disponible a la venta un nuevo libro de 0xWord centrado en la seguridad de los Sistemas Industriales y las Infraestructuras...

Entradas populares