13 julio 2011

Swivel Pinsafe: Autenticación Fuerte sin Tokens

Cuando empecé a escribir en SecurityByDefault, trabajaba como preventa técnico para un fabricante de Cortafuegos de Aplicaciones Web (o WAF), y de ahí que haya mencionado en varios posts este tipo de protección ante ataques de nivel 7 a las aplicaciones web.

Desde la semana pasada, y espero que por muchos años, he cambiado la protección web, los SQLi, XSS, RFIs y demás,… por otra empresa dedicada a la protección de accesos remotos mediante mecanismos de autenticación fuerte,... bastante curiosos.

Esta claro que los accesos usuario/contraseña únicamente, pueden llegar a ser bastante inseguros. Los riesgos: fuerza bruta, diccionario, robo de credenciales, troyanos, contraseñas almacenadas en claro, etc,…  Además de que, como hemos contado varias veces también, la gente utiliza contraseñas débiles por longitud, y baja complejidad, así como fácilmente adivinables.

Para determinadas conexiones, en las que con una autenticación se da acceso a toda una organización (por ejemplo mediante un acceso VPN), puede ser realmente peligroso dejarlo en manos de un único mecanismo por usuario/contraseña que no siempre cumple características de gran complejidad, que puede estar escrita en un post-it en el monitor o de fondo de pantalla del escritorio, que puede ser vox populi porque hubo que decírsela a alguien una vez para que pudiera hacer determinada operación o que simplemente ha sido robada por Shoulder Surfing al escribirla en el teclado varias veces. El principal peligro de una autenticación por usuario/contraseña es que éstas últimas, sean como sean, son estáticas.

Así pues, para otorgar un mayor nivel de seguridad para estos accesos, es por lo que se utiliza lo que se llama un 2FA o una autenticación de doble factor. En general, la autenticación fuerte por 2FA viene dado por la composición de una doble autenticación en base a tres tipos de factores: algo que se sabe (la contraseña), algo que se tiene (generalmente un token que genera un código OTP) y algo que se es (autenticación biométrica).

Para la autenticación biométrica, es necesario contar con dispositivos que sean capaces de "reconocer" una característica de los usuarios (la voz, el iris, la retina, las huellas dactilares, la disposición de las venas…). Esto, estando en la playa, por ejemplo ahora que empiezan los meses de vacaciones de verano, no resulta muy cómodo.

En menor medida, para poder acceder remotamente a una organización, no siempre es agradable tener que estar cargando en todo momento con el típico llavero rojo y azul que genera numeros aleatorios válidos durante un tiempo finito. Si olvidamos el token en el coche, en casa, en otra chaqueta, etc,… estaremos todo un día sin podernos autenticar y por ello, en algunas ocasiones, hasta trabajar. Por experiencia, si me dejo el móvil en casa, lo utilice o no como soft-token, vuelvo a por él.

Os quiero contar como es, a muy grandes rasgos, la solución de Swivel Secure, no porque trabaje para esa compañía desde este mes (que también :D), sino porque me ha parecido muy original, seguro y cómodo. PinSafe permite generar un One-Time-Code sin necesidad de llevar llaveros, tarjetas empresariales, tarjetas de coordenadas, chips, ni demás "amuletos". Lo único que hay que saberse es un PIN, además de tu usuario/contraseña. Pero ojo, el PIN que te sabes, no hay que ponerlo en ningún sitio, sino no valdría para nada al ser siempre el mismo. El dispositivo de autenticación presentará al usuario lo que se llama una "security string": básicamente una cadena de caracteres aleatorios que puede ser presentado en formato imagen de TURing, o enviado por SMS, email, a través de una aplicación de un dispositivo móvil (iPhone, Android, applet Java, Windows Mobile, etc,…) Los números del PIN que nos sabemos, marcará las posiciones de los caracteres de la security string que se nos presenta.


El OTC (One Time Code) que deberemos introducir será diferente en cada autenticación, pudiendo forzar las características del PIN (longitud, complejidad, nivel de repetición, etc,…). Incluso se puede hacer que las imágenes de TURing aparezcan animadas para evitar troyanos que monitorizan la  pantalla de un usuario infectado. Muchos diréis, oye pero si estás en un entorno con posibilidad de MiTM, se podrá averiguar el PIN también en base a analizar el TURing y los caracteres enviados. La respuesta es sí, pero siempre puedes hacer que el security string le llegue al usuario por un canal diferente (SMS, aplicación para móvil, etc,..), entonces será necesario tener troyanizada tu vida entera para que averigüen tu PIN.

Si queréis ver la presentación que hizo mi compañero Alex Rocha en el Asegur@IT 9, os dejo el video con la misma, bajo estas líneas.




Podéis comprobar por vosotros mismos algunas de las capacidades de la solución, así como la diversidad de productos empresariales con los que se integra.

16 comments :

Román Ramírez dijo...

Si, por ejemplo, me toca el PIN 1234 y me están haciendo MitM... Si la primera vez introduzco las posiciones "1", "2", "3" y "4"... ¿no le basta al atacante con esperar a que llegue la nueva cadena aleatoria y repetir las posiciones que yo haya metido en la primera vez?

Si ha capturado la security string cuando ha venido la primea vez y ha capturado los números introducidos por el usuario, deducir el PIN se me sugiere trivial.

En el fondo, por mucho OTC diferente que termines introduciendo, las posiciones siguen siendo las mismas que viene ser que introduces el PIN cada vez, en el fondo.

Incluso si te aseguras de que la Security String tenga cifras repetidas, para que sea más complejo deducir qué posiciones insertar el usuario, existe un componente de predictibilidad muy alto.

Lo lógico sería que la security string se reciba por otro canal (SMS, vasos de yougurt unidos con un hilito, un operador en la India que te llame y te lo cante con endecasílabos...) pero, si esa es la circunstacia... ¿para qué depender de un PIN si lo puedes transformar completamente en un OTP?

Sergio dijo...

Estoy con Román

Rodrigo Moreno dijo...

Yo quisiera saber en que parte de la Web puedo adquirir la solución para una pequeña empresa que quiero lanzar...

Lorenzo Martínez Rodríguez dijo...

Román... precisamente pongo en el post:

" Muchos diréis, oye pero si estás en un entorno con posibilidad de MiTM,
se podrá averiguar el PIN también en base a analizar el TURing y los
caracteres enviados. La respuesta es sí, pero siempre puedes hacer que
el security string le llegue al usuario por un canal diferente (SMS,
aplicación para móvil, etc,..), entonces será necesario tener
troyanizada tu vida entera para que averigüen tu PIN."

Es decir, si el security string y el PIN van por el mismo canal y estás en un entorno MiTM, efectivamente puede existir ese riesgo. Sin embargo, si van por canales diferentes, se minimiza bastante el problema que apuntas. ¿Cuándo dices que quieres que te lo demuestre ;D?

Lorenzo Martínez Rodríguez dijo...

Porque si te roban el dispositivo token, ya tienes el OTP... en este caso, te envían el security string, y el OTC hay que deducirlo mediante tu PIN

Lorenzo Martínez Rodríguez dijo...

Mándame un correo por privado y hablamos :)

sobradielero dijo...

Ok, entendí mal el método. 

Di por sentado que la autenticación solicita tanto contraseña como PIN (u OTP en su caso), con lo que no importa si te roban el dispositivo token.

Jose A. dijo...

Siento decir que esta solución no es original... en Nationale-Nederlanden por ejempolo llevo años viendola implementada. Exceptuando el uso de distintos canales para recibir los OTP.

Saludos.

Román Ramírez dijo...

Te compro que sea mejor lanzarlo por otro canal. También que si infectas el terminal, afectaría igualmente a un SecurID o un Vasco y su seed.

Pero en escenarios tales como un Galaxy Tab o un iPad, en el fondo, el usuario recibirá todo en el mismo elemento. Un bicho que se centrara en este tipo de autenticación igualmente tendría acceso a la validación por el segundo canal, con el agravante de haber "cazado" el PIN previamente.
Teniendo en cuenta que ese escenario aplica a cualquier modelo, ¿para qué complicarte la vida (y complicársela al usuario)?¿No es más simple enviar un OTP que no dependa para nada de un PIN potencialmente "predecible" o que tenga que tener el usuario en su lado? Si total, lo van a cazar indistintamente.

Lorenzo Martínez Rodríguez dijo...

Ok Román, evidentemente si el canal por el que se hace la autenticación y por el que se reciben los tokens es el mismo, efectivamente, si éste está comprometido, existe la posibilidad que apuntas. Si el otro 99% de los usuarios, reciben el SMS con la security string en un móvil normal y corriente y la auth la hacen desde otro dispositivo, no le encuentro el problema, la verdad

Lorenzo Martínez Rodríguez dijo...

Bueno, al menos hay una diferencia que hace mejor esta alternativa... :D Gracias por tu aportación. Buscaré el contacto de Nationale-Nederlanden para proponer Swivel jejeje

Alejandronf dijo...

tengo una duda mas que razonable, este metodo persenta la misma debilidad que las claves/usuarios de toda la vida.
Si el usuario por norma vago y descuidado tiene apuntado en un papelucho en su escritorio el pin, si alguien te ve introduciendolo , etc... en el caso de que tengas el pin ya estás con la puerta abierta ¿verdad?

un token fisico , el iris o disposicion de las venas ... o lo llevo yo encima o no hay tu tia ( si , si me arrancan los ojos xD)

no entiendo aparte del posible robo a traves de la red cual es la ventaja que aporta, es decir evitar un MITM porque el pin no viaja por la red, eso si está bien pero para lo demás es igual.

saludos

Lorenzo Martínez Rodríguez dijo...

Hombre,.. no sé que tan difícil es para alguien acordarse de un PIN de mínimo 4 dígitos. Lo haces para la tarjeta de crédito, el PIN del móvil, etc,..

No obstante, si el security string le llega al usuario por un canal diferente (como por ejemplo el móvil), incluso habiendo robado el "papelucho" con el pin, no podrías hacer nada sin robar el móvil del individuo.

El token físico te lo pueden robar (igual que el móvil). Las venas, iris etc, etc,.. el problema es que los dispositivos desde los que te autentiques han de tener un lector adecuado para esa autenticación: es un tema de comodidad el poder autenticarte en cualquier parte.

Alfonso dijo...

Esta claro que uno de los puntos debiles en la entrada son las passwords, y los sistemas de autenticación de doble factor son uno de los puntos mas importantes para la compañias. Existen muchas compañias que hacen este tipo de soluciones, yo he estado trabajando con una denominada StoneGate Authenticacion Server, que ademas de introducir sistemas de OTP, genera tambien OTP que pueden ser enviadas a través de SMS o correo electrónico.
Pero quizás un buen sistema es el que utiliza un token software, basado en una semilla y una medida de tiempo, de este modo, en caso de que se vea comprometida una semilla, no se ve comprometido todo el sistema, como paso hace unos meses con RSA, y que obligo a cambiar 40 millones de tokens.
Ademas, que seria de un sistema de Autenticación de doble factor sin un sistema de Identity Federation.
A todos los fabricantes les falta algo, eso no hay duda, pero siempre hay que buscar la solución que mejor se adapte a las necesidades del cliente
http://www.stonesoft.com/en/products/smc/authentication_server/

Invitado dijo...

Buen SPAM, me ha gustado

f0n dijo...

Al fin y al cabo es su blog :D, y es un blog de seguridad, y es un post de seguridad... no veo el spam por ningún lado :D