Generación del token

El Token Digital se implementará utilizando el algoritmo TOTP (Time based One-Time Password), de acuerdo con la especificación RFC 6238, que usará una semilla cifrada mediante AWS Cloud HSM. Para el proceso de generación se tiene en cuenta:

Identificador de acceso de la clave

Se usará el User Id que maneja actualmente Spin. Es un tipo de dato UUID, para su transmisión se usará su valor como cadena de texto y para la generación de tokens su valor como arreglo de bytes con longitud de 128 bits

Clave para generar OTP

La clave o semilla para ser usada por el algoritmo debe tener las siguientes características:

• Aleatoriedad: Uso de generador de números aleatorios seguros.

• Longitud: 256 bits

• Unicidad: (Validar) Garantizar que no haya 2 semillas iguales

• Secreto: Confidencialidad durante la generación y transmisión

• Almacenamiento seguro: La clave se cifrará mediante AWS Cloud HSM y se almacenará una vez cifrada en MongoDB

• Revocabilidad: Implementación de métodos para refrescar o eliminar la clave.

Algoritmo de cifrado para HMAC

La generación del token digital requiere el uso de HMAC (Hash-based Message Authentication Code), por lo que es necesario hacer uso de un algoritmo para generar el digest. Inicialmente se considera SHA-256, aunque es posible realizar la modificación a otro algoritmo como SHA3.

Longitud del token

El token generado será un número de 32 bits, aunque sólo se considerarán los 9 dígitos decimales menos significativos.

Autenticación de servicios

La comunicación interna se hará usando el protocolo gRPC, se propone el uso de Linkerd como mecanismo de autenticación interna.

Acceso a los servicios

El acceso a los servicios se hará a través del servicio de agregación, que expondrá los métodos mediante gRPC y REST. El clúster deberá estar en la misma VPN de los servicios consumidores, y expone una API Key para su acceso.

Algoritmos y librerías utilizadas para la generación, aprovisionamiento y seguridad del token

Para la generación de la semilla, se implementó el paquete Java Security. En este proceso, se recurrió a la clase MessageDigest, que se nutrió del algoritmo SHA-256, permitiendo de esta forma la creación efectiva del digest.

Cuando se trata de almacenar la semilla en CloudHSM, es emplea la clase KeyGenerator. Esta facilita la tarea de cifrar la semilla utilizando el algoritmo AES, lo que nos permite su posterior almacenamiento seguro en CloudHSM.

Cuando se necesita retornar la semilla al cliente, esta se cifra utilizando una llave pública suministrada por el propio cliente. Para este proceso, hacemos uso del algoritmo RSA, lo que fortalece la seguridad y protección de la información del cliente.

Lineamientos de uso de Token digital

Características del consumidor

Al ser una solución de backend, gran parte de la seguridad de los servicios reposa sobre la seguridad del consumidor por quien interactúa con los distintos usuarios de la solución. Debido a lo anterior, para satisfacer los requerimientos de seguridad de FEMSA, el consumidor de los servicios de Token digital debe cumplir con las siguientes características:

Autenticación y autorización

• Los datos de acceso a los sistemas de información deberán estar compuestos por un ID o nombre de usuario y contraseña que debe ser única para cada usuario o tercero, exceptuando la primera autenticación.

• Se debe solictar al menos un identificador de usuario y un factor de autenticación de categoría 2 (mediante información que sólo el usuario conoce), 3 (contraseñas dinámicas de un solo uso) o 4 (mediante datos biométricos). La longitud del identificador de usuario deberá ser de al menos seis caracteres. El identificador de usuario deberá ser único para cada usuario y permitirá identificar todas las operaciones realizadas por el propio usuario.

• Se deberá utilizar un factor de identificación de categoría 3 (contraseñas dinámicas de un solo uso para ejecución de operaciones sensibles como el establecimiento de límites de monto, alta o cambio de cuentas destino, alta o cambio de datos de notificación, transferencias monetarias, pagos de servicios, pagos de impuestos o creación de tarjetas digitales. Estas contraseñas dinámicas deben tener un tiempo de validez no mayor a dos minutos, solo puede ser utilizada una vez, debe tener una longitud de ocho posiciones y no debe ser replicable ni conocida previamente a su publicación.

• Durante el inicio de sesión se debe impedir la lectura de la información de identificación y autenticación del usuario en la pantalla del dispositivo de acceso sustituyendo con asteriscos la información.

• Deberá contar con un procedimiento para invalidar los factores de autenticación cuando un usuario o el negocio cancele el servicio de banca electrónica o cuando dicho usuario deje de ser cliente del negocio.

• Una vez iniciada la sesión por parte del cliente, debe mostrar la fecha y hora del último inicio de sesión y el nombre y apellido del usuario.

• Deberá establecer procesos y mecanismos automáticos para bloquear el uso de contraseñas y otros factores de autenticación cuando se intente ingresar a la aplicación utilizando información de autenticación incorrecta en hasta tres ocasiones consecutivas.

• Deberá proporcionar al cliente una opción para desactivar el servicio Pago Móvil o Banca Móvil de manera temporal en caso de requerirlo así como establecer procedimientos para reactivar el uso cuando el usuario lo disponga.

• Se deberá bloquear la clave del usuario si se han realizado 3 intentos fallidos (contraseñas inválidas).

• Se debe bloquear la clave de usuario si se ingresa de forma incorrecta cinco veces consecutivas, la cuenta debe ser bloqueada automáticamente por un periodo mínimo de 15 minutos la primera vez, y 360 minutos en caso de reincidencia dentro de las siguientes 24 horas o hasta que un administrador la desbloquee.(AA6)

• Se debe bloquear el usuario de proceso si se realizan cinco intentos fallidos de autenticación.

• No se permite cambiar la contraseña más de dos veces en un mismo día.

• Deberá evitar el acceso concurrente con un mismo identificador de usuario.

• Deberá contar con procesos de borrado de cuentas dentro de los sistemas.

• Deberá contar con un proceso para la administración de cuentas de administradores.

• Deberán existir controles técnicos para el acceso de usuarios privilegiados (Por ejemplo: doble factor de autenticación, filtros de IP, firewalls, comunicaciones encapsuladas, etc).

• Se deben indicar las características que debe cumplir la contraseña.

• Utilizar la autenticación condicional basados en geolocalización, dispositivo y transacción en los sistemas que lo permitan.

• Se deberá contar con un módulo de autogestión para el usuario, que le permite el desbloqueo y restablecimiento de contraseñas.

• La contraseña debe contener al menos tres de los siguientes cuatro tipos de caracteres: o Letra mayúscula. o Letra minúscula. o Número. o Carácter especial y/o de puntuación.

• El historial de contraseña debe incluir las 15 últimas.

• Deberá permitir a los clientes cambiar sus contraseñas o NIPs, solicitando al usuario la contraseña actual. Deberá permitir al usuario obtener una nueva contraseña en caso de haberla olvidado.

• Debe validar que las contraseñas tengan al menos 8 caracteres de longitud.

• La longitud mínima de la contraseña para cuentas de clientes debe ser de 6 caracteres

• La longitud mínima de la contraseña para cuentas de usuarios debe ser de 10 caracteres

• La longitud mínima de la contraseña para cuentas de administradores debe ser de 15 caracteres

• La longitud mínima de la contraseña para cuentas de servicio debe ser de 25 caracteres

• Se requerirá un doble factor de autenticación mediante contraseñas dinámicas de un solo uso (OTP) o envio de correo electronico y con una vigencia no mayor a 2 minutos durante el primer loggeo del usuario en la aplicación.

• Se requerirá un doble factor de autenticación mediante contraseñas dinámicas de un solo uso (OTP) o envio de correo electronico y con una vigencia no mayor a 2 minutos en los cambios respecto de los factores de autenticación.

• Se requerirá un doble factor de autenticación mediante contraseñas dinámicas de un solo uso (OTP) o envio de correo electronico y con una vigencia no mayor a 2 minutos en la alta y/o modificación del los medios de notificaciones al cliente

• Se requerirá un doble factor de autenticación mediante contraseñas dinámicas de un solo uso (OTP) o envio de correo electronico y con una vigencia no mayor a 2 minutos al momento de generar una operación crítica definida por el negocio (realizar un pago, hacer una solicitud de préstamo, alta/baja/cambio de beneficiarios, etc.)

• Después de 5 intentos fallidos de intento de sesión, se debe bloquear la cuenta de usuario por un segundo. La duración del bloqueo luego se duplica después de cada intento fallido adicional, hasta un máximo de 15 minutos.

• Deberá prever mecanismos y procedimientos por medio de los cuales el usuario deba cambiar la contraseña inmediatamente después de que la aplicación la haya definido o generado.

• Para el manejo de contraseñas, deberá mantener procedimientos que proporcionen seguridad en la información contenida en los dispositivos de autenticación en su custodia, la distribución, así como en la asignación y reposición de dichas contraseñas y factores de autenticación; no permitirá contar con mecanismos, algoritmos o procedimientos que les permitan conocer, recuperar o descifrar los valores de cualquier información relativa a la autenticación de sus usuarios.

• No está permitido el uso de patrones (repetición de caracteres, números o letras consecutivos, etc.) como autenticación de clientes.

• Deberá cifrar o truncar la información de las cuentas u operaciones de sus usuarios y cifrar las contraseñas, números de identificación personal (NIP), respuestas secretas, o cualquier otro factor de autenticación, en caso de que se almacenen.

• Está prohibido el uso de usuarios genéricos.

• La contraseña de cuentas de servicio o plataformas que no soportan doble factor de autenticación deben tener Expiración para usuario administrador de sistema 180 días.

• La contraseña de cuentas de servicio o plataformas que no soportan doble factor de autenticación deben tener h) Las cuentas de servicios no deben permitir inicio de sesión de ningún tipo (consola, escritorio remoto y/o red).

• La contraseña de cuentas de servicio o plataformas que no soportan doble factor de autenticación deben tener c) Expiración para cuentas de servicio sin bóveda de contraseñas 90 días, con bóveda de contraseñas no aplica.

• Debe verificar que exista el principio de privilegio mínimo: los usuarios solo deben poder acceder a funciones, archivos de datos, URL, controladores, servicios y otros recursos para los que poseen una autorización específica.

• Deberá estar autenticada por medio del AD de Digital@Femsa.

• Deberá autenticar la comunicación entre componentes.

• La función "Recordar contraseña" para las aplicaciones no se utilizará ni se habilitará. Si es posible, se aplicará a través de la configuración del sistema.

• Las contraseñas no estén basadas en algún dato que otra persona pueda adivinar u obtener fácilmente mediante información relacionada con la persona, por ejemplo, nombres, números de teléfono, fecha de nacimiento, etc

Manejo de la sesión

• Se deberá generar un nuevo Token por cada sesión.

• Deberá verificar que la aplicación no permita revelar tokens de sesión en parámetros de URL o mensajes de error.

• Se deberá validar que el cierre de sesión y la expiración invaliden el Token de la sesión, de modo que el botón de retroceso no reanude una sesión autenticada.

• Se requiere prevenir que la sesión pueda ser usada por un tercero, dando por terminada la sesión en caso de inactividad por más de 15 minutos, un minuto en caso de transacciones monetarias, o al identificar cambios relevantes en los parámetros de comunicación.

• Se requiere prevenir que la sesión pueda ser usada por un tercero, dando por terminada la sesión en caso de inactividad por más de 15 minutos.

• Se deberá comunicar al usuario que al momento de re-dirigir a servicios de terceros, se cerrará automáticamente la sesión abierta y que ingresará a otra cuya seguridad no depende ni es responsabilidad de Digital@Femsa.

• Se requiere que los tokens de sesión basados ​​en cookies tengan establecido el atributo 'Secure' , 'HttpOnly', 'SameSite' y ´__Host-'.

• Se deberá impedir el acceso en forma simultánea, mediante la utilización de un mismo Identificador de usuario.

• Se deben utilizar identificadores de sesión impredecibles.

• Se debe asegurar que el manejo de la sesión fuerce el paso de credenciales en cada llamada.

Gestión de Accesos e Identidades

• Deberá existir una adecuada segregación de funciones entre el rol de gestión de usuarios privilegiados y el resto de roles.

• Si requiere usuarios de servicio, debe contar con la aprobación del CTSO (CyberArk - (posiblemente)).

• Las ID de usuario de servicios deberán estar plenamente identificadas y solo pueden usarse si son necesarias. Estas deberán tener asignados siempre un custodio el cual será responsable de su uso.

• El acceso de los administradores al ambiente productivo sólo es permitido mediante el uso de bóveda de contraseñas.

Validación, limpieza y codificación

• Deben contar con controles que previenen ataques de fuerza bruta o de bloqueo de cuentas como CAPTCHA o limitación de velocidad.

• Debe de contar con store procedures u otros mecanismos protegidos contra inyecciones de código para las consultas a bases de datos.

• Debe de contar con mecanimos para prevenir inyecciones de código malicioso en plataformas, servidores web, servidores de aplicaciones y bases de datos.

Protección de datos

• Implementar mecanismos de enmascaramiento o anonimización si es necesario usar datos reales (interno, restringidos o confidenciales) en un ambiente no productivo.

• Evitar el almacenamiento en cachés de aplicaciones o balanceadores de carga, datos confidenciales y restringidos.

• Configurar una política de "limpieza" cuando se almacenan datos temporales en caché por un periodo para evitar su exposición.

Comunicaciones

• La gestión de las claves para datos en tránsito, deberán ser gestionadas por Digital@Femsa.

• Todos los sitios web deberán tener configurados los siguientes headers: X-Content-Type-Options, Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy.

• Los parámetros de la cadena de consulta (URL) de cualquier HTTP verb no deben contener datos confidenciales.

• La información transmitida mediante notificaciones y/o correos electrónicos no debe contener vínculos activos.

• Los componentes que se comunican a través de Internet deben validar la autenticidad del certificado (Certificate/Public Key Pinning) o usar un mecanismo de autenticación mutua.

• Los componentes de la aplicación deben validar las cadenas y los certificados TLS o utilizar mecanismos de autenticación mutua.

• Se deben utilizar certificados SSL válidos y validar la cadena para reconocer de forma unívoca al servidor.

• No deben utilizarse certificados “*” (wildcard) ni autofirmados.

• Los certificados, tanto internos como externos, deben ser emitidos por una autoridad de certificación reconocida por Digital@Femsa y la revocación tendrá que estar activada para un periodo máximo de dos años.

• El acceso remoto seguro debe controlarse estrictamente a través de la autenticación y las claves públicas / privadas con frases de contraseña fuertes o autenticación de dos factores.

Código malicioso

• Se deben ocultar todas las rutas referentes a acceso a consolas, portales de administrador, recursos de archivos, así como los reedireccionamientos a los mismos.

• Se deberá usar software que sea estrictamente requerido. Durante el desarrollo de herramientas o software, se deberán desactivar los componentes y bibliotecas que no se requieran.

• Se deberán realizar verificaciones y evaluaciones de software de terceros, incluyendo frameworks de desarrollo o bibliotecas de software populares.

• Se deben ejecutar los intérpretes con el nivel de privilegios mínimo.

Aprobación y consideraciones para subir código a respositorios de SPIN

Vulnerabilidades encontradas

Vulnerabilidad por CSRF(Cross-site request forgery)

Identificada al implementar la configuración y uso de Apykey como medio de autenticación entre servicios en el servicio Aggregation Service:

Esta vulnerabilidad fue revisada con el equipo de desarrollo de Spin ya que al implementar el ApiKey en todos sus servicios presentan el mismo problema. Se llego a la conclusión que se podía mantener como un falso positivo ya que los servicios están en una subnet privada y son accedidos por medio de un balanceador privado, por lo que solo pueden ser consumidos por los servicios de Spin.

Vulnerabilidades por licencias

Estas vulnerabilidades son identificadas en los diferentes jar de librerías de terceros como las de Spring, Tomcat, Lockbag, etc:

Estas son librerías ampliamente usadas y de momento se acordo verlos como falsos positivos, pero se quedó que en cuanto se actualizara la base de datos de Snyk y si siguen saliendo se evaluara la exclusion o remediación de estos.