GH GambleHub

Política de contraseñas y MFA

1) Objetivos y alcance

Objetivo: reducir el riesgo de comprometer las cuentas de empleados/socios y jugadores, garantizar el cumplimiento de las normas de seguridad internas y los requisitos de los reguladores.
Alcance: todas las cuentas corporativas (SSO/IdP), paneles de administración, consolas de pago y KYC, cuentas de servicio/bot, así como cuentas de usuario de los jugadores.

2) Principios básicos

Resistencia a la física predeterminada: FIDO2/WebAuthn ≥ TOTP ≥ Push ≥ SMS/e-mail OTP (estos últimos sólo como fallback).
Privilegio Least + JIT: los privilegios se emiten de forma mínima y temporal, MFA es obligatorio cuando se aumenta.
Passwords as last resort: énfasis en pasfrases y gestores de contraseñas; prohibición de contraseñas cortas «conmemorativas».
Security by Default: MFA está habilitado de forma predeterminada; para acciones críticas - re-auth.
Observabilidad: todos los eventos de autenticación/solicitud/reinicio están en los registros de auditoría.

3) Requisitos de contraseñas/pasfrases

3. 1 Empleados/Almirantes

Formato: pasfrase ≥ 14 caracteres, espacios permitidos; los requisitos de «complejidad» del tipo 'A1!' están prohibidos - en cambio, la verificación de fugas (have-I-been-pwned-style localmente/vía API-hash).
Reutilización: prohibición de reuse de los últimos 10, prohibición de contraseña corporativa para servicios externos.
Rotación: sólo en caso de compromiso/riesgo; Cambio periódico forzado: no se aplica (para evitar contraseñas débiles).
Almacenamiento: sólo en el administrador de contraseñas de la empresa; prohibición de archivos locales/almacenamiento automático del navegador fuera de los perfiles MDM.

3. 2 Jugadores

Mínimo de 10-12 caracteres o generador de paspfraz; indicación visual de la fuerza; bloque de listas de contraseñas populares.
Habilitar «mostrar contraseña» e «insertar desde el gestor»; no imponer restricciones no estándar (emoji/caracteres - se puede).

4) Hashing y secretos

Algoritmo: Argon2id (memoria ≥ 256 MB, iteraciones ≥ 3, paralelismo ≥ 1); digamos bcrypt (costo ≥ 12) como legasi.
Sal: 16 + bytes únicos por entrada. Pimienta (pepper): el secreto del sistema en HSM/KMS.
Actualización: al iniciar sesión en legashi hashi, «reenviar» de forma transparente al perfil actual.
Claves de servicio/API-tokens: no «contraseñas» - administrar a través del administrador secreto, rotación programada y en caso de incidentes.

5) MFA: factores y prioridades

FactorResistencia al phishingDónde aplicar
FIDO2/WebAuthn (claves, plataforma TouchID/Windows Hello)Altoempleados/almirantes, operaciones de alto riesgo en los jugadores
TOTP (RFC 6238)Mediaempleados y jugadores (principal fallback)
Inserción (confirmación en la aplicación)Mediaempleados/jugadores; protegerse contra MFA-fatigue (rate-limit, number-match)
SMS/e-mail OTPBajasólo como reserva cuando se pierde el dispositivo y para bajo riesgo
Necesariamente:
  • códigos de copia de seguridad (10 piezas, desechables), almacenamiento fuera de línea;
  • MFA-enforcement: para accesos administrativos y acciones de pago sin excepciones;
  • Number-matching in push, prohibición de «con un solo clic de acuerdo».

6) Política de sesiones y re-auth

Duración: web 12 h (interactivo), consolas de administración 8 h, paneles críticos 4 h.
Idle timeout: 15-30 min para Almirantes.
Re-auth con MFA: en pagos/cambio de datos/cambio de correo electrónico/MFA/emisión de tokens API.
Device binding: MDM/dispositivo registrado para empleados; para los jugadores - memorizar dispositivos de confianza con evaluación de riesgo.

7) Protección contra ataques de autenticación

Credential stuffing: IP/device/user-based rate-limits, retardos de protección, análisis de comportamiento, comprobación de contraseñas filtradas.
Fuerza bruta: retrasos progresivos/capcha después de fallas N; bloqueos blandos (temporales), sin bloqueo prolongado para los jugadores.
spraying contraseña: detección de anomalías (muchas cuentas con una sola contraseña).
MFA-fatigue: límite de solicitudes push, número-match, notificaciones al usuario.
Bot/anti-automatización: WebAuthn preferiblemente, señales de comportamiento, fijación TLS, mTLS para paneles de administración.

8) Procedimientos (SOP)

8. 1 Empleado de Onboarding

1. Cuenta SSO a través de SCIM;

2. emisión de clave FIDO2 (mínimo 2: principal + de respaldo) y TOTP;

3. Establecer un gestor de contraseñas;

4. confirmación de aprendizaje (phishing, MFA).

8. 2 Pérdida de dispositivo/restablecimiento de MFA

1. Autoinformación a través del portal → bloqueo temporal de sesiones;

2. verificación de documentos + confirmación a través del supervisor;

3. La liberación de nuevos factores;

4. Auditoría del registro de inicio de sesión en 30 días.

8. 3 Break-glass (acceso de emergencia)

Sólo para recuperación; factor: token maestro almacenado en HSM + segundo aprobador; Tiempo ≤ 30 minutos; Grabación completa de la sesión; Security + DPO post-review.

8. 4 Restablecimiento de la contraseña del jugador

Canal: e-mail/teléfono, enlace desechable ≤ 15 min; después de reiniciar - Configuración obligatoria de MFA en la próxima entrada (compulsión suave con bonificación/motivación).

9) Reglas para diferentes categorías de cuentas

9. 1 Empleados/vendedores

Es obligatorio WebAuthn + TOTP; Prohibición de SMS-MFA.
Acceso a los administradores sólo desde dispositivos MDM/corp-VPN; JIT cuando aumenta los privilegios.
Prohibición de cuentas locales «compartidas»; sólo con nombre.

9. 2 Jugadores

MFA suave-forzado: banners motivacionales, bonos de inclusión; rígido - bajo alto riesgo (pago/cambio de datos).
Soporte de disponibilidad: frases clave/lectores de pantalla, canales fallback.

9. 3 Cuentas de servicio/API

Sin contraseñas; sólo autenticación mutua (mTLS, OIDC client-creds, firma de webhooks).
Las claves están en el administrador secreto; rotación y auditoría.

10) Integración con IdP/SSO

IdP central (OIDC/SAML); referencia de grupo a roles (RBAC as code).
MFA adaptativa: amplificar los factores por señales de riesgo (geo/nuevo dispositivo/anomalías).
SCIM-visioning/de-viwening; offboarding ≤ 15 minutos después del despido.

11) Registro y auditoría

События (аудит-обязательные): `LOGIN_SUCCESS/FAIL`, `MFA_ENROLL/VERIFY/FAIL`, `PASSWORD_RESET_REQUEST/COMPLETE`, `MFA_RESET`, `DEVICE_TRUST_ADD/REMOVE`, `BREAK_GLASS_START/END`, `ADMIN_LOGIN`, `RISK_UPGRADE`, `TOKEN_ISSUE/REVOKE`.

Copia en WORM, cadena de firma/hash; referencia a 'trace _ id', 'actor _ id', 'purpose'.

12) Métricas y KPI/KRI

MFA (empleados): 100% WebAuthn, 100% TOTP como reserva.
MFA adoption (jugadores): ≥ 30-50% en 6 meses (dependiendo del mercado).
Compromised logins: 0; la proporción de intentos con contraseñas filtradas bloqueadas en el perímetro es del 100%.
Avg time to offboard: ≤ 15 мин.
Push fatigue alerts/1000 MAU: ↓ MoM.
Password reset success rate: ≥ 98% sin recurrir al sapport.
Re-auth coverage: 100% para operaciones de alto riesgo.

13) Ejemplos de políticas (fragmentos)

13. 1 Política de longitud y verificación de fugas (pseudo-YAML)

yaml password:
min_length: 14 allow_spaces: true banned_lists:
- top100k_common
- organization_keywords breach_check: enabled  # k-anonymity lookup rotation: on_compromise_only

13. 2 MFA-envolvente

yaml mfa:
required_roles:
- admin
- payments
- aml
- kyc required_factors:
- webauthn fallback:
- totp disallowed:
- sms

13. 3 Re-auth para actividades sensibles

yaml reauth:
actions:
- change_payout_details
- approve_withdrawal
- change_email
- manage_mfa ttl_minutes: 5

14) Relación con otros controles

RBAC/ABAC/SoD: MFA es obligatorio cuando se asignan o modifican roles, elevaciones JIT y operaciones 'APPROVE _'.
Registros y almacenamiento de registros: consulte «Registros de auditoría y rastros de acceso», «Política de retención de registros».
Incidentes: en caso de sospecha de compromiso - inmediato password + token reset, revocación de sesiones, forensic (ver «Procedimientos en caso de filtración de datos»).

15) Hojas de cheques

Antes de la versión de autenticación

  • WebAuthn está habilitado, TOTP como reserva, los códigos de respaldo se emiten.
  • Comprobación de contraseñas filtradas y listas léxicas.
  • Rate-limits y protección contra el stuffing credential.
  • Re-auth para operaciones sensibles.
  • Registros/auditorías y alertas en SIEM.

Trimestral

  • Análisis de MFA-aceptación; A/B-motivadores para los jugadores.
  • Un político revuelo de la fatiga push.
  • Rotación de llaves de servicio, verificación de pimienta/KMS.
  • Enseñanzas: pérdida de clave de FIDO2, fracaso TOTP, break-glass.

16) Hoja de ruta para la implementación

Semanas 1-2: auditar la autenticación, habilitar WebAuthn y TOTP, configurar breach-check, actualizar la política de contraseñas (pasfrases).
Semanas 3-4: introducir re-auth para high-risk, number-matching en push, alertas SIEM; repartir FIDO2 llaves a los empleados.
Mes 2: MFA adaptable (señales de riesgo), gestor de contraseñas con todas las funciones, portal de reinicio de autoservicio, códigos de respaldo.
Mes 3 +: Promoción A/B de MFA a jugadores, ejercicios periódicos, optimización de UX y reducción de MFA-fatigue, automatización de informes de KPI.

TL; DR

Autenticación fuerte = pasfrases + WebAuthn (obligatorio) + TOTP (reserva) + re-auth para actividades de riesgo, protección contra stuffing/brute, hashing confiable (Argon2id), gestor de contraseñas y auditoría de cada paso. Esto reduce el compromiso de las cuentas, simplifica el cumplimiento de normas y casi no convierte a UX si se hace de manera competente.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.