Foto de Towfiqu barbhuiya en Unsplash

Manrique Feoli | CEO de Hound Software

Uno de los principales factores que hay que tener en cuenta a la hora de asegurar un sistema informático es la autenticación del usuario, lo que significa validar que quien dice ser la persona que presenta las credenciales realmente es.

Un buen ejemplo de esto es cuando se quiere ejecutar una transacción bancaria desde el sitio web del Banco, uno podría recibir un mensaje de texto al teléfono celular conteniendo un código que a su vez deberá de ser ingresado al sistema web para confirmar la transacción. Este envío de un código por otro medio de comunicación se le conoce como como autenticación de múltiple factor, (o autenticación de segundo factor en este caso del banco).

Hay tres dimensiones o factores principales con los que se puede autenticar a un usuario: 

1. Algo que el usuario sabe: una contraseña, un dato secreto (ej: donde conoció a su actual pareja)
2. Algo que el usuario tiene: una tarjeta, un dispositivo USB, un teléfono celular, una llave.
3. Algo que el usuario es (característica biométrica): una huella digital, características faciales, características de la retina.

La validación por solo uno de esos factores ya no es suficiente en el mundo actual, especialmente utilizar solo el de usuario y la contraseña dado que la mayoría de los accesos indebidos están relacionados con credenciales robadas, adivinadas o recreadas (cosechadas) o sea tomadas de múltiples puntos en el ecosistema del usuario para adivinar con fuentes probables, peor aun cuando existe un mercado negro de lista de usuarios y contraseñas donde los delincuentes las adquieren.

Por lo tanto, la utilización de más de uno de estos tres factores incrementa en varios ordenes de magnitud el nivel de seguridad del acceso al sistema, a esto se le llama “autenticación por múltiples factores” o bien “segundo factor de autenticación” (asumiendo que solo queremos dos).

El segundo factor de autenticación per se, es una forma muy efectiva de mitigar los accesos indebidos relacionados con este tipo de credenciales mal habidas, dado que, adicionalmente a la validación de las credenciales normales, se coloca una nueva capa de seguridad que está relacionada con dos nuevas características:

a- Se recibe un token (código) que se crea en tiempo real.  

b- Se transfiere a un dispositivo que la persona tiene, el teléfono en este caso.

Con esto, asumiendo que un delincuente posee las credenciales robadas, las probabilidades de que también pueda tener acceso a ese código generado en tiempo real y a ese dispositivo específico (el teléfono) todo al mismo tiempo son -por mucho- inferiores, por lo que se reduce drásticamente, o al mínimo, la cantidad de accesos indebidos a los sistemas.

Por supuesto, no todo es perfecto, la autenticación de doble factor, por su naturaleza, a cambio de la seguridad que agrega, genera una mayor complejidad al usuario externo, sin embargo, los usuarios hemos ido aprendiendo a vivir con esa carga adicional en pro de mantener nuestros accesos y datos seguros.

¿Cómo implementarlo?  Pareciera, a primera vista poco experta, que es algo muy sencillo, al menos eso podría pensar un programador inicialmente si no considera todos los aspectos reales de seguridad involucrados.  

Por ejemplo, podría darse el caso que se resuelve generando el token en el propio sistema de la organización, almacenarlo y enviarlo al usuario por mensaje de texto, esto es un proceso sencillo y no tiene mucha ciencia.  Sin embargo, hacerlo de esta forma, sin las consideraciones de seguridad adecuadas está contraindicado dado que el token puede ser interceptado de múltiples formas, o hackeado directo de una BD, creando un punto único de falla de la seguridad con lo que el delincuente inhabilitaría todo el esquema.  Es importante notar que el manejo, la generación y la inhabilitación de los tokens es de gran criticidad en este proceso pues desde ahí mismo también se puede comprometer todo.

Una forma más adecuada es la delegación de la autenticación del token, o sea la generación del token por parte de un sistema externo que es quien se encarga de enviarlo y luego validarlo, estableciendo una conexión encriptada a nivel de canal y a nivel de datos. Esta última forma donde la generación y validación de los tokens no “vive” en los sistemas de la organización, incrementa la seguridad en la medida de que un ciberataque y acceso a las bases de datos de la organización no le da acceso heredado a todos los tokens de validación de cualquier usuario y por ende no inhabilita este otro sistema también. Ejemplos, en niveles básicos de esto se puede ver en los servicios de autenticación de LinkedIn, de Facebook, de Google entre otros más específicos para aplicaciones seguras hasta llegar a las de grado bancario que se ubican en la parte superior.

Por lo tanto, la debida implementación de un esquema de doble factor es de gran importancia y criticidad, y no debe de ser subestimado de ninguna manera, mucho menos ni relegado al programador de menor experiencia.   Debe ser debidamente diseñado, validado por un experto en seguridad y asegurado o bien integrado como servicio por un tercero experto.

Ya volviendo a la vida real, y a nivel global, debido a los niveles de ataques que se han estado experimentando, se está viendo que ya no solo se ha estado hablando de autenticación de múltiple factor en sistemas de transacciones bancarias sino también en sistemas ya de uso más común y menos crítico y de uso diario.

De ahí que nos encontremos en un tiempo donde la autenticación de identidad es más vital que nunca, y donde, curiosamente, la antigua línea de teléfono celular, que ya casi ninguno de nosotros utiliza para conversar, ha ido evolucionando y posicionándose como un medio y un dispositivo de validación de identidad, pues se puede asumir que casi todos tienen uno.