Las ideas no duran mucho, hay que hacer algo con ellas

juliorestrepo.wordpress.com desde el año 2008

Autenticación por Doble Factor y Cambio de Canal

A continuación copio y pego a manera de backup de internet artículo tomado de http://www.csospain.es/Autenticacion-por-Doble-Factor/seccion-tecnologias/articulo-197396 :

Fragmento más relevante (a mi parecer)

El proceso podría seguir los siguientes pasos:

– El usuario entra en el sistema con su usuario y contraseña. Tal vez en este punto se podría incluir un Doble Factor tipo tarjeta de coordenadas.
– Llega al punto donde se configura una transferencia o pago de alto impacto por su cuantía.
– El sistema lanza un desafio (pregunta relativa a la transacción o a información adicional) al teléfono móvil o a un dispositivo (RSA, Vasco, CIDWAY etc). Un sistema de desafío algo burdo, pero efectivo, es visualizar en el navegador una lista de combinaciones de letras y números y pedir al cliente, por el canal externo, alguna información al respecto.

Este desafío, al haber cambiado de canal, no puede ser interceptado por el atacante. El atacante, todo lo más que hará, es ver una posible lista de desafíos, pero no sabe cual se ha preguntado al cliente mediante el otro canal.
– El cliente contesta con el segundo canal, la respuesta correcta al desafío planteado.
– El sistema central realiza la transacción una vez confirmada.

Todo esto sobre el papel es tremendamente fácil, pero claro, las cosas en la vida real pueden complicarse extraordinariamente.

Autenticación por Doble Factor

Un sistema informático que recibe conexiones de clientes o usuarios para realizar operaciones, presenta tres problemas de seguridad:
– El servidor debe asegurarse que el usuario es quien dice ser y no se está suplantando su identidad.
– El usuario debe asegurarse que el servidor es el auténtico y no está siendo engañado por un atacante
– Que la comunicación, en caso de ser intervenida, no sea legible para el atacante.

Los sistemas basados en DF se presentan para asegurar el primer punto, es decir, evitar la suplantación de identidad del usuario. Se utilizan normalmente, bien al ingresar en el sistema o bien para confirmar operaciones especiales o de alto riesgo.

Conceptualmente hay dos formas de suplantar la identidad de alguien:
– El atacante conoce su mecanismo de autenticación, generalmente usuario y contraseña.
– El atacante se mete en medio de la comunicación, echa al usuario y se hace pasar por él.De todos es sabido que existen troyanos especializados en capturar pulsaciones de teclado y enviarlas al atacante para suplantar la identidad de la víctima. Los sistemas antivirus son una buena medida, pero por desgracia no son infalibles.

Además, lo “malos” comparte constantemente información actualizada de cómo evitar que los troyanos sean detectados e incluso de cómo detener el antivirus sin que el usuario pueda darse cuenta.

Este tipo de troyanos atacan los sistemas de autenticación basados en “lo que el usuario sabe”, es decir, usuario y contraseña, y opcionalmente, clave de operaciones. En algunos casos se solicitan algunas posiciones de la clave de operaciones y en otros se pide la clave entera. Simplemente es cuestión de tiempo el hacerse con el valor de todas las posiciones y por tanto de toda la clave.

Los sistemas de Doble Factor van más allá de “lo que el usuarios sabe” e incluyen el concepto de “lo que el usuario tiene” (y el atacante no puede tener). Por lo general, ese dispositivo que el usuario tiene, genera una contraseña de un solo uso (OTP, One Time Password) que para nuestra desgracias puede ser capturada por el atacante una vez generada. Realmente, el objetivo es utilizar un sistema de autenticación ajeno al canal que estamos usando, de esta forma no dependeremos de las debilidades asociadas al medio.

No olvidemos algo básico y es que en el el proceso de autenticación hay un cliente con un ordenador usando un navegador en el que es relativamente sencillo inyectar código. Este es el quid de la cuestión. La inyección de código y el secuestro de sesión son nuestros puntos débiles.

No debemos caer en el error de pensar en la fortaleza de los actuales sistemas de teclados virtuales, donde las teclas se colocan de forma aleatoria y el usuario hace clics de ratón para marcar los número. Evidentemente, es más que nada, pero existen troyanos especializados en capturar pulsaciones de este tipo de teclados.

En realidad los sistemas de Doble Factor ponen las cosas más difíciles, que no es poco, pero no son la panacea universal. Si un atacante captura un usuario-contraseña, podrá suplantar la identidad de la víctima siempre que quiera hasta que sea descubierto. Mediante un Doble Factor solo podrá suplantar la identidad de la víctima en el momento que esta usa el mecanismo de Doble Factor y además se ha interceptado la sesión, ya que el atacante no puede generar una OTP válida para esa sesión.

Mecanismos de Doble Factor
Tarjeta de coordenadas: dispositivo tipo tarjeta de crédito que contiene una serie de valores a lo largo de unas filas y columnas. Una vez que se han pedido todas las posiciones, la tarjeta puede anularse y emitir otra o bien se puede volver a reutilizar.  Aún reutilizándose, el sistema garantiza una importante reducción en el fraude en aquellas entidades que lo usan.
El sistema tiene dos debilidades. Una sería un troyano que pacientemente capturara todas las posiciones del la tarjeta y ésta fuera reutilizable. La otra sería un phising o secuestro de DNS que terminara pidiendo al usuario todas las posiciones de la tarjeta y éste las comunicara. Esto, por increíble descabellado que pueda parecer, ha ocurrido alguna vez.
En algunas entidades, en lugar de pedir el valor de una posición, piden de forma aleatoria el valor de algunos caracteres dentro de esa posición. Esto realmente no refuerza la seguridad, simplemente alarga el proceso del troyano que captura los valores.
Ya existen troyanos específicos para interceptar sesiones en sistemas que usan tarjeta de coordenadas como elemento de Doble Factor. Por lo general son troyanos diseñados específicamente para un banco concreto.

–  OTP, contraseñas de un solo uso: estos sistemas son de distinto tipo. Los hay basados en tiempo, es decir utilizan la hora del dispositivo y la del servidor para establecer la validez de la OTP que se ha generado. Los hay basados en mecanismos tipo desafío/respuesta, es decir, el servidor hace una pregunta que se introduce en el token o dispositivo y éste genera una respuesta únicamente válida para el desafío previamente introducido.
Estos sistemas son robustos frente al phising tradicional y siempre y cuando estén bien planteados. Si por ejemplo el sistema le da una vida a la OTP de 24 horas es muy probable que nos puedan hacer un phising sin dificultad. En cualquier caso, ante un secuestro de sesión se muestran ineficaces dado que la OTP va a caer en manos del atacante y va a disponer de un mínimo tiempo para poder utilizarla.

Certificados digitales:el uso de certificados digitales es conceptualmente muy distinto a una OTP, sin embargo su robustez es similar. Son atacables en la medida que se produce un secuestro de sesión, lo cual evidentemente no es sencillo, pero se hace. Personalmente entiendo que un certificado digital debe ir en una tarjeta EMV o similar (DNI electrónico), nunca instalado permanentemente en el repositorio del navegador. Por desgracia los navegadores no son precisamente robustos.

El estándar CAP-EMV:posiblemente las tendencias de futuro puedan ir por aquí. CAP es un estándar propuesto por MasterCard y aceptado por VISA. El objetivo es generar un token usando los mecanismos cristalográficos inherentes a una transacción financiera basada en chip EMV. El token está vinculado de forma inequívoca al chip a la tarjeta (y a la transacción) lo cual permite que pueda considerarse una OTP en un entorno de autenticación.
Como vemos, el gran caballo de batalla es la interceptación de la sesión. Los mecanismos de los que hemos hablado son una buena solución en parte, pero son todos vulnerables a un secuestro de sesión. ¿Cual es la solución?: Cambiar el canal de autenticación.

Cambio de Canal
La autenticación basada en un elemento ajeno al canal y que requiera de información de la transacción que ha de ser introducida por el usuario en el mecanismo, representa el medio más fiable para asegurarse de la identidad del cliente y evitar suplantaciones.
Vamos a poner un escenario a ver cómo podríamos implementar un sistema basado en el cambio de canal.
Imaginemos un sistema bancario donde la gerencia ha decidido que para confirmar la identidad del usuario se va a implementar un sistema de autenticación o confirmación de Doble Factor. Seamos mal pensados e imaginemos que el ordenador del cliente no solo tiene un troyano capaz de inyectar código HTML sino que además permite secuestrar la sesión mediante un “hombre en medio”.
El proceso podría seguir los siguientes pasos:

– El usuario entra en el sistema con su usuario y contraseña. Tal vez en este punto se podría incluir un Doble Factor tipo tarjeta de coordenadas.
– Llega al punto donde se configura una transferencia o pago de alto impacto por su cuantía.
– El sistema lanza un desafio (pregunta relativa a la transacción o a información adicional) al teléfono móvil o a un dispositivo (RSA, Vasco, CIDWAY etc). Un sistema de desafío algo burdo, pero efectivo, es visualizar en el navegador una lista de combinaciones de letras y números y pedir al cliente, por el canal externo, alguna información al respecto.

Este desafío, al haber cambiado de canal, no puede ser interceptado por el atacante. El atacante, todo lo más que hará, es ver una posible lista de desafíos, pero no sabe cual se ha preguntado al cliente mediante el otro canal.
– El cliente contesta con el segundo canal, la respuesta correcta al desafío planteado.
– El sistema central realiza la transacción una vez confirmada.

Todo esto sobre el papel es tremendamente fácil, pero claro, las cosas en la vida real pueden complicarse extraordinariamente. Por ejemplo:
– Puede que la organización, banco etc tenga múltiples canales que habría que dotar de Doble Factor.
– No todos los mecanismos de Doble Factor son adecuados para todos los canales.
– No todos los usuarios son receptivos a ciertas tecnologías.
– El costo de la tecnología debe ser el adecuado para el impacto que se pretende evitar.
– La diversidad en cuanto a los mecanismos de Doble Factor implica aumento del coste de implantación de los distintos sistemas.
– Deben existir procedimientos adecuados de entrega, utilización y uso de elementos físicos de Doble Factor en caso de que existan.

Hemos hablado del uso del teléfono móvil o de dispositivos externos para la recepción de desafíos y/o el envío de respuestas, y claro, aparece la primera pregunta: ¿El móvil es seguro?.
Bueno, esto es fuente para un artículo dedicado en exclusividad a este tema. En cualquier caso el móvil tiene una inmensa ventaja: todo el mundo tiene. Todo lo que sea el uso del móvil como herramienta de recepción de desafíos y envío de respuestas, tiene un nivel de riesgo que entra dentro de lo razonable. Otra cosa es instalar software en el móvil orientado a la generación de OTP´s, es ya es harina de otro costal porque al final estamos llevando al móvil los problemas que ya tienen los PC´s.

Un SMS puede cambiar la configuración del móvil sin apenas darnos cuenta. El Bluetooth que por defecto todo el mundo tiene activado, se ha convertido en una fuente de vulnerabilidades importante. BlueBug, BlueJacking, BlueSnarfing, Roving Bug etc etc son algunos de los posibles ataques que se pueden perpetrar contra un móvil.

En cuanto a dispositivos externos orientados a generación de OTP´s etc cabe destacar RSA (http://www.rsa.com/), VASCO (http://www.vasco.com/) y CIDWAY (http://www.cidway.com/) entre otros. Personalmente pienso que lo realmente seguro es el uso de estos dispositivos. En su contra cabe destacar que tienen un coste adicional que no tiene el móvil.

Tomado de: http://www.csospain.es/Autenticacion-por-Doble-Factor/seccion-tecnologias/articulo-197396

 

Autenticación por Doble Factor

Un sistema informático que recibe conexiones de clientes o usuarios para realizar operaciones, presenta tres problemas de seguridad:
– El servidor debe asegurarse que el usuario es quien dice ser y no se está suplantando su identidad.
– El usuario debe asegurarse que el servidor es el auténtico y no está siendo engañado por un atacante
– Que la comunicación, en caso de ser intervenida, no sea legible para el atacante.

Los sistemas basados en DF se presentan para asegurar el primer punto, es decir, evitar la suplantación de identidad del usuario. Se utilizan normalmente, bien al ingresar en el sistema o bien para confirmar operaciones especiales o de alto riesgo.

Conceptualmente hay dos formas de suplantar la identidad de alguien:
– El atacante conoce su mecanismo de autenticación, generalmente usuario y contraseña.
– El atacante se mete en medio de la comunicación, echa al usuario y se hace pasar por él.De todos es sabido que existen troyanos especializados en capturar pulsaciones de teclado y enviarlas al atacante para suplantar la identidad de la víctima. Los sistemas antivirus son una buena medida, pero por desgracia no son infalibles.

Además, lo “malos” comparte constantemente información actualizada de cómo evitar que los troyanos sean detectados e incluso de cómo detener el antivirus sin que el usuario pueda darse cuenta.

Este tipo de troyanos atacan los sistemas de autenticación basados en “lo que el usuario sabe”, es decir, usuario y contraseña, y opcionalmente, clave de operaciones. En algunos casos se solicitan algunas posiciones de la clave de operaciones y en otros se pide la clave entera. Simplemente es cuestión de tiempo el hacerse con el valor de todas las posiciones y por tanto de toda la clave.

Los sistemas de Doble Factor van más allá de “lo que el usuarios sabe” e incluyen el concepto de “lo que el usuario tiene” (y el atacante no puede tener). Por lo general, ese dispositivo que el usuario tiene, genera una contraseña de un solo uso (OTP, One Time Password) que para nuestra desgracias puede ser capturada por el atacante una vez generada. Realmente, el objetivo es utilizar un sistema de autenticación ajeno al canal que estamos usando, de esta forma no dependeremos de las debilidades asociadas al medio.

No olvidemos algo básico y es que en el el proceso de autenticación hay un cliente con un ordenador usando un navegador en el que es relativamente sencillo inyectar código. Este es el quid de la cuestión. La inyección de código y el secuestro de sesión son nuestros puntos débiles.

No debemos caer en el error de pensar en la fortaleza de los actuales sistemas de teclados virtuales, donde las teclas se colocan de forma aleatoria y el usuario hace clics de ratón para marcar los número. Evidentemente, es más que nada, pero existen troyanos especializados en capturar pulsaciones de este tipo de teclados.

En realidad los sistemas de Doble Factor ponen las cosas más difíciles, que no es poco, pero no son la panacea universal. Si un atacante captura un usuario-contraseña, podrá suplantar la identidad de la víctima siempre que quiera hasta que sea descubierto. Mediante un Doble Factor solo podrá suplantar la identidad de la víctima en el momento que esta usa el mecanismo de Doble Factor y además se ha interceptado la sesión, ya que el atacante no puede generar una OTP válida para esa sesión.

Mecanismos de Doble Factor
Tarjeta de coordenadas: dispositivo tipo tarjeta de crédito que contiene una serie de valores a lo largo de unas filas y columnas. Una vez que se han pedido todas las posiciones, la tarjeta puede anularse y emitir otra o bien se puede volver a reutilizar.  Aún reutilizándose, el sistema garantiza una importante reducción en el fraude en aquellas entidades que lo usan.
El sistema tiene dos debilidades. Una sería un troyano que pacientemente capturara todas las posiciones del la tarjeta y ésta fuera reutilizable. La otra sería un phising o secuestro de DNS que terminara pidiendo al usuario todas las posiciones de la tarjeta y éste las comunicara. Esto, por increíble descabellado que pueda parecer, ha ocurrido alguna vez.
En algunas entidades, en lugar de pedir el valor de una posición, piden de forma aleatoria el valor de algunos caracteres dentro de esa posición. Esto realmente no refuerza la seguridad, simplemente alarga el proceso del troyano que captura los valores.
Ya existen troyanos específicos para interceptar sesiones en sistemas que usan tarjeta de coordenadas como elemento de Doble Factor. Por lo general son troyanos diseñados específicamente para un banco concreto.

–  OTP, contraseñas de un solo uso: estos sistemas son de distinto tipo. Los hay basados en tiempo, es decir utilizan la hora del dispositivo y la del servidor para establecer la validez de la OTP que se ha generado. Los hay basados en mecanismos tipo desafío/respuesta, es decir, el servidor hace una pregunta que se introduce en el token o dispositivo y éste genera una respuesta únicamente válida para el desafío previamente introducido.
Estos sistemas son robustos frente al phising tradicional y siempre y cuando estén bien planteados. Si por ejemplo el sistema le da una vida a la OTP de 24 horas es muy probable que nos puedan hacer un phising sin dificultad. En cualquier caso, ante un secuestro de sesión se muestran ineficaces dado que la OTP va a caer en manos del atacante y va a disponer de un mínimo tiempo para poder utilizarla.

Certificados digitales:el uso de certificados digitales es conceptualmente muy distinto a una OTP, sin embargo su robustez es similar. Son atacables en la medida que se produce un secuestro de sesión, lo cual evidentemente no es sencillo, pero se hace. Personalmente entiendo que un certificado digital debe ir en una tarjeta EMV o similar (DNI electrónico), nunca instalado permanentemente en el repositorio del navegador. Por desgracia los navegadores no son precisamente robustos.

El estándar CAP-EMV:posiblemente las tendencias de futuro puedan ir por aquí. CAP es un estándar propuesto por MasterCard y aceptado por VISA. El objetivo es generar un token usando los mecanismos cristalográficos inherentes a una transacción financiera basada en chip EMV. El token está vinculado de forma inequívoca al chip a la tarjeta (y a la transacción) lo cual permite que pueda considerarse una OTP en un entorno de autenticación.
Como vemos, el gran caballo de batalla es la interceptación de la sesión. Los mecanismos de los que hemos hablado son una buena solución en parte, pero son todos vulnerables a un secuestro de sesión. ¿Cual es la solución?: Cambiar el canal de autenticación.

Cambio de Canal
La autenticación basada en un elemento ajeno al canal y que requiera de información de la transacción que ha de ser introducida por el usuario en el mecanismo, representa el medio más fiable para asegurarse de la identidad del cliente y evitar suplantaciones.
Vamos a poner un escenario a ver cómo podríamos implementar un sistema basado en el cambio de canal.
Imaginemos un sistema bancario donde la gerencia ha decidido que para confirmar la identidad del usuario se va a implementar un sistema de autenticación o confirmación de Doble Factor. Seamos mal pensados e imaginemos que el ordenador del cliente no solo tiene un troyano capaz de inyectar código HTML sino que además permite secuestrar la sesión mediante un “hombre en medio”.
El proceso podría seguir los siguientes pasos:

– El usuario entra en el sistema con su usuario y contraseña. Tal vez en este punto se podría incluir un Doble Factor tipo tarjeta de coordenadas.
– Llega al punto donde se configura una transferencia o pago de alto impacto por su cuantía.
– El sistema lanza un desafio (pregunta relativa a la transacción o a información adicional) al teléfono móvil o a un dispositivo (RSA, Vasco, CIDWAY etc). Un sistema de desafío algo burdo, pero efectivo, es visualizar en el navegador una lista de combinaciones de letras y números y pedir al cliente, por el canal externo, alguna información al respecto.

Este desafío, al haber cambiado de canal, no puede ser interceptado por el atacante. El atacante, todo lo más que hará, es ver una posible lista de desafíos, pero no sabe cual se ha preguntado al cliente mediante el otro canal.
– El cliente contesta con el segundo canal, la respuesta correcta al desafío planteado.
– El sistema central realiza la transacción una vez confirmada.

Todo esto sobre el papel es tremendamente fácil, pero claro, las cosas en la vida real pueden complicarse extraordinariamente. Por ejemplo:
– Puede que la organización, banco etc tenga múltiples canales que habría que dotar de Doble Factor.
– No todos los mecanismos de Doble Factor son adecuados para todos los canales.
– No todos los usuarios son receptivos a ciertas tecnologías.
– El costo de la tecnología debe ser el adecuado para el impacto que se pretende evitar.
– La diversidad en cuanto a los mecanismos de Doble Factor implica aumento del coste de implantación de los distintos sistemas.
– Deben existir procedimientos adecuados de entrega, utilización y uso de elementos físicos de Doble Factor en caso de que existan.

Hemos hablado del uso del teléfono móvil o de dispositivos externos para la recepción de desafíos y/o el envío de respuestas, y claro, aparece la primera pregunta: ¿El móvil es seguro?.
Bueno, esto es fuente para un artículo dedicado en exclusividad a este tema. En cualquier caso el móvil tiene una inmensa ventaja: todo el mundo tiene. Todo lo que sea el uso del móvil como herramienta de recepción de desafíos y envío de respuestas, tiene un nivel de riesgo que entra dentro de lo razonable. Otra cosa es instalar software en el móvil orientado a la generación de OTP´s, es ya es harina de otro costal porque al final estamos llevando al móvil los problemas que ya tienen los PC´s.

Un SMS puede cambiar la configuración del móvil sin apenas darnos cuenta. El Bluetooth que por defecto todo el mundo tiene activado, se ha convertido en una fuente de vulnerabilidades importante. BlueBug, BlueJacking, BlueSnarfing, Roving Bug etc etc son algunos de los posibles ataques que se pueden perpetrar contra un móvil.

En cuanto a dispositivos externos orientados a generación de OTP´s etc cabe destacar RSA (http://www.rsa.com/), VASCO (http://www.vasco.com/) y CIDWAY (http://www.cidway.com/) entre otros. Personalmente pienso que lo realmente seguro es el uso de estos dispositivos. En su contra cabe destacar que tienen un coste adicional que no tiene el móvil.

Un comentario el “Autenticación por Doble Factor y Cambio de Canal

  1. lingual braces
    septiembre 13, 2012

    Hey there! Someone in my Facebook group shared this website with us so
    I came to look it over. I’m definitely enjoying the information. I’m bookmarking and will
    be tweeting this to my followers! Superb blog and superb design.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Información

Esta entrada fue publicada en noviembre 18, 2009 por en Redes, Seguridad Informática y etiquetada con , , , , , .
A %d blogueros les gusta esto: