Recientemente BASE4 Security estuvo presente en Santiago de Chile dictando una capacitación técnica sobre la solución RSA SecurID.
Para quienes no están relacionados con esta tecnología, les dejo a continuación algunas notas sobre su funcionamiento.
RSA SecurID es podría decirse, unos de los pioneros en la autenticación de doble factor, RSA es reconocida mundialmente por la robustez y calidad de sus productos, y en gran parte debido a esto es que tienen más de 25millones de tokens vendidos.
En esta oportunidad dimos un curso sobre la última versión disponible de RSA Securid, la 7.1, para los que no conocen la tecnología ni la terminología hago una breve introducción, existen tres formas de autenticar a alguien:
RSA SecurID es podría decirse, unos de los pioneros en la autenticación de doble factor, RSA es reconocida mundialmente por la robustez y calidad de sus productos, y en gran parte debido a esto es que tienen más de 25millones de tokens vendidos.
En esta oportunidad dimos un curso sobre la última versión disponible de RSA Securid, la 7.1, para los que no conocen la tecnología ni la terminología hago una breve introducción, existen tres formas de autenticar a alguien:
- Una forma es por medio del uso de una clave fija, es decir el usuario debe ingresar su contraseña al sistema que desea acceder y comúnmente se lo describe como “algo que se sabe , la clave.
- Otra forma sería con “algo que se tiene”, en este caso podemos hacer un ejemplo con las tarjetas magnéticas de acceso.
- Finalmente un tercer factor de autenticación es el biométrico, es decir “algo que somos”, por ejemplo un lector de huellas digitales.
Pero hasta aquí por separado siguen siendo cada uno un único factor de autenticación, si unimos por lo menos dos de los factores anteriores tendremos un doble factor de autenticación, un ejemplo claro de doble factor es la tarjeta del cajero automático, donde un factor es tener la tarjeta en sí “algo que se tiene”, y el segundo factor es “algo que se sabe”, es saber el PIN o clave a la hora de ingresar la tarjeta en el cajero, con este método el banco logra autenticar a sus usuarios mediante un doble factor.
La solución de RSA Securid está formada en esencia por una base de datos, el servicio de autenticación o “Authentication Manager”, las consolas de administración “GUI” y los tokens.
La forma más popular en que RSA brinda el servicio de doble factor de autenticación es mediante el uso de tokens, el más usado es el denominados KEY FOB, básicamente es un llavero con un display que muestra un número el cual cambia cada 60 segundos. Este llavero está compuesto de 4 elementos, una CPU, un reloj sincronizado UTC, el algoritmo que es una función hash y una semilla o clave secreta diferente en cada token y puesta desde su fabricación. Combinando esos 4 elementos el llavero es capaz de otorgar claves diferentes cada 60s. (faltó mencionar una pila pero a efectos de la autenticación en sí, no es necesario)
Del lado de servidor, básicamente se tienen los mismos 4 elementos, todos igualmente importantes, pero el fundamental es la semilla del token, por cada token que se tiene en el sistema, también se tiene su semilla, cuando se adquieren tokens nuevos, también se adquieren las semillas o claves que le permitirán al sistema generar las mismas claves que sus tokens.
Siguiendo con los componentes de la solución podemos mencionar a la base de datos, que es donde se almacenan datos de usuarios, grupos, perfiles, políticas de autenticación (es decir, longitud de las claves, intentos fallidos etc) y las semillas de los tokens.
Otro componente es el servicio de autenticación, el servicio que permitirá manejar el proceso de autenticación en sí y donde básicamente se comparan claves, la clave ingresada por un usuario con un token asignado, con la generada internamente de la semilla del token.
Podemos decir hasta aquí que el servidor “sabe” qué token tiene asignado cada usuario, en algún momento a un usuario dado se le asigno un token en el sistema (en realidad se le asigno la semilla), por lo tanto también “sabe” el valor que espera recibir en un determinado momento para cada usuario, un ejemplo para aclarar:
Supongamos que el usario A tiene el token TOKEN1, y a las 14:50:00s el servidor de autenticación recibe un requerimiento de autenticación de dicho usuario A, el servidor utilizará la semilla del TOKEN1 (previamente ingresada al sistema cuando se adquirió el TOKEN1 y luego asignado a A), mas el horario en que entro el requerimiento, 14:50:00s, mas el algoritmo, mas su CPU para calcular una clave, esta clave debería ser igual a la ingresada por el usuario A, de esta forma A es autenticado y tendrá acceso al sistema.
En este punto aclaro dos cosas:
La solución de RSA Securid está formada en esencia por una base de datos, el servicio de autenticación o “Authentication Manager”, las consolas de administración “GUI” y los tokens.
La forma más popular en que RSA brinda el servicio de doble factor de autenticación es mediante el uso de tokens, el más usado es el denominados KEY FOB, básicamente es un llavero con un display que muestra un número el cual cambia cada 60 segundos. Este llavero está compuesto de 4 elementos, una CPU, un reloj sincronizado UTC, el algoritmo que es una función hash y una semilla o clave secreta diferente en cada token y puesta desde su fabricación. Combinando esos 4 elementos el llavero es capaz de otorgar claves diferentes cada 60s. (faltó mencionar una pila pero a efectos de la autenticación en sí, no es necesario)
Del lado de servidor, básicamente se tienen los mismos 4 elementos, todos igualmente importantes, pero el fundamental es la semilla del token, por cada token que se tiene en el sistema, también se tiene su semilla, cuando se adquieren tokens nuevos, también se adquieren las semillas o claves que le permitirán al sistema generar las mismas claves que sus tokens.
Siguiendo con los componentes de la solución podemos mencionar a la base de datos, que es donde se almacenan datos de usuarios, grupos, perfiles, políticas de autenticación (es decir, longitud de las claves, intentos fallidos etc) y las semillas de los tokens.
Otro componente es el servicio de autenticación, el servicio que permitirá manejar el proceso de autenticación en sí y donde básicamente se comparan claves, la clave ingresada por un usuario con un token asignado, con la generada internamente de la semilla del token.
Podemos decir hasta aquí que el servidor “sabe” qué token tiene asignado cada usuario, en algún momento a un usuario dado se le asigno un token en el sistema (en realidad se le asigno la semilla), por lo tanto también “sabe” el valor que espera recibir en un determinado momento para cada usuario, un ejemplo para aclarar:
Supongamos que el usario A tiene el token TOKEN1, y a las 14:50:00s el servidor de autenticación recibe un requerimiento de autenticación de dicho usuario A, el servidor utilizará la semilla del TOKEN1 (previamente ingresada al sistema cuando se adquirió el TOKEN1 y luego asignado a A), mas el horario en que entro el requerimiento, 14:50:00s, mas el algoritmo, mas su CPU para calcular una clave, esta clave debería ser igual a la ingresada por el usuario A, de esta forma A es autenticado y tendrá acceso al sistema.
En este punto aclaro dos cosas:
- El ejemplo anterior es un ejemplo de un único factor de autenticación, para tener dos factores, se utilizará además del número que muestra el token (TOKENCODE) un PIN o clave que será destinada para cada usuario. Al PIN + el TOKENCODE, RSA lo denomina PASSCODE.
- La segunda es que el servidor debe estar en hora, también sincronizado UTC. Sin bien tiene un margen de tolerancia de + - 2 minutos.
Por último, las consolas o GUI son también elementos que forman parte de la solución, y son las interfaces por medio de las cuales la administraremos.
Algunos comentarios para finalizar, hasta la versión 6.1 no se tenía un soporte nativo con LDAP, es decir si bien se podían tomar usuarios de un Active Directory, la forma era copiando y replicando esos usuarios en la base interna de RSA. Hoy en la versión 7 los usuarios se mantienen en el LDAP sin necesidad de duplicarlos en dos bases.
Se mejoro el proceso de autogestión de tokens y se soportan tokens sobre demanda, es decir el uso de token por SMS y MAIL.
Gran parte de la solución se reescribió completamente en java, logrando mayor portabilidad e integración. Lo malo es que se tornó muy demandante de recursos, por ejemplo, montar una maqueta standalone, requiere de por lo menos 4Gb de RAM y un procesador de cuatro núcleos para funcionar correctamente.
Algunos comentarios para finalizar, hasta la versión 6.1 no se tenía un soporte nativo con LDAP, es decir si bien se podían tomar usuarios de un Active Directory, la forma era copiando y replicando esos usuarios en la base interna de RSA. Hoy en la versión 7 los usuarios se mantienen en el LDAP sin necesidad de duplicarlos en dos bases.
Se mejoro el proceso de autogestión de tokens y se soportan tokens sobre demanda, es decir el uso de token por SMS y MAIL.
Gran parte de la solución se reescribió completamente en java, logrando mayor portabilidad e integración. Lo malo es que se tornó muy demandante de recursos, por ejemplo, montar una maqueta standalone, requiere de por lo menos 4Gb de RAM y un procesador de cuatro núcleos para funcionar correctamente.
Escrito por el Ing. Carlos Liteplo, Director de Ingeniería de BASE4 Security, y especialista en soluciones RSA y Check Point.
Si desea saber más sobre esta tecnología no dude en contactarnos a info@base4sec.com
No hay comentarios:
Publicar un comentario