Contexto actual - Validación por medio de PIN
En la actualidad, SPIN soporta la autenticación de acciones protegidas mediante el uso de un PIN, que es solicitado cada vez que un usuario desea realizar la acción. El PIN actual es el mismo para cada operación y es asignado al usuario al momento del registro.
...
En éste flujo se verifica la validez del PIN mediante su comparación con su valor cifrado almacenado en la base de datos. Si la validación del PIN es exitosa se genera un token con base en el User Id, posteriormente el token es registrado en Redis para ser consultado en la próxima operación que lo requiera.
Cuando se ejecuta una acción protegida por PIN, junto con el payload de la acción se añade un HEADER de tipo x-pin-authorization junto con el valor de x-device-id. Cada servicio tiene integrado el filtro de validación de token, y de ser validado se elimina para evitar un nuevo uso.
...
Al realizar la autenticación del usuario mediante la contraseña pueden surgir PIN varios inconvenientes:
Olvido de token.
Exposición voluntaria/involuntaria de token. El token puede ser visto o compartido con terceros, aumentando la probabilidad de fraude.
Tiempo adicional de diligenciamiento de información, afectando la experiencia del usuario.
Para mitigar los efectos negativos de la autenticación usando contraseña, se propone el uso de token digital basado en OTP, que se envíe automáticamente durante las ejecución de las transacciones
Token digital
Comparado con el token basado en PIN, el token digital actuará como un mecanismo de autenticación que solicite automáticamente cada vez que el usuario realice una transacción, de ésta forma se evita la recordación y el ingreso del token manual por parte del usuario, y al ser generado durante cada transacción, se reduce el riesgo de exposición, lo que otorga mayor seguridad a la transacción al evitar que un posible atacante lo acceda. Éste tipo de token también es conocido como OTP (One time password).
OTP es una contraseña de un solo uso que se genera para una sola transacción de autenticación. Se genera por un algoritmo matemático que utiliza un valor secreto (secreto compartido) y un valor cambiante, dependiendo del tipo de implementación (puede ser un contador o la hora actual). La contraseña OTP generada es válida solo por un corto período de tiempo, generalmente unos pocos minutos, y solo puede ser utilizada una vez. Después de ese tiempo, la contraseña OTP expira y ya no es válida para su uso.
Los mecanismos de OTP que se consideran para la solución son:
HMAC-based One-Time Password (HOTP)
utiliza una clave secreta compartida para generar una serie de contraseñas OTP únicas. La generación del token se hace al aplicar un algoritmo HMAC (Hash Message Authentication Code) a la clave secreta compartida junto con un contador sincronizado que mantienen el servidor y el cliente, garantizando que garantiza que cada contraseña OTP sea única y no se pueda reutilizar.
SMS One-Time Password:
Envía una contraseña OTP al número de teléfono del usuario a través de un mensaje de texto. El usuario puede entonces ingresar la contraseña OTP en la aplicación de autenticación de dos factores. Este mecanismo es fácil de implementar, pero es menos seguro que los mecanismos basados en token ya que la contraseña OTP puede ser interceptada por un atacante.
Mobile Push Notification
Envía una notificación push al dispositivo móvil del usuario para solicitar la autenticación. El usuario puede entonces aprobar o denegar la solicitud de autenticación desde su dispositivo móvil. Para el funcionamiento de la notificación push es necesario que el la aplicación tenga habilitadas las notificaciones. Este mecanismo es más seguro que el envio de claves vía SMS, ya que no requiere que el usuario ingrese una contraseña OTP.
Time-based One-Time Password (TOTP)
Genera una contraseña OTP única basada en el tiempo actual. El servidor y el cliente deben mantener el mismo reloj sincronizado para garantizar que la contraseña OTP generada sea válida. Este mecanismo es ampliamente utilizado en aplicaciones de autenticación de dos factores que requieren una contraseña OTP basada en el tiempo.
Componentes identificados
Activation service
Orquesta la activación del token para su registro y activación
Token service
Encapsula toda la funcionalidad del token
HSM Adapter
Encapsula acceso a servicio de HSM de AWS
Access service
Sincroniza la transferencia de mensajes entre el backend y el usuario
Enrollment API
Expone el API para permitir la generación de tokens
Flujo Propuesto
...
Procesos necesarios para implementación de OTP
...
Proceso
...
Descripción
...
Servicios implicados
...
Puntos de acceso
...
Registro de usuario
...
El registro de usuario corresponde al proceso actual de registro de información del usuario en la base de datos de SPIN
...
Servicios existentes de SPIN
...
...
Solicitud de vinculación del dispositivo
...
Con base en la información del usuario se genera un código de activación que es enviado al dispositivo seleccionado. Para el envío del código se podrían considerar varios medios: Código QR, E-mail, SMTP, o Notificación Push
...
Activation service (Nuevo)
...
getActivationCode
...
Access Service (Revisar)
...
...
Autenticación de usuario
...
Se verifica que el usuario sea el dueño del dispositivo a vincular al ingresar el código de activación recibido previamente, si coinciden, se genera la semilla para la generación de OTP, y se envía al dispositivo (Revisar mecanismo)
...
Activation service
...
GenerateOTP
...
Token service
...
createFactor
...
Access service
...
send
...
Vinculación de dipostivo
...
El dispositivo recibe la semilla y después de ser verificada se asocia al teléfono (considerar IMEI)
...
Activation service
...
BindDevice
...
Access service
...
validate
...
Token service
...
validate
...
Ejecución de transacción
...
El cliente envía a información de la transacción al servidor, el servidor coordina con el cliente el factor de autenticación y el cliente envía el nuevo factor. Si el factor es válido se ejecuta la transacción.
...
Activation service
...
getEntityFactor
validateOTP
...
Token service
...
createChallenge
validateChallenge
...
Access service
...
send
Aspectos a considerar
...
Toda la comunicación entre los dispositivos debe estar adecuadamente cifrada. (Revisar especificaciones regulatorias)
...
No se deben almacenar datos en medios sensibles de estar expuestos a menos que se encuentren cifrados. Se usará HSM en AWS.
...
Si es necesario almacenar u obtener datos del dispositivo móvil, se procurará dar lineamientos para que no puedan ser falseados o interceptados.
...
A continuación, los diagramas de arquitectura que representan visualmente las relaciones e interacciones que existen entre los componentes del proyecto de Token Digital:
Diagramas:
| Table of Contents |
|---|
Diagrama de infraestructura
...
C4 - Level 1
El token digital se generará desde Spin, permitiendo los usuarios su generación y uso, y a los usuarios de call center a funcionalidades utilitarias de activación o desactivación. Para permitir el enrolamiento se requiere autenticación por un segundo factor, para lo cual se envía un OTP utilizando la infraestructura de AWS para su transmisión desde Spin.
...
C4 - Level 2
Adicional a la aplicación móvil, el acceso a los servicios de Spin se podría dar desde una PWA, donde el dispositivo se utilizaría para la generación y validación del token digital
...
C4 - Level 3
Token Digital
...
Diagrama - ffss-token-aggregation-service
...
Diagrama - ffss-token-activation-service
...
Diagrama - ffss-token-service
...
Diagrama - ffss-hsm-adapter-service
...