Skip to content

Autenticación de doble factor … donde menos te la esperas

Publicado por Sergio Hernando el 20 septiembre 2010

Hola,

Hoy he charlado con un amiguete que trabaja como administrador de sistemas. Me estuvo preguntando qué opino sobre la doble autenticación, a lo que respondí como suelo responder a este tipo de preguntas. En primer lugar los tiempos han cambiado, y en vez de hablar de doble autenticación quizás debiéramos hablar de autenticación basada o proporcional al riesgo. Sí, en esencia es abstraer la pregunta a una capa superior, pero yo al menos prefiero hablar de riesgo y luego detenerme a hablar de factores. No obstante me guardé esto para después, para no aturullar a mi amigo con conceptos teóricos.

Le comenté que la doble autenticación, tal y como el la entendía, ha ido progresando. De la combinación lineal de factores (dos claves, una de autenticación y otra de confirmación) se ha ido pasando progresivamente al empleo de dos factores en distintos canales, como por ejemplo, los números de confirmación enviados a móviles, ya que al aumentar el número de canales normalmente debería incrementarse la fortaleza del sistema, reduciéndose en proporción el impacto del fraude. No obstante le dejé claro que la doble autenticación no es la panacea, que ha sido burlada en algunos escenarios y que de lo único que estoy seguro es que hoy en día tener un doble factor de autenticación en canales distintos es mucho mejor que tener dos factores lineales. Creo que le ha quedado claro que llegará el día que los factores independientes hoy considerados más fuertes estarán completamente rotos, pero probablemente cuando eso ocurra, los que lideran la tecnología de seguridad ya se habrán pasado a otros métodos que no se puedan comprometer de inmediato. Y así, sucesivamente.

Repasé con él el concepto de autenticar transacciones, no a personas. Reconozco ser un pesado con este tema, pero el problema primario del fraude es poder validar transacciones, no autenticar a individuos, especialmente en operativa de transaccionalidad (banca en línea, comercios, etc). Aproveché aquí para explicarle que al final se trata de ser consecuente con lo que quiere proteger, y que por tanto lo que importa no es el número de factores, sino que las medidas de protección sean acordes a lo que se quiere salvaguardar. Entendió bien que una banca en línea expuesta a Internet no requiere la misma fortaleza que proteger un servidor Web con datos estadísticos de menor importancia en una red local corporativa.

Por último le puse un ejemplo. Además bien reciente. Google empieza a dotar a Gmail y a sus aplicaciones de dobles factores de autenticación robustos. Se sorprendió bastante, ya que estos métodos de autenticación son novedosos incluso en grandes infraestructuras en línea transaccionales, con lo que la pregunta es obvia. ¿Por qué un proveedor como Google ofrece autenticación equiparable a la de muchas entidades financieras? Este es el momento en el que aprovecho para enlazar con lo que comentamos al principio. Al final, se trata de ser consecuentes con lo que se hace, y adecuar las medidas de protección al riesgo. ¿Te preocupa la problemática del robo de identidad y el fraude? En ese caso, el movimiento se demuestra andando, y andar aquí es implementar medidas revolucionarias para un segmento que tradicionalmente se ha amparado en métodos simples de autenticación.

Los tiempos han cambiado y los troyanos más elementales te levantan las credenciales de tu correo, tu banco en línea o tu proveedor de tarjetas de crédito con extrema facilidad. ¿Qué hacer para proteger a los usuarios? Fácil. Mejorar lo que se tiene, como por ejemplo, implementando un segundo factor en un canal distinto, en este caso, un número de transacción enviado a un móvil. Ni más ni menos. Le costó poco comprender que esta medida y el porqué de dicha medida. Resultó fácil explicarle que además de proteger a los usuarios, estos movimientos sirven para que los amigos de lo ajeno pongan los ojos en otros objetivos más jugosos y menos protegidos. Ni hizo falta recurrir al clásico ejemplo de la calle llena de coches, y porqué un ladrón se fija habitualmente en el vehículo que menos medidas de protección tiene.

Espero que mi amigo se haya marchado con las ideas más claras. Al final se trata de conceptos básicos y elementales, pero que no siempre están al alcance de cualquiera. Nada que no se pueda lograr siguiendo una explicación lógica y razonada.

Un saludo,

Be Sociable, Share!

Categoría/s → Seguridad

2 comentarios
  1. 21 septiembre 2010
    Álvaro Del Hoyo permalink

    Buenas, Sergio

    Insisto en que en el proceso se han de dar varias autenticaciones, de identidad y de transacciones.

    El sistema Google Authenticator va justo por donde te adelantaba en este otro comentario. Parece que el código está abierto así que…

    http://www.sahw.com/wp/archivos/2010/07/20/3-d-secure-verified-by-visa-mastercard-securecode-el-principio-del-fin/#comment-54472

    Google lo hace porque su negocio es la confianza de los usuarios, especialmente cuando ya 30 millones de organizaciones han recurrido a sus servicios de cloud computing con una cantidad no poco despreciable de usuarios a nivel personal. Necesitan que los usuarios profesionales y personales mantengan el uso de sus servicios, y aceptando sus políticas de privacidad, puedan presentar publicidad online, pues ésta supone el 95% de sus ingresos.

    En el caso de la banca online sucede lo mismo si bien en el análisis de riesgos los bancos no han de tener en cuenta tanto la importancia la banca electrónica que tiene para su negocio globalmente considerado, sino el impacto que para la confianza de sus clientes tienen los incidentes de seguridad, o el impacto en su imagen corporativa,… Creo que no es para nada despreciable desarrollar aplicaciones móviles que permitan autenticación de los usuarios de banca electrónica por medio de soluciones tipo Google Authenticator. Con el dinero que se ahorrará en el envío de SMS el banco se puede pagar el desarrollo de las aplicaciones móviles, no?

    A ello se podría añadir la autenticación vía IMSI, si bien ello precisa la enttega previa al banco de tal dato, así como el perjuicio de provisión de nueva IMSI en caso de duplicación de SIM, disposición de nueva SIM (casos de pérdida o portabilidad a otro operador). La aplicación móvil debería transmitir el dato de la IMSI, pero me temo que ello implicaría depender del operador.

    Un saludo

Trackbacks & Pingbacks

  1. de la red – 20/09/2010 « Tecnologías y su contexto

Escribir un comentario

Note: XHTML permitido. Tu email nunca será publicado.

Suscribirse a los comentarios via RSS