Política de Seguridad de Sesión

Última actualización: May 22, 2026

POLÍTICA DE SEGURIDAD DE SESIONES DE DATACRED

Versión del Documento: 1.0

Fecha de Entrada en Vigor: 22 de mayo de 2026

Clasificación: INTERNO - CONFIDENCIAL / SECCIONES PÚBLICAS SEGÚN SE INDICA

Ciclo de Revisión: Semestral

Propietario: Director de Seguridad de la Información (CISO)

1. [PROPÓSITO Y ALCANCE](#1-purpose-and-scope)

2. [MARCO DE GESTIÓN DE SESIONES](#2-session-management-framework)

3. [MECANISMOS DE AUTENTICACIÓN](#3-authentication-mechanisms)

4. [CREACIÓN DE SESIONES](#4-session-creation)

5. [MANTENIMIENTO DE SESIONES](#5-session-maintenance)

6. [TERMINACIÓN DE SESIONES](#6-session-termination)

7. [MONITOREO DE SEGURIDAD DE SESIONES](#7-session-security-monitoring)

8. [MARCO DE CONFIANZA DEL DISPOSITIVO](#8-device-trust-framework)

9. [AUTENTICACIÓN CONTINUA](#9-continuous-authentication)

10. [REGISTRO DE AUDITORÍA DE SESIONES](#10-session-audit-trail)

11. [SEGURIDAD DE SESIONES DE API](#11-api-session-security)

12. [SEGURIDAD DE SESIONES MÓVILES](#12-mobile-session-security)

13. [DESCARGOS DE RESPONSABILIDAD Y LIMITACIONES](#13-disclaimers-and-limitations)

14. [OBLIGACIONES DEL USUARIO](#14-user-obligations)

15. [MANTENIMIENTO Y MODIFICACIÓN DE LA POLÍTICA](#15-policy-maintenance-and-modification)

16. [INFORMACIÓN DE CONTACTO](#16-contact-information)

DataCred ("DataCred," "nosotros," "nos," "nuestro") es una plataforma venezolana de puntuación de reputación financiera conductual nativa de IA que opera bajo una estructura legal de Wyoming, Estados Unidos. DataCred NO es un banco, prestamista, institución financiera regulada ni empresa de servicios monetarios.

DataCred es una plataforma privada e independiente de información y reputación financiera. No es el buró ni el registro oficial del Estado, no está autorizada, certificada ni respaldada por la Superintendencia de las Instituciones del Sector Bancario (SUDEBAN), el Banco Central de Venezuela (BCV), el Sistema de Información Central de Riesgos (SICRI) ni ningún otro organismo del gobierno, y no está conectada a ellos. Los puntajes y la información que DataCred ofrece son estimaciones para apoyar decisiones; no constituyen decisiones oficiales ni garantías.

Esta Política de Seguridad de Sesiones (la "Política") establece el marco integral que rige la gestión de sesiones durante todo el ciclo de vida de autenticación en la plataforma de DataCred.

El propósito de esta Política es:

1.1.1 Definir el marco de gestión de sesiones, incluyendo autenticación, creación de sesiones, mantenimiento de sesiones y terminación de sesiones;

1.1.2 Establecer requisitos de seguridad para todos los mecanismos de autenticación compatibles con DataCred;

1.1.3 Definir los requisitos de generación, almacenamiento y validación de tokens de sesión;

1.1.4 Establecer políticas de tiempo de espera de sesión, mecanismos de actualización de tokens y gestión de sesiones en múltiples dispositivos;

1.1.5 Definir procedimientos de monitoreo de sesiones, detección de anomalías y respuesta a amenazas;

1.1.6 Establecer los marcos de confianza del dispositivo y autenticación continua;

1.1.7 Definir requisitos de seguridad de sesiones de API;

1.1.8 Comunicar las limitaciones de las medidas de seguridad de sesiones y las obligaciones del usuario;

1.1.9 Proporcionar transparencia con respecto a las prácticas de seguridad de sesiones de DataCred a usuarios, socios y partes interesadas.

Esta Política se aplica a:

1.2.1 Todos los Usuarios: Todas las personas y entidades que acceden a las plataformas, aplicaciones, API o servicios de DataCred, incluyendo, entre otros, usuarios finales, usuarios organizacionales, administradores, consumidores de API e integradores terceros.

1.2.2 Todos los Métodos de Acceso: Todos los métodos de acceso a los sistemas de DataCred, incluyendo navegadores web, aplicaciones móviles (iOS y Android), clientes de API, interfaces de línea de comandos (CLI) e integraciones de terceros.

1.2.3 Todos los Tipos de Autenticación: Todos los mecanismos de autenticación compatibles con DataCred, incluyendo autenticación basada en contraseña, autenticación multifactor, autenticación biométrica, inicio de sesión OAuth/redes sociales y autenticación mediante clave de API.

1.2.4 Todos los Tipos de Sesión: Todos los tipos de sesión, incluyendo sesiones web (basadas en cookies), sesiones móviles (basadas en tokens), sesiones de API (basadas en tokens) y sesiones de servicio a servicio.

1.2.5 Todos los Entornos: Todos los entornos de DataCred, incluyendo producción, pruebas, desarrollo y sandbox, a menos que se exceptúen expresamente.

ESTA POLÍTICA NO ES UN CONTRATO Y NO CREA NINGÚN DERECHO U OBLIGACIÓN CONTRACTUAL. DATACRED PUEDE MODIFICAR ESTA POLÍTICA EN CUALQUIER MOMENTO SIN AVISO, SUJETO A LAS DISPOSICIONES DE LA SECCIÓN 15.

DataCred gestiona las sesiones a través de un ciclo de vida definido que consta de cuatro fases:

Fase 1 - Autenticación:

El proceso mediante el cual un usuario demuestra su identidad al sistema a través de uno o más mecanismos de autenticación.

Fase 2 - Creación de la Sesión:

La generación y emisión de un token de sesión tras la autenticación exitosa, estableciendo una sesión autenticada.

Fase 3 - Mantenimiento de la Sesión:

La gestión continua de la sesión autenticada, incluyendo validación de tokens, actualización, aplicación de tiempos de espera y monitoreo de anomalías.

Fase 4 - Terminación de la Sesión:

La finalización segura de una sesión autenticada, ya sea por acción explícita del usuario, tiempo de espera automático, terminación forzada u otros eventos.

DataCred admite los siguientes tipos de sesión:

#### 2.2.1 Sesiones Web

Sesiones de navegador web establecidas a través de tokens de autenticación basados en cookies. Las sesiones web se gestionan mediante:

  • Cookies de Sesión: Cookies de corta duración almacenadas en la memoria del navegador (no persistentes);
  • Cookies Persistentes: Cookies de mayor duración para la funcionalidad "recordarme", cifradas y con alcance restringido;
  • Tokens de Almacenamiento Local: Tokens de actualización cifrados almacenados en el almacenamiento local del navegador cuando corresponda.

#### 2.2.2 Sesiones Móviles

Sesiones de aplicaciones móviles establecidas mediante autenticación basada en tokens. Las sesiones móviles se gestionan mediante:

  • Tokens de Acceso: Tokens de corta duración (minutos a horas) almacenados en la memoria de la aplicación o almacenamiento seguro;
  • Tokens de Actualización: Tokens de mayor duración (días a meses) almacenados en el Llavero de iOS o el Almacén de Claves de Android;
  • Tokens de Registro de Dispositivo: Tokens persistentes que vinculan el dispositivo a la cuenta de usuario.

#### 2.2.3 Sesiones de API

Sesiones de cliente de API establecidas mediante claves de API, JWT o tokens OAuth2. Las sesiones de API se gestionan mediante:

  • Claves de API: Claves de larga duración utilizadas para comunicación servidor a servidor;
  • JWT: JSON Web Tokens firmados con vencimiento definido;
  • Tokens OAuth2: Tokens de acceso y tokens de actualización emitidos a través de flujos OAuth2.

#### 2.2.4 Sesiones de Servicio a Servicio

Sesiones de autenticación servidor a servidor establecidas entre servicios de back-end. Las sesiones de servicio a servicio se gestionan mediante:

  • mTLS: Autenticación TLS mutua con certificados de cliente;
  • Tokens de Cuenta de Servicio: Tokens firmados o JWT para identidad de servicio;
  • IAM en la Nube: Gestión de identidad y acceso del proveedor de nube para comunicación interna de servicios.

#### 3.1.1 Requisitos de Contraseña

Todas las contraseñas utilizadas para autenticarse en los sistemas de DataCred deben cumplir con los siguientes requisitos:

  • Longitud Mínima: 12 caracteres;
  • Sin Longitud Máxima: Las contraseñas pueden tener cualquier longitud; se aceptan contraseñas muy largas;
  • Complejidad: Deben incluir al menos tres de las siguientes categorías de caracteres:
  • Letras mayúsculas latinas (A-Z);
  • Letras minúsculas latinas (a-z);
  • Dígitos numéricos (0-9);
  • Caracteres especiales (por ejemplo, !@#$%^&*()-_=+[]{}|;:,.<>?/~`).
  • Contraseñas Prohibidas:
  • Contraseñas comunes (según lo determinado por la lista negra de contraseñas de DataCred, que incluye contraseñas comprometidas conocidas, patrones comunes y contraseñas específicas del contexto);
  • Contraseñas que han sido expuestas en violaciones de datos conocidas (verificadas contra bases de datos de violaciones como Have I Been Pwned);
  • Contraseñas que contienen el nombre del usuario, nombre de usuario, dirección de correo electrónico o nombre de la organización;
  • Caracteres secuenciales (por ejemplo, "abcdefg", "12345678");
  • Caracteres repetidos (por ejemplo, "aaaaaa", "111111");
  • Patrones de teclado (por ejemplo, "qwerty", "asdfgh");
  • Contraseñas específicas del contexto (por ejemplo, "DataCred123", "password").

#### 3.1.2 Almacenamiento de Contraseñas

Todas las contraseñas se almacenan utilizando algoritmos hash estándar de la industria:

  • Algoritmo Hash: bcrypt con un factor de costo de 12 o superior (o un algoritmo hash adaptativo equivalente);
  • Salado: Cada contraseña se somete a hash con un salt criptográficamente aleatorio único;
  • Pepper: Se utiliza un secreto adicional a nivel de sitio (pepper) además del salt por contraseña;
  • Prohibición de Texto Plano: Las contraseñas NUNCA se almacenan en texto plano, cifradas (reversibles) ni en ninguna forma a partir de la cual puedan recuperarse;
  • Transmisión: Las contraseñas se transmiten únicamente a través de conexiones cifradas TLS 1.3.

#### 3.1.3 Cambio de Contraseña

  • Los usuarios pueden cambiar su contraseña en cualquier momento a través de la configuración de la cuenta autenticada;
  • Los cambios de contraseña requieren la contraseña actual del usuario para verificación;
  • Los cambios de contraseña requieren reverificación de MFA cuando esté habilitada;
  • El historial de contraseñas impide la reutilización de las últimas 10 contraseñas;
  • El cambio de contraseña invalida todas las sesiones existentes excepto la sesión actual (con todas las demás sesiones terminadas).

#### 3.1.4 Restablecimiento de Contraseña

  • Las solicitudes de restablecimiento de contraseña requieren la propiedad verificada de la dirección de correo electrónico asociada;
  • Los enlaces de restablecimiento de contraseña tienen límite de tiempo (15 minutos);
  • Los enlaces de restablecimiento de contraseña son de un solo uso;
  • El restablecimiento de contraseña genera una notificación a la dirección de correo electrónico verificada del usuario;
  • El restablecimiento de contraseña termina todas las sesiones activas, requiriendo reautenticación.

3.2 Autenticación Multifactor (MFA)

#### 3.2.1 Requisitos de MFA

Se requiere MFA para todas las cuentas de DataCred:

  • Todos los Usuarios: Se requiere MFA para todas las cuentas de usuario;
  • Todos los Administradores: Se requiere MFA para todas las cuentas administrativas y privilegiadas;
  • Todas las Operaciones Sensibles: Se requiere MFA para operaciones sensibles independientemente del método de autenticación principal.

#### 3.2.2 Métodos de MFA Admitidos

3.2.2.1 TOTP (Contraseña de Un Solo Uso Basada en Tiempo)

  • Estándares: RFC 6238 (TOTP), RFC 4226 (HOTP);
  • Validez del Token: 30 segundos;
  • Longitud de Clave: 160 bits mínimo;
  • Recuperación: Códigos de recuperación proporcionados en el registro;
  • Almacenamiento de Semilla: Cifrada en reposo en la base de datos; nunca transmitida después del registro inicial.

3.2.2.2 Códigos de Respaldo por SMS / Autenticación Basada en SMS

  • Disponibilidad: La autenticación basada en SMS está disponible como método de RESPALDO únicamente;
  • Limitaciones:
  • SMS no está disponible como método de MFA principal;
  • SMS está destinado únicamente para escenarios de recuperación de cuenta;
  • Se aplican límites de uso (máximo 5 códigos SMS por período móvil de 24 horas);
  • SMS está sujeto a la disponibilidad de la red de telecomunicaciones y limitaciones de seguridad.
  • ADVERTENCIA: LA AUTENTICACIÓN BASADA EN SMS ESTÁ SUJETA A ATAQUES DE SIM SWAP, VULNERABILIDADES DEL PROTOCOLO SS7 Y OTROS ATAQUES A NIVEL DE TELECOMUNICACIONES. SE RECOMIENDA ENCARECIDAMENTE A LOS USUARIOS QUE UTILICEN TOTP O LLAVES DE SEGURIDAD DE HARDWARE EN LUGAR DE SMS.

3.2.2.3 Llaves de Seguridad de Hardware (WebAuthn/FIDO2/FIDO U2F)

  • Estándares: WebAuthn (W3C), FIDO2, FIDO U2F;
  • Tipos de Llave Admitidos: Llaves de seguridad USB, NFC y Bluetooth Low Energy (BLE);
  • Registro: Las llaves se registran por usuario por dispositivo;
  • Autenticación: Se requiere verificación de presencia del usuario (toque) para cada autenticación;
  • Verificación del Usuario: Se puede requerir PIN o verificación biométrica para mayor seguridad;
  • Resistencia al Phishing: Las llaves de seguridad de hardware proporcionan autenticación resistente al phishing;
  • Soporte: WebAuthn es compatible con todos los navegadores y plataformas modernos;
  • Gestión: Los usuarios pueden registrar múltiples llaves y eliminar llaves perdidas o comprometidas.

3.2.2.4 Códigos de Recuperación

  • Generación: Los códigos de recuperación se generan en el registro de MFA;
  • Cantidad: 10 códigos de recuperación (de un solo uso);
  • Almacenamiento: Se instruye a los usuarios para que almacenen los códigos de recuperación en una ubicación segura fuera de línea;
  • Regeneración: Los códigos de recuperación pueden regenerarse desde la configuración de la cuenta;
  • Uso: Los códigos de recuperación omiten MFA para una única sesión de autenticación;
  • Caducidad: Los códigos de recuperación se invalidan cuando se generan nuevos códigos;
  • Limitaciones: Los códigos de recuperación pueden estar sujetos a límites de uso y caducidad.

#### 3.2.3 Aplicación de MFA

  • Registro: El registro de MFA se aplica antes del acceso inicial al sistema;
  • Omisión: No se permite la omisión de MFA para el acceso rutinario;
  • Período de Gracia: Se puede proporcionar un período de gracia limitado para que los nuevos usuarios registren MFA, pero con funcionalidad restringida;
  • Excepciones: Las excepciones de MFA requieren la aprobación documentada del CISO y se revisan trimestralmente.

#### 3.2.4 Recuperación de MFA

  • Dispositivo MFA Perdido: La recuperación de la cuenta requiere verificación de identidad a través de canales alternativos;
  • Tiempo de Recuperación: La recuperación puede tardar hasta 5 días hábiles para la verificación de seguridad;
  • Invalidación de Sesión: Tras la recuperación exitosa, todas las sesiones activas se terminan.

#### 3.3.1 Métodos Biométricos Admitidos

DataCred admite los siguientes métodos de autenticación biométrica:

  • Biometría de Plataforma (WebAuthn): Autenticadores de plataforma como Windows Hello, macOS Touch ID y reconocimiento facial/de huellas dactilares a nivel de plataforma;
  • Biometría Móvil: iOS Face ID, iOS Touch ID, huella dactilar de Android, desbloqueo facial de Android;
  • Vinculado al Dispositivo: La autenticación biométrica está vinculada al dispositivo y no transmite datos biométricos a los servidores de DataCred.

#### 3.3.2 Limitaciones Biométricas

  • Dependiente de la Plataforma: La autenticación biométrica solo está disponible en dispositivos y plataformas que la admitan;
  • Procesamiento Local: La verificación biométrica se realiza localmente en el dispositivo del usuario; los datos biométricos NO se transmiten ni almacenan por DataCred;
  • Alternativa: La autenticación biométrica siempre requiere una contraseña o PIN como alternativa;
  • Sin Base de Datos Biométrica: DataCred no mantiene una base de datos de plantillas biométricas;
  • Registro del Dispositivo: La autenticación biométrica requiere el registro previo del dispositivo.

#### 3.4.1 Proveedores Admitidos

DataCred puede admitir la autenticación a través de proveedores OAuth de terceros (inicio de sesión con redes sociales). Los proveedores admitidos se enumeran en la documentación de la plataforma y pueden cambiar con el tiempo.

#### 3.4.2 Consideraciones de Seguridad

  • Limitación de Alcance: El acceso al proveedor OAuth se limita al alcance mínimo necesario (típicamente solo información de correo electrónico y perfil);
  • Vinculación de Cuentas: Las cuentas OAuth se vinculan a cuentas existentes de DataCred; el inicio de sesión OAuth no crea una cuenta separada de DataCred;
  • Consideración de MFA: Los usuarios que se autentican a través de OAuth aún deben tener MFA habilitado en su cuenta de DataCred para operaciones sensibles;
  • Seguridad del Proveedor: DataCred confía en la seguridad de la autenticación del proveedor OAuth; los usuarios deben asegurarse de que su cuenta del proveedor OAuth tenga medidas de seguridad apropiadas (MFA, contraseña segura);
  • Descontinuación del Proveedor OAuth: Si un proveedor OAuth se descontinúa o DataCred elimina el soporte, los usuarios deberán configurar un método de autenticación alternativo.

#### 3.4.3 Flujo OAuth

  • Protocolo: Flujo de Código de Autorización OAuth 2.0 con PKCE (Proof Key for Code Exchange);
  • Parámetro de Estado: Se utiliza un parámetro de estado criptográficamente aleatorio para prevenir ataques CSRF;
  • Validación de URI de Redirección: Las URI de redirección se validan estrictamente contra una lista blanca registrada;
  • Intercambio de Tokens: Los códigos de autorización se intercambian por tokens solo en el lado del servidor (nunca expuestos al navegador).

La autenticación de API se cubre en detalle en la Sección 11 (Seguridad de Sesiones de API).

Tras la autenticación exitosa, DataCred genera tokens de sesión utilizando métodos criptográficamente seguros:

  • Fuente de Aleatoriedad: Generador de números pseudoaleatorios criptográficamente seguro (CSPRNG);
  • Entropía: Los tokens de sesión contienen un mínimo de 128 bits de entropía;
  • Unicidad: Los tokens de sesión se generan con garantías de unicidad (resistentes a colisiones);
  • No Predecibilidad: Los tokens de sesión no son predecibles basándose en ningún conocimiento previo (tiempo, ID de usuario, número de secuencia).

Los tokens de sesión se almacenan de forma segura según el tipo de sesión:

#### 4.2.1 Almacenamiento de Tokens de Sesión Web

  • Almacenamiento Principal: Cookies HttpOnly, Secure, SameSite;
  • Bandera HttpOnly: JavaScript no puede acceder a la cookie, evitando el robo de tokens basado en XSS;
  • Bandera Secure: La cookie solo se transmite a través de conexiones HTTPS;
  • Atributo SameSite: SameSite=Strict (o SameSite=Lax cuando sea estrictamente necesario para la experiencia del usuario);
  • Prefijo de Cookie: Se utiliza el prefijo __Host- cuando es compatible;
  • Restricción de Ruta: La cookie se limita a la ruta más estrecha necesaria;
  • Restricción de Dominio: La cookie se limita al dominio más estrecho necesario;
  • Cifrado: Los valores de las cookies se cifran cuando se almacena información sensible;
  • Prohibición de Almacenamiento Local: Los tokens de sesión NO se almacenan en localStorage ni sessionStorage.

#### 4.2.2 Almacenamiento de Tokens de Sesión Móvil

  • iOS: Los tokens se almacenan en el Llavero de iOS con controles de acceso apropiados (kSecAttrAccessibleWhenUnlockedThisDeviceOnly);
  • Android: Los tokens se almacenan en el sistema Almacén de Claves de Android con almacén de claves respaldado por hardware cuando esté disponible;
  • Cifrado: Los tokens se cifran en reposo en el almacenamiento seguro del dispositivo;
  • Aislamiento de Procesos: Los tokens son accesibles solo para la aplicación de DataCred (no para otras aplicaciones);
  • Exención de Copia de Seguridad: Los tokens se excluyen de las copias de seguridad del dispositivo cuando sea factible.

#### 4.2.3 Almacenamiento de Tokens de Cliente de API

  • Claves de API: Almacenadas de forma segura por el consumidor de la API; DataCred recomienda variables de entorno, servicios de gestión de secretos o bóvedas seguras;
  • JWT: Almacenados por la aplicación cliente; DataCred recomienda almacenamiento cifrado o memoria segura;
  • Tokens OAuth2: Almacenados de forma segura por el cliente; DataCred recomienda utilizar el mecanismo de almacenamiento seguro apropiado para la plataforma del cliente.

Cuando DataCred utiliza JSON Web Tokens (JWT), se aplican las siguientes especificaciones:

  • Algoritmo: RS256 (Firma RSA con SHA-256) o ES256 (ECDSA con P-256 y SHA-256). Los algoritmos HMAC (HS256, HS384, HS512) NO se utilizan para tokens de acceso;
  • Emisor: La declaración "iss" (emisor) contiene un identificador único de DataCred como el emisor del token;
  • Sujeto: La declaración "sub" (sujeto) contiene un identificador de usuario único y no reasignable;
  • Audiencia: La declaración "aud" (audiencia) contiene el destinatario previsto del token;
  • Caducidad: La declaración "exp" (caducidad) se establece en un valor razonable (típicamente 15-60 minutos para tokens de acceso);
  • No Antes de: La declaración "nbf" (no antes de) puede utilizarse para prevenir el uso del token antes de un momento específico;
  • Emitido en: La declaración "iat" (emitido en) registra el momento de emisión del token;
  • ID de JWT: La declaración "jti" (ID de JWT) proporciona un identificador único para el token, permitiendo comprobaciones de revocación;
  • Gestión de Claves de Firma: Las claves de firma se gestionan a través de HSM/KMS con rotación periódica;
  • Rotación de Claves: Las claves de firma se rotan al menos trimestralmente;
  • Distribución de Clave Pública: Las claves públicas se distribuyen a través de endpoints JWKS bien conocidos (https://datacred.org/.well-known/jwks.json);
  • Validación de Algoritmo: El algoritmo en la cabecera JWT se valida estrictamente contra una lista blanca; los ataques de confusión de algoritmo se previenen validando explícitamente el algoritmo.

Las sesiones se vinculan a atributos específicos para prevenir el secuestro:

  • Vinculación IP: Los tokens de sesión pueden estar vinculados a la dirección IP de origen (con tolerancia para cambios de IP);
  • Vinculación de Huella Digital del Dispositivo: Las sesiones se vinculan a una huella digital del dispositivo derivada de las características del navegador/dispositivo;
  • Vinculación de User-Agent: Las sesiones se vinculan a la cadena User-Agent cuando corresponda;
  • Vinculación de Geolocalización: Las sesiones pueden estar vinculadas a la región geográfica.

Los atributos de vinculación de sesión se validan en cada solicitud. Los cambios significativos en los atributos de vinculación desencadenan verificación de autenticación adicional o terminación de la sesión.

DataCred aplica las siguientes políticas de tiempo de espera de sesión:

#### 5.1.1 Tiempo de Espera Absoluto

Las sesiones tienen una vida útil máxima independientemente de la actividad:

  • Sesiones Web: Máximo 24 horas desde la creación de la sesión;
  • Sesiones Móviles: Máximo 30 días desde la creación de la sesión (requiriendo reautenticación);
  • Sesiones de API: Máximo 60 minutos para tokens de acceso (los tokens de actualización tienen un tiempo de espera separado);
  • Sesiones de Administrador: Máximo 4 horas desde la creación de la sesión;
  • Sesiones de Servicio a Servicio: Máximo 60 minutos.

#### 5.1.2 Tiempo de Espera por Inactividad

Las sesiones caducan automáticamente después de un período de inactividad:

  • Sesiones Web: 30 minutos de inactividad;
  • Sesiones Móviles: 24 horas de inactividad (con un tiempo de espera más corto antes de requerir autenticación local del dispositivo);
  • Sesiones de Administrador: 15 minutos de inactividad;
  • Sesiones de API: N/A (modelo de tiempo de espera separado).

#### 5.1.3 Caducidad Renovable

La caducidad de la sesión puede extenderse con la actividad:

  • Sesiones Web: La caducidad de la sesión se renueva con la actividad, hasta el límite de tiempo de espera absoluto;
  • Sesiones Móviles: La caducidad de la sesión se renueva con la actividad, hasta el límite de tiempo de espera absoluto;
  • Sesiones de API: Sin caducidad renovable; los tokens de acceso caducan después de la duración especificada.

#### 5.2.1 Rotación de Tokens de Actualización

DataCred implementa la rotación de tokens de actualización:

  • Estructura del Token de Actualización: Los tokens de actualización son cadenas opacas, criptográficamente aleatorias (entropía mínima de 128 bits);
  • Almacenamiento: Los tokens de actualización se almacenan con hash (bcrypt o equivalente) en la base de datos;
  • Rotación: Cada vez que se utiliza un token de actualización para obtener un nuevo token de acceso, el token de actualización se rota (el token antiguo se invalida, se emite un nuevo token);
  • Rotación Automática: La rotación del token de actualización ocurre de manera transparente para el usuario;
  • Revocación: Los tokens de actualización pueden ser revocados individualmente por el usuario (a través de la gestión de sesiones) o automáticamente por DataCred.

#### 5.2.2 Detección de Reutilización de Token de Actualización

DataCred implementa la detección de reutilización de tokens de actualización:

  • Si se presenta un token de actualización revocado o ya utilizado, DataCred:
  • Rechaza la solicitud de actualización de token;
  • Invalida la familia de tokens (todos los tokens derivados del mismo token inicial);
  • Termina todas las sesiones asociadas con el usuario afectado;
  • Requiere reautenticación completa;
  • Registra el evento como un posible robo de token;
  • Notifica al usuario del evento de seguridad;
  • Este mecanismo mitiga el impacto del robo de tokens de actualización mediante la detección de reutilización de tokens.

#### 5.2.3 Vida Útil del Token de Actualización

  • Sesiones Web: Tokens de actualización válidos por 24 horas (coincidiendo con el tiempo de espera absoluto);
  • Sesiones Móviles: Tokens de actualización válidos por 30 días;
  • API (basada en usuario): Tokens de actualización válidos por 7-30 días dependiendo de los requisitos de la aplicación;
  • Sesiones de Administrador: Tokens de actualización válidos por 4 horas;
  • Después de la Caducidad: Se requiere reautenticación completa.

Los usuarios pueden gestionar múltiples sesiones de dispositivo simultáneamente:

  • Visibilidad de la Sesión: Los usuarios pueden ver todas las sesiones activas desde su configuración de cuenta, incluyendo:
  • Tipo y nombre del dispositivo;
  • Sistema operativo;
  • Navegador/aplicación;
  • Dirección IP (enmascarada);
  • Ubicación geográfica aproximada;
  • Marca de tiempo de la última actividad;
  • Marca de tiempo de creación de la sesión;
  • Revocación de Sesión: Los usuarios pueden revocar sesiones individuales o todas las sesiones desde su configuración de cuenta;
  • Límites de Sesión: Máximo 20 sesiones concurrentes por usuario (configurable para cuentas organizacionales);
  • Detección de Nuevo Dispositivo: Cuando se crea una sesión desde un nuevo dispositivo, se notifica al usuario por correo electrónico con los detalles del dispositivo.

Durante el mantenimiento de la sesión, DataCred monitorea las siguientes anomalías:

  • Cambio de Dirección IP: Cambio significativo con respecto a la dirección IP asociada con la creación de la sesión;
  • Cambio Geográfico: Viaje imposible (inicio de sesión desde una ubicación seguido rápidamente de actividad desde una ubicación distante);
  • Cambio de Huella Digital del Dispositivo: Cambio en la huella digital del dispositivo durante una sesión activa;
  • Cambio de User-Agent: Cambio en el User-Agent durante una sesión activa;
  • Anomalía Conductual: Cambio en los patrones de uso típicos (hora del día, frecuencia de acceso, tipos de operaciones).

Cuando se detectan anomalías, DataCred puede:

  • Requerir autenticación adicional (reverificación MFA);
  • Terminar la sesión anómala;
  • Notificar al usuario sobre la actividad anómala;
  • Marcar la cuenta para revisión.

Los usuarios pueden terminar explícitamente su sesión:

#### 6.1.1 Cierre de Sesión Individual

  • La sesión activa se termina;
  • El token de sesión se invalida (en el lado del servidor);
  • Los tokens del lado del cliente se eliminan (cookies, almacenamiento local, llavero);
  • El usuario es redirigido a la página de inicio de sesión.

#### 6.1.2 Cierre de Todas las Sesiones

  • Todas las sesiones activas del usuario se terminan;
  • Todos los tokens de sesión se invalidan;
  • Todos los tokens de actualización se invalidan;
  • El usuario es redirigido a la página de inicio de sesión.

Las sesiones se terminan automáticamente en las siguientes circunstancias:

  • Tiempo de Espera Absoluto: La sesión excede la vida útil máxima (véase la Sección 5.1.1);
  • Tiempo de Espera por Inactividad: La sesión excede el tiempo máximo de inactividad (véase la Sección 5.1.2);
  • Cambio de Contraseña: Todas las sesiones excepto la sesión actual se terminan;
  • Restablecimiento de Contraseña: Todas las sesiones se terminan;
  • Cambio de MFA: Todas las sesiones se terminan;
  • Cambio de Correo Electrónico: Todas las sesiones se terminan;
  • Terminación de Cuenta: Todas las sesiones se terminan;
  • Actividad Sospechosa: Las sesiones pueden terminarse automáticamente cuando se detecta actividad sospechosa (véase la Sección 7).

DataCred se reserva el derecho de terminar forzosamente cualquier sesión en cualquier momento, sin aviso, por cualquier motivo, incluyendo, entre otros:

  • Preocupación de Seguridad: Sospecha de compromiso de la cuenta o sesión;
  • Violación de la Política: Violación de los Términos de Servicio, Política de Uso Aceptable u otras políticas aplicables de DataCred;
  • Requisito Legal: Cumplimiento de la ley aplicable o proceso legal;
  • Terminación del Servicio: Terminación o suspensión de la cuenta del usuario;
  • Mantenimiento del Sistema: Las sesiones pueden terminarse durante procedimientos de mantenimiento.

La terminación de la sesión siempre incluye la invalidación en el lado del servidor:

  • El registro de la sesión se marca como terminado en la base de datos;
  • Los tokens asociados (tokens de acceso, tokens de actualización) se invalidan;
  • La revocación de tokens se propaga a las capas de caché y CDN cuando corresponda;
  • Todos los datos relacionados con la sesión se eliminan o anonimizan.

Las sesiones huérfanas y caducadas se limpian periódicamente:

  • Las sesiones caducadas se eliminan de la base de datos de forma continua;
  • Los tokens de actualización caducados se eliminan de la base de datos de forma continua;
  • Los registros de sesión se conservan de acuerdo con las políticas de retención de datos (véase la Sección 10).

DataCred implementa la detección de inicios de sesión fallidos en múltiples capas:

#### 7.1.1 Bloqueo a Nivel de Cuenta

  • Umbral: 10 intentos de inicio de sesión fallidos consecutivos;
  • Duración del Bloqueo: Bloqueo automático de 30 minutos, aumentando exponencialmente con bloqueos subsiguientes;
  • Restablecimiento: El bloqueo se restablece después de la duración del bloqueo o tras un restablecimiento de contraseña exitoso;
  • Notificación: Se notifica al usuario de los intentos de inicio de sesión fallidos por correo electrónico;
  • Desbloqueo por Administrador: Los administradores pueden desbloquear cuentas manualmente.

#### 7.1.2 Retroceso Exponencial

  • Después de cada intento de inicio de sesión fallido, la demora antes de que se acepte el siguiente intento aumenta exponencialmente;
  • Demora inicial: 1 segundo;
  • Demora máxima: 60 segundos;
  • La demora se restablece tras la autenticación exitosa.

#### 7.1.3 CAPTCHA

  • CAPTCHA se activa después de 3 intentos de inicio de sesión fallidos desde la misma dirección IP;
  • Se requiere CAPTCHA para el inicio de sesión desde direcciones IP sospechosas (VPN, proxy, nodos de salida TOR, IP maliciosas conocidas);
  • CAPTCHA puede ser requerido para el inicio de sesión desde dispositivos o ubicaciones no familiares.

#### 7.1.4 Limitación de Velocidad Basada en IP

  • Límite de Inicio de Sesión por IP: Máximo 30 intentos de inicio de sesión por minuto por dirección IP;
  • Bloqueo de Cuenta por IP: Múltiples cuentas bloqueadas desde la misma IP pueden desencadenar bloqueo a nivel de IP;
  • Bloqueo CIDR: Los ataques sostenidos desde rangos de IP pueden resultar en bloqueo a nivel CIDR;
  • Bloqueo Geográfico: Los inicios de sesión desde regiones geográficas de alto riesgo pueden ser bloqueados o requerir verificación adicional.

DataCred emplea mecanismos de detección especializados para ataques de relleno de credenciales:

  • Análisis de Velocidad: Análisis de la velocidad de intentos de inicio de sesión desde IP individuales y fuentes distribuidas;
  • Análisis de Patrones: Detección de patrones de inicio de sesión automatizados (intervalos fijos, nombres de usuario secuenciales, reintento sistemático);
  • Verificación de Credenciales: Las contraseñas enviadas se verifican contra bases de datos de violaciones; las contraseñas comprometidas conocidas son rechazadas;
  • Cuentas Señuelo: Se despliegan cuentas señuelo para detectar ataques de relleno de credenciales;
  • Monitoreo de la Dark Web: DataCred monitorea fuentes de la dark web en busca de filtraciones de credenciales dirigidas a usuarios de DataCred.

DataCred implementa múltiples mecanismos de detección para el secuestro de sesión:

#### 7.3.1 Detección de Cambio de Dirección IP

  • La dirección IP de la sesión se valida en cada solicitud;
  • Los cambios significativos de dirección IP (cambio de geolocalización, cambio de ISP, cambio de ASN) desencadenan verificación adicional;
  • Los cambios de IP que son consistentes con el comportamiento normal del usuario (dispositivo móvil cambiando de WiFi a datos celulares) pueden ser tolerados.

#### 7.3.2 Detección de Cambio de Huella Digital del Dispositivo

  • La huella digital del dispositivo se valida en cada solicitud;
  • Los cambios de huella digital del dispositivo durante una sesión activa desencadenan verificación adicional;
  • Los atributos de huella digital incluyen: user-agent, resolución de pantalla, zona horaria, idioma, fuentes instaladas, complementos del navegador, huella digital de canvas, huella digital de WebGL, huella digital de audio.

#### 7.3.3 Detección de Viaje Imposible

  • DataCred analiza la ubicación geográfica y la marca de tiempo de solicitudes consecutivas;
  • Si la distancia entre solicitudes consecutivas excede el viaje físicamente posible (considerando viajes aéreos y uso de VPN), la sesión se marca;
  • La detección de viaje imposible considera: vuelos directos, uso de VPN/proxy, cambios de zona horaria y precisión de geolocalización IP;
  • Las sesiones marcadas desencadenan: verificación de autenticación adicional, terminación de la sesión y/o notificación al usuario.

#### 7.3.4 Detección de Anomalías Biométricas Conductuales

  • La dinámica de pulsaciones, los patrones de movimiento del ratón y los gestos táctiles pueden analizarse para autenticación continua;
  • La desviación significativa de los patrones conductuales establecidos puede indicar secuestro de sesión;
  • El análisis biométrico conductual se realiza en el lado del servidor cuando sea factible y en el lado del cliente cuando corresponda.

DataCred implementa las siguientes protecciones contra ataques de replay de sesión:

  • Nonce: Cada solicitud puede incluir un nonce criptográficamente aleatorio para prevenir el replay;
  • Marca de Tiempo: Cada solicitud incluye una marca de tiempo; las solicitudes fuera de una ventana de tiempo aceptable (típicamente 5 minutos) son rechazadas;
  • Vinculación de Token: Los tokens de sesión están vinculados a atributos específicos (IP, huella digital del dispositivo, sesión TLS), evitando el uso del token desde diferentes contextos;
  • TLS Mutuo: Para operaciones sensibles, se puede requerir mTLS, vinculando la sesión al certificado de cliente TLS.

DataCred admite un marco de confianza del dispositivo donde los dispositivos pueden designarse como "de confianza" basándose en los siguientes criterios:

  • MFA Exitoso: El dispositivo se ha utilizado con verificación MFA exitosa;
  • Registro del Dispositivo: El dispositivo se ha registrado a través del proceso de registro de confianza del dispositivo;
  • Postura de Seguridad: El dispositivo cumple con los requisitos mínimos de seguridad:
  • El sistema operativo está actualizado con parches de seguridad;
  • El bloqueo de pantalla está habilitado;
  • El cifrado de disco está habilitado;
  • El dispositivo no está jailbroken ni rooteado;
  • No se ha detectado malware conocido (para dispositivos gestionados);
  • La verificación de integridad del dispositivo es exitosa.

Los dispositivos de confianza pueden recibir los siguientes beneficios:

  • Solicitudes de MFA Reducidas: Se requiere MFA con menos frecuencia en dispositivos de confianza;
  • Funcionalidad Mejorada: Los dispositivos de confianza pueden acceder a funciones adicionales;
  • Duración de la Sesión: Se pueden permitir duraciones de sesión más largas en dispositivos de confianza.

A cada dispositivo se le asigna una puntuación de confianza basada en:

  • Antigüedad de la Confianza: Cuánto tiempo ha sido confiable el dispositivo;
  • Verificación Reciente: Tiempo desde la última autenticación exitosa;
  • Seguridad del Dispositivo: Evaluación de la postura de seguridad;
  • Consistencia Conductual: Consistencia con los patrones de uso históricos;
  • Consistencia de Ubicación: Consistencia con las ubicaciones geográficas históricas.

La confianza del dispositivo puede ser revocada en cualquier momento:

  • Incidente de Seguridad: Si el dispositivo está asociado con un incidente de seguridad;
  • Compromiso del Dispositivo: Si se sospecha que el dispositivo está comprometido;
  • Pérdida o Robo: Si el dispositivo se reporta como perdido o robado;
  • Inactividad: Si el dispositivo no se ha utilizado durante un período prolongado;
  • Acción del Usuario: El usuario revoca la confianza de un dispositivo;
  • Acción de DataCred: DataCred revoca la confianza a su sola discreción.

Cuando se implementa, DataCred utiliza biometría conductual para la validación continua de la sesión:

  • Dinámica de Pulsaciones: Análisis de patrones de escritura (duración de presión de tecla, tiempo de vuelo, patrones de error);
  • Dinámica del Ratón: Análisis de patrones de movimiento del ratón (velocidad, aceleración, trayectoria, patrones de clic);
  • Dinámica Táctil: Análisis de gestos táctiles (patrones de deslizamiento, presión, duración de toque);
  • Análisis de Marcha: Para aplicaciones móviles, análisis de patrones de caminata a partir de sensores del dispositivo.

LA BIOMETRÍA CONDUCTUAL SE UTILIZA COMO UNA CAPA DE SEGURIDAD ADICIONAL Y NO ES UNA GARANTÍA DE AUTENTICACIÓN CONTINUA. LA BIOMETRÍA CONDUCTUAL PUEDE NO ESTAR IMPLEMENTADA PARA TODAS LAS PLATAFORMAS O SEGMENTOS DE USUARIOS.

DataCred puede requerir autenticación adicional (reverificación MFA) para operaciones sensibles:

Operaciones Sensibles que Requieren Reautenticación:

  • Cambio de contraseña;
  • Cambio de configuración de MFA;
  • Cambio de dirección de correo electrónico;
  • Cambio de número de teléfono;
  • Añadir o eliminar dispositivos de confianza;
  • Ver o exportar datos RESTRINGIDOS;
  • Transacciones u operaciones de alto valor;
  • Cambios en la configuración de seguridad;
  • Cambios en los métodos de pago;
  • Autorización de nuevas claves de API;
  • Cambios en las opciones de recuperación de cuenta;
  • Cambios en la configuración organizacional.

Factores de Riesgo que Desencadenan Reautenticación:

  • Ubicación geográfica inusual;
  • Dispositivo inusual;
  • Hora de acceso inusual;
  • Patrones de comportamiento anómalos;
  • Operación de alto riesgo (acceso a grandes volúmenes de datos, cambio de privilegios);
  • Evento o alerta de seguridad reciente;
  • Actividad sospechosa detectada en la cuenta.

DataCred puede recopilar y analizar las siguientes señales pasivas para autenticación continua:

  • Geolocalización de dirección IP;
  • Huella digital del dispositivo;
  • Características del navegador;
  • Características de la conexión (tipo de red, intensidad de señal, latencia);
  • Patrones basados en tiempo (hora del día, día de la semana);
  • Patrones de uso de la aplicación (patrones de navegación, uso de funciones);
  • Señales biométricas (cuando estén disponibles y con consentimiento del usuario).

DataCred registra los siguientes eventos de sesión con fines de seguridad y auditoría:

Eventos de Creación de Sesión:

  • Inicio de sesión exitoso (con método de autenticación);
  • Intento de inicio de sesión fallido (con motivo);
  • Verificación MFA (éxito/fallo);
  • Emisión de token de sesión.

Eventos de Mantenimiento de Sesión:

  • Actualización de token de sesión;
  • Actividad de sesión (latido periódico u operaciones significativas);
  • Cambios de atributos de sesión (cambio de IP, cambio de dispositivo);
  • Eventos de detección de anomalías.

Eventos de Terminación de Sesión:

  • Cierre de sesión explícito;
  • Tiempo de espera de sesión (absoluto o por inactividad);
  • Terminación forzada (con motivo);
  • Cambio/restablecimiento de contraseña;
  • Cambios de cuenta (MFA, correo electrónico, terminación).

Los registros de auditoría de sesión incluyen la siguiente información:

  • Marca de Tiempo: Marca de tiempo UTC con precisión de milisegundos;
  • Identificador de Usuario: Identificador de usuario único (ID de usuario, no nombre de usuario ni correo electrónico);
  • Identificador de Sesión: Identificador de sesión único;
  • Tipo de Evento: Tipo de evento de sesión;
  • Dirección IP de Origen: Dirección IP de origen (puede estar enmascarada por privacidad);
  • Huella Digital del Dispositivo: Huella digital del dispositivo (hash, no huella digital bruta);
  • User-Agent: Cadena User-Agent;
  • Geolocalización: Ubicación geográfica aproximada (nivel de ciudad/país);
  • Método de Autenticación: Método utilizado para la autenticación (contraseña, MFA, biométrico, OAuth, clave de API);
  • Factores de Autenticación: Factores utilizados para MFA (TOTP, SMS, WebAuthn, etc.);
  • Atributos de Sesión: Atributos de sesión relevantes (nivel de confianza, estado de confianza del dispositivo);
  • Resultado: Éxito o fallo del evento.

Los usuarios pueden acceder a su propio historial de sesión desde la configuración de su cuenta, incluyendo:

  • Sesiones activas (dispositivo, ubicación, última actividad, creada);
  • Historial de inicio de sesión reciente (últimos 30 días);
  • Intentos de inicio de sesión fallidos (últimos 30 días);
  • Actividad de la cuenta (cambios de contraseña, cambios de MFA, cambios de correo electrónico).

Los registros de auditoría de sesión se conservan según el siguiente calendario:

  • Registros de Sesión Activa: Se conservan mientras la sesión esté activa;
  • Historial de Sesión Reciente: Se conserva durante un mínimo de 12 meses;
  • Registros de Auditoría de Sesión: Se conservan durante un mínimo de 36 meses;
  • Registros de Auditoría de Autenticación: Se conservan durante un mínimo de 36 meses;
  • Registros de Eventos de Anomalía: Se conservan durante un mínimo de 36 meses.

Los registros de auditoría de sesión están protegidos contra manipulaciones:

  • Los registros se almacenan en almacenamiento de solo anexar, de una sola escritura;
  • La integridad de los registros se verifica criptográficamente (cadenas hash o equivalente);
  • El acceso a los registros está restringido al personal de seguridad y auditoría autorizado;
  • Las modificaciones de registros se detectan y alertan;
  • Los registros se cifran en reposo y en tránsito.

#### 11.1.1 Generación de Clave de API

  • Longitud de Clave: Mínimo 128 bits de entropía;
  • Formato: Cadena opaca (que no contiene información identificable);
  • Almacenamiento: Las claves de API se almacenan con hash (bcrypt o equivalente) en la base de datos;
  • Visualización: Las claves de API se muestran una vez en el momento de la creación y deben almacenarse de forma segura por el consumidor de la API.

#### 11.1.2 Permisos de Clave de API

  • Ámbito de la Clave: Las claves de API pueden tener un ámbito limitado a permisos, recursos y operaciones específicos;
  • Restricción IP: Las claves de API pueden restringirse a direcciones IP o rangos CIDR específicos;
  • Límites de Velocidad: Las claves de API están sujetas a límites de velocidad basados en el plan y los permisos de la clave;
  • Caducidad: Las claves de API pueden tener una fecha de caducidad;
  • Revocación: Las claves de API pueden ser revocadas individualmente.

#### 11.1.3 Rotación de Clave de API

  • Rotación Regular: Las claves de API deben rotarse al menos cada 90 días;
  • Rotación de Claves Críticas: Las claves con permisos elevados deben rotarse cada 30 días;
  • Rotación Forzada: DataCred se reserva el derecho de forzar la rotación de claves de API por razones de seguridad;
  • Período de Gracia de Rotación: Se puede proporcionar un período de gracia con ambas claves (antigua y nueva) válidas simultáneamente (típicamente 7 días).

11.2 Autenticación JWT (API)

Cuando se utilizan JWT para la autenticación de API:

  • Vida Útil del Token: Tokens de acceso: máximo 60 minutos;
  • Actualización: Se utilizan tokens de actualización para obtener nuevos tokens de acceso (véase la Sección 5.2);
  • Revocación: Los JWT se validan contra una lista de revocación para aplicaciones críticas;
  • Ámbito: Los JWT contienen declaraciones de ámbito que limitan el acceso a recursos autorizados.

11.3 OAuth2 (API)

Cuando se utiliza OAuth2 para la autenticación de API:

  • Tipos de Concesión: Flujo de Código de Autorización con PKCE (para usuarios), flujo de Credenciales de Cliente (para servicio a servicio);
  • Vida Útil del Token: Tokens de acceso: máximo 60 minutos; Tokens de actualización: 7-30 días;
  • Ámbitos: Los ámbitos de OAuth2 se utilizan para limitar los permisos del token.

Todos los endpoints de API están sujetos a limitación de velocidad:

  • Límite de Velocidad por Clave: Basado en el plan y los permisos de la clave de API;
  • Límite de Velocidad por IP: Límites adicionales basados en la dirección IP de origen;
  • Límites Específicos de Endpoint: Límites más restrictivos en endpoints sensibles o costosos;
  • Cabeceras de Límite de Velocidad: Se devuelven cabeceras estándar de límite de velocidad (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset);
  • Límite de Velocidad Excedido: Se devuelve HTTP 429 Too Many Requests con una cabecera Retry-After.

Las sesiones de API se aplican a través de:

  • Autenticación Requerida: Todas las solicitudes de API deben incluir credenciales de autenticación válidas en la cabecera Authorization;
  • Validación de Token: Todos los tokens de API se validan en cada solicitud (firma, caducidad, estado de revocación);
  • Aplicación de Ámbito: El acceso a la API se limita a los permisos otorgados al token;
  • Registro de Auditoría: Todas las solicitudes de API se registran con atribución al usuario.

Los tokens de sesión móviles se almacenan de forma segura:

  • iOS: Tokens almacenados en el Llavero de iOS con kSecAttrAccessibleWhenUnlockedThisDeviceOnly;
  • Android: Tokens almacenados en EncryptedSharedPreferences o Almacén de Claves de Android, con almacenamiento respaldado por hardware cuando esté disponible;
  • Cifrado: Los tokens se cifran en reposo;
  • Exclusión de Copia de Seguridad: Los tokens se excluyen de las copias de seguridad del dispositivo cuando sea técnicamente factible.

Las aplicaciones móviles admiten la autenticación biométrica:

  • iOS: Face ID y Touch ID para autenticación local;
  • Android: API BiometricPrompt para autenticación por huella dactilar y facial;
  • Solo Local: La verificación biométrica se realiza localmente; los datos biométricos no se transmiten;
  • Alternativa: La alternativa con contraseña/PIN está siempre disponible.
  • Primer Plano/Fondo de la Aplicación: Las sesiones persisten en las transiciones de primer plano/fondo de la aplicación;
  • Terminación de la Aplicación: Las sesiones persisten tras la terminación de la aplicación (tokens almacenados en almacenamiento seguro);
  • Bloqueo del Dispositivo: El contenido de la aplicación se oculta en el selector de aplicaciones cuando el dispositivo está bloqueado;
  • Tiempo de Espera por Inactividad: El bloqueo de la aplicación se activa después de 5 minutos de inactividad, requiriendo autenticación local;
  • Caducidad de la Sesión: Las sesiones móviles respetan las mismas políticas de tiempo de espera absoluto y por inactividad (con un tiempo de espera por inactividad más largo para móviles).

Las aplicaciones móviles pueden verificar la integridad del dispositivo:

  • Detección de Jailbreak/Root: Detección de dispositivos jailbroken (iOS) o rooteados (Android);
  • Detección de Emulador: Detección de entornos de emulador;
  • Detección de Depurador: Detección de depuradores o herramientas de desarrollo;
  • Respuesta de Integridad: Ante la detección de compromiso, la aplicación puede:
  • Negarse a iniciar;
  • Limpiar los tokens almacenados;
  • Notificar al usuario;
  • Reportar el evento al equipo de seguridad.

DATACRED IMPLEMENTA LAS MEDIDAS DE SEGURIDAD DE SESIÓN DESCRITAS EN ESTA POLÍTICA COMO ESFUERZOS COMERCIALMENTE RAZONABLES PARA PROTEGER LAS SESIONES Y CUENTAS DE LOS USUARIOS. SIN EMBARGO, NINGUNA MEDIDA DE SEGURIDAD DE SESIÓN, INDEPENDIENTEMENTE DE SU INTEGRALIDAD, PUEDE GARANTIZAR LA SEGURIDAD ABSOLUTA. DATACRED NO OFRECE NINGUNA GARANTÍA, GARANTÍA O REPRESENTACIÓN, EXPRESA O IMPLÍCITA, DE QUE LAS MEDIDAS DE SEGURIDAD DE SESIÓN DESCRITAS EN EL PRESENTE DOCUMENTO PREVENDRÁN:

  • Secuestro de sesión;
  • Acceso no autorizado a la cuenta;
  • Robo de credenciales;
  • Robo o falsificación de tokens;
  • Ataques de replay de sesión;
  • Ataques de intermediario (man-in-the-middle);
  • Ataques de phishing o ingeniería social;
  • Robo de tokens basado en malware;
  • Cualquier otro compromiso de seguridad de sesión.

DATACRED RECONOCE QUE LAS SESIONES PUEDEN SER SECUESTRADAS A PESAR DE LA IMPLEMENTACIÓN DE LOS CONTROLES DE SEGURIDAD DESCRITOS EN ESTA POLÍTICA. LOS MÉTODOS DE ATAQUE QUE PUEDEN ELUDIR LAS PROTECCIONES DE SESIÓN INCLUYEN, ENTRE OTROS:

  • Malware en el dispositivo del usuario que captura tokens o credenciales;
  • Ataques de intermediario en redes comprometidas;
  • Ataques de cross-site scripting (XSS) que eluden las protecciones de cookies HttpOnly;
  • Ataques de canal lateral que filtran información relacionada con la sesión;
  • Acceso físico al dispositivo del usuario;
  • Ataques de ingeniería social que engañan a los usuarios para que revelen credenciales o tokens;
  • Vulnerabilidades de día cero en navegadores, sistemas operativos o plataformas;
  • Compromiso de proveedores de autenticación de terceros.

LOS MECANISMOS DE AUTENTICACIÓN CONTINUA DESCRITOS EN ESTA POLÍTICA (BIOMETRÍA CONDUCTUAL, DETECCIÓN DE ANOMALÍAS, REAUTENTICACIÓN BASADA EN RIESGO) SON CONTROLES DE SEGURIDAD SUPLEMENTARIOS Y NO SE GARANTIZA QUE DETECTEN TODA LA ACTIVIDAD ANÓMALA O PREVENGAN TODO ACCESO NO AUTORIZADO. PUEDEN OCURRIR FALSOS POSITIVOS Y FALSOS NEGATIVOS.

EL MARCO DE CONFIANZA DEL DISPOSITIVO DESCRITO EN LA SECCIÓN 8 SE BASA EN SEÑALES DISPONIBLES Y NO ES UNA GARANTÍA DE QUE UN DISPOSITIVO SEA SEGURO O NO HAYA SIDO COMPROMETIDO. LOS DISPOSITIVOS DE CONFIANZA PUEDEN SER COMPROMETIDOS SIN EL CONOCIMIENTO DE DATACRED. LOS USUARIOS NO DEBEN CONFIAR EN LA CONFIANZA DEL DISPOSITIVO COMO EL ÚNICO MEDIO DE PROTECCIÓN DE LA CUENTA.

EN LA MÁXIMA MEDIDA PERMITIDA POR LA LEY APLICABLE, DATACRED Y SUS AFILIADAS, FUNCIONARIOS, DIRECTORES, EMPLEADOS, AGENTES Y PROVEEDORES DE SERVICIOS NO SERÁN RESPONSABLES POR NINGÚN DAÑO DIRECTO, INDIRECTO, INCIDENTAL, ESPECIAL, CONSECUENTE O PUNITIVO DERIVADO DE O RELACIONADO CON:

  • Acceso no autorizado a cuentas de usuario;
  • Secuestro de sesión o ataques relacionados con la sesión;
  • Fallos o evasiones de autenticación;
  • Robo o compromiso de credenciales;
  • Robo, falsificación o replay de tokens;
  • Cualquier otro fallo de seguridad de sesión.

Esta limitación de responsabilidad se aplica independientemente de si DataCred implementó las medidas de seguridad de sesión descritas en esta Política e independientemente de si se alegó que las medidas de DataCred fueron negligentes, inadecuadas o ineficaces.

ESTA POLÍTICA NO ES UN CONTRATO Y NO CREA NINGÚN DERECHO U OBLIGACIÓN CONTRACTUAL. ESTA POLÍTICA ES UN DOCUMENTO TÉCNICO Y DE GOBERNANZA QUE DESCRIBE LAS PRÁCTICAS DE SEGURIDAD DE SESIÓN DE DATACRED. ESTA POLÍTICA NO CREA NINGÚN DERECHO DE BENEFICIARIO TERCERO. NINGÚN USUARIO, SOCIO U OTRO TERCERO PUEDE CONFIAR EN ESTA POLÍTICA COMO CREANDO CUALQUIER OBLIGACIÓN DE DATACRED DE IMPLEMENTAR O MANTENER CUALQUIER CONTROL DE SEGURIDAD DE SESIÓN ESPECÍFICO.

ESTA POLÍTICA Y LAS MEDIDAS DE SEGURIDAD DE SESIÓN DESCRITAS EN EL PRESENTE DOCUMENTO NO SON:

  • Una garantía de seguridad de la cuenta;
  • Una póliza de seguro contra el compromiso de la cuenta;
  • Un sustituto de las prácticas de seguridad del usuario;
  • Una garantía, expresa o implícita, de seguridad de sesión;
  • Una certificación de cumplimiento;
  • Una obligación contractual;
  • Una renuncia a cualquier derecho o defensa legal;
  • Una representación a cualquier tercero con respecto a la adecuación de controles de seguridad específicos.

Los usuarios de las plataformas de DataCred tienen las siguientes obligaciones de seguridad de sesión:

  • Contraseñas Fuertes y Únicas: Los usuarios deben utilizar contraseñas fuertes y únicas para sus cuentas de DataCred. Las contraseñas no deben reutilizarse en múltiples servicios. Se recomienda a los usuarios utilizar un gestor de contraseñas para generar y almacenar contraseñas complejas;
  • Activar MFA: Los usuarios deben activar y mantener al menos un método de MFA en su cuenta de DataCred. Se recomienda encarecidamente a los usuarios que utilicen llaves de seguridad de hardware o TOTP en lugar de SMS;
  • Dispositivos Seguros: Los usuarios deben acceder a las plataformas de DataCred solo desde dispositivos que sean razonablemente seguros, incluyendo:
  • Sistema operativo y aplicaciones actualizados;
  • Parches de seguridad activos;
  • Bloqueo de pantalla habilitado con contraseña fuerte o biométrico;
  • Cifrado del dispositivo habilitado;
  • Antivirus/antimalware actualizado (cuando corresponda);
  • Sin jailbreak ni acceso root.
  • Sin Compartición de Credenciales: Los usuarios no deben compartir sus credenciales de cuenta de DataCred, tokens de sesión, claves de API o códigos MFA con ninguna otra persona;
  • Cerrar Sesión en Dispositivos Compartidos: Los usuarios deben cerrar sesión en su cuenta de DataCred cuando utilicen dispositivos compartidos, públicos o prestados;
  • Revisión de Sesiones: Los usuarios deben revisar sus sesiones activas regularmente y terminar cualquier sesión que no reconozcan;
  • Reporte Inmediato: Los usuarios deben reportar cualquier sospecha de acceso no autorizado o compromiso de sesión a DataCred de inmediato;
  • Conciencia de Phishing: Los usuarios deben estar atentos contra intentos de phishing dirigidos a sus credenciales de DataCred y reportar comunicaciones sospechosas;
  • Códigos de Recuperación de MFA: Los usuarios deben almacenar sus códigos de recuperación de MFA en una ubicación segura fuera de línea y no compartirlos con nadie;
  • Protección de Claves de API: Los usuarios de API deben almacenar las claves de API de forma segura, rotarlas regularmente y nunca exponerlas en código del lado del cliente, control de versiones o repositorios públicos;
  • Hábito de Cierre de Sesión: Los usuarios deben cerrar sesión cuando terminen de usar las plataformas de DataCred, especialmente en dispositivos compartidos.

Los usuarios que no cumplan con sus obligaciones de seguridad de sesión:

  • Pueden tener su acceso restringido o revocado;
  • Pueden estar sujetos a requisitos de autenticación adicionales;
  • Pueden tener su cuenta suspendida o terminada;
  • Pueden no ser elegibles para asistencia de recuperación de cuenta;
  • Reconocen que asumen un mayor riesgo de compromiso de cuenta;
  • Reconocen que DataCred no es responsable por los daños resultantes de su incumplimiento de estas obligaciones.

Los usuarios que pierdan el acceso a su cuenta debido al incumplimiento de las obligaciones de seguridad (por ejemplo, dispositivo MFA perdido sin códigos de recuperación, contraseña olvidada sin acceso al correo electrónico de recuperación) reconocen que:

  • La recuperación de la cuenta puede no ser posible en todas las circunstancias;
  • La recuperación puede requerir una verificación de identidad exhaustiva;
  • La recuperación puede tardar hasta 5 días hábiles;
  • DataCred puede negarse a recuperar una cuenta a su sola discreción.

Esta Política se revisa al menos semestralmente por el CISO y el Comité Directivo de Seguridad. La revisión incluye la evaluación de:

  • Eficacia de los controles de seguridad de sesión;
  • Amenazas emergentes y técnicas de ataque;
  • Mejores prácticas de la industria y evolución de estándares;
  • Cambios en los requisitos legales y reglamentarios aplicables;
  • Retroalimentación de evaluaciones de seguridad, pruebas de penetración y revisiones de incidentes;
  • Comentarios de los usuarios y consideraciones de usabilidad.

DATACRED SE RESERVA EL DERECHO DE MODIFICAR, ENMENDAR O REEMPLAZAR ESTA POLÍTICA Y LAS MEDIDAS DE SEGURIDAD DE SESIÓN DESCRITAS EN EL PRESENTE DOCUMENTO EN CUALQUIER MOMENTO SIN AVISO. LAS MODIFICACIONES PUEDEN INCLUIR EL FORTALECIMIENTO, LA REDUCCIÓN O LA ELIMINACIÓN DE CONTROLES DE SEGURIDAD DE SESIÓN, EL CAMBIO DE PROCEDIMIENTOS DE GESTIÓN DE SESIONES O LA ACTUALIZACIÓN DE REQUISITOS DE AUTENTICACIÓN. NO OBSTANTE LO ANTERIOR, DATACRED NO REDUCIRÁ LAS MEDIDAS DE SEGURIDAD DE SESIÓN POR DEBAJO DE LO QUE DATACRED CONSIDERE RAZONABLEMENTE COMO ESTÁNDARES COMERCIALMENTE RAZONABLES DADA LA NATURALEZA DE LOS DATOS Y LOS SISTEMAS INVOLUCRADOS.

DATACRED SE RESERVA EL DERECHO DE TERMINAR CUALQUIER SESIÓN EN CUALQUIER MOMENTO, SIN AVISO, A SU SOLA DISCRECIÓN, POR CUALQUIER MOTIVO, INCLUYENDO, ENTRE OTROS:

  • Preocupaciones de seguridad;
  • Violaciones de la política;
  • Actividad sospechosa;
  • Mantenimiento del sistema;
  • Cambios en la cuenta;
  • Requisitos legales.

Se mantiene el control de versiones de esta Política. El número de versión actual y la fecha de entrada en vigor se indican al inicio de este documento.

Si usted sospecha que su cuenta de DataCred ha sido comprometida o su sesión ha sido secuestrada, contáctenos de inmediato:

  • Correo Electrónico: [email protected]
  • Emergencia: [Contacto de emergencia disponible para Personal Autorizado]

CONTROL DEL DOCUMENTO

| Versión | Fecha | Autor | Cambios |

|---------|------|--------|---------|

| 1.0 | 22 de mayo de 2026 | DataCred Security | Publicación inicial |

APROBACIONES

| Rol | Nombre | Fecha |

|-----|--------|-------|

| CISO | DataCred LLC | 22 de mayo de 2026 |

| CEO | DataCred LLC | 22 de mayo de 2026 |

| CTO | DataCred LLC | 22 de mayo de 2026 |

| CLO | DataCred LLC | 22 de mayo de 2026 |

FIN DE LA POLÍTICA DE SEGURIDAD DE SESIONES

Política de Seguridad de Sesión | DataCred