Politique de mot de passe et MFA

1) Objectifs et domaine d'action

Objectif : réduire le risque de compromettre les comptes des employés/partenaires et des joueurs, s'assurer que les normes de sécurité internes et les exigences réglementaires sont respectées.
Couverture : tous les comptes d'entreprise (SSO/IdP), les panneaux d'administration, les consoles de paiement et KYC, les comptes de service/bot, ainsi que les comptes de joueurs personnalisés.

2) Principes de base

Phishing-resistant par défaut : FIDO2/WebAuthn ≥ TOTP ≥ Push ≥ SMS/e-mail OTP (ces derniers ne sont que fallback).
Least Privilège + JIT : les privilèges sont accordés au minimum et temporairement, MFA obligatoire lors de la promotion.
Passwords as last resort : accent mis sur les passfrases et les gestionnaires de mots de passe ; interdiction des mots de passe courts « commémoratifs ».
Security by Default : MFA est activé par défaut ; pour les actions critiques - re-auth.
Observability : tous les événements d'authentification/de demande/de réinitialisation sont dans les pistes d'audit.

3) Exigences de mot de passe/pasphrases

3. 1 Employés/admins

Format : pasphrase ≥ 14 caractères, espaces autorisés ; les exigences de « complexité » du type « A1 ! » sont interdites - au lieu de cela, la vérification des fuites (have-I-been-pwned-style local/via API-hash).
Surutilisation : interdiction de la reuse des 10 derniers, interdiction du mot de passe d'entreprise pour les services externes.
Rotation : uniquement lorsque le risque est compromis ; changement périodique forcé - ne s'applique pas (pour éviter les mots de passe faibles).
Stockage : uniquement dans le gestionnaire de mot de passe d'entreprise ; L'interdiction des fichiers locaux/des stockages automatiques de navigateur en dehors des profils MDM.

3. 2 joueurs

Au moins 10 à 12 caractères ou générateur de pasphrases ; une indication visuelle de la force ; bloc de listes de mots de passe populaires.
Activer « afficher le mot de passe » et « coller à partir du gestionnaire » ; ne pas imposer de restrictions non standard (emoji/caractères - vous pouvez).

4) Hachage et secrets

Algorithme : Argon2id (mémoire ≥ 256 MB, itérations ≥ 3, parallélisme ≥ 1) ; disons que bcrypt (cost ≥ 12) est un legasi.
Sel : unique 16 + octets par enregistrement. Poivre (pepper) : secret systémique dans HSM/KMS.
La rénovation : à l'entrée legasi-khechi est transparent "перехэшировать" sur le profil en cours.
Clés de service/jetons API : pas de « mots de passe » - gérer via le gestionnaire de secrets, rotation planifiée et en cas d'incident.

5) MFA : Facteurs et priorités

• codes de sauvegarde (10 pcs, jetables), stockage hors ligne ;
• MFA-enforcement : pour les accès aux admins et les actions de paiement sans exception ;
• Number-matching dans push, interdiction par « un simple clic d'accord ».

6) Politique des sessions et re-auth

Durée : Web 12 h, admin-console 8 h, panneaux critiques 4 h

Idle timeout : 15-30 min pour les amiraux.
Re-auth avec MFA : lors de paiements/changement de détails/changement d'e-mail/MFA/émission de tokens API.
Binding d'appareils : MDM/appareil enregistré pour les employés ; pour les joueurs - mémoriser les dispositifs de confiance avec une évaluation des risques.

7) Protection contre les attaques d'authentification

Credential stuffing : IP/device/user-based rate-limits, délais de protection, analyse comportementale, vérification des mots de passe perdus.
Brute force : retards progressifs/captch après N échecs ; verrouillage doux (temporaire), sans lockout long pour les joueurs.
Spraying de mot de passe : détection par anomalie (nombreux comptes avec un seul mot de passe).
MFA-fatigue : limite des requêtes push, nombre-match, notifications à l'utilisateur.
Bot/anti-automation : WebAuthn de préférence, signaux comportementaux, fixation TLS, mTLS pour les panneaux admin.

8) Procédures (SOP)

8. 1 Onbording employé

1. Compte SSO via SCIM ;

2. l'émission de la clé FIDO2 (minimum 2 : principal + de secours) et du TOTP ;

3. l'installation d'un gestionnaire de mots de passe ;

4. confirmation de formation (phishing, MFA).

8. 2 Perte d'appareil/réinitialisation de MFA

1. L'autosuffisance via le portail → le blocage temporaire des sessions ;

2. vérification des documents + confirmation par l'intermédiaire du superviseur ;

3. la production de nouveaux facteurs ;

4. audit du journal des entrées en 30 jours.

8. 3 Break-glass (accès d'urgence)

Seulement pour la récupération ; Facteur : jeton maître stocké HSM + deuxième approbateur ; Temps ≤ 30 min ; l'enregistrement complet de la session ; Sécurité post-revue + DPO.

8. 4 Réinitialiser le mot de passe du joueur

Canal : e-mail/téléphone, lien jetable ≤ 15 min ; une fois réinitialisé, il est obligatoire de configurer le MFA à l'entrée suivante (contrainte douce avec bonus/motivation).

9) Règles pour différentes catégories de comptes

9. 1 Employés/fournisseurs

Obligatoire WebAuthn + TOTP ; interdiction des SMS-MFA.
Accès aux admins uniquement à partir des périphériques MDM/corp-VPN ; JIT lorsque vous augmentez vos privilèges.
Interdiction des comptes locaux « partagés » ; Seulement nommé.

9. 2 joueurs

MFA soft-force : bannières de motivation, bonus d'inclusion ; rigide - à risque élevé (paiements/changement de détails).
Support de disponibilité : phrases clés/lecteurs d'écran, canaux fallback.

9. 3 Comptes de service/API

Sans mot de passe ; authentification mutuelle uniquement (mTLS, OIDC client-creds, signature de webhooks).
Clés dans le gestionnaire secret ; rotation et audit.

10) Intégration avec IdP/SSO

IdP central (OIDC/SAML) ; Référence de groupe aux rôles (RBAC en tant que code).
Adaptive MFA : amplifier les facteurs de risque (géo/nouveau dispositif/anomalies).
SCIM-provisiening/de-provisiening ; Offboarding ≤ 15 min après le licenciement.

11) Journal et audit

События (аудит-обязательные): `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`.

Copie dans WORM, signature/chaîne de hachage ; référence à 'trace _ id', 'actor _ id', 'purpose'.

12) Métriques et KPI/KRI

MFA adoption (employés) : 100 % WebAuthn, 100 % TOTP comme réserve.
MFA adaptation (joueurs) : ≥ 30-50 % en 6 mois (selon le marché).
Compromised logins: 0; La proportion de tentatives avec des mots de passe cachés bloqués sur le périmètre est de 100 %.
Avg time to offboard: ≤ 15 мин.
Push fatigue alerts/1000 MAU: ↓ MoM.
Taux de réussite Password reset : ≥ 98 % sans recours au sappport.
Re-auth coverage : 100 % pour les opérations de risque élevé.

13) Exemples de politiques (fragments)

13. 1 Politique de longueur et de vérification des fuites (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-enforcement

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

13. 3 Re-auth pour les actions sensibles

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

14) Relation avec d'autres contrôles

RBAC/ABAC/SoD : L'AMF est obligatoire lors de l'attribution/modification des rôles, des levées JIT et des opérations 'APPROVE _'.
Journaux et stockage des logs : Voir « Pistes d'audit et traces d'accès », « Stratégie de stockage des logs ».
Incidents : en cas de suspicion de compromission - mot de passe immédiat + token reset, révocation de sessions, forensing (voir « Procédures en cas de fuite de données »).

15) Chèques-feuilles

Avant la sortie de l'authentification

• WebAuthn est activé, TOTP en tant que réserve, les codes de sauvegarde sont émis.
• Vérifier les mots de passe perdus et les listes lexicales.
• Taux-limites et protection contre le stuffing crédentiel.
• Re-auth pour les opérations sensibles.
• Logi/audit et alertes au SIEM.

Trimestriel

• Analyste MFA-Acceptation ; A/B-motivations pour les joueurs.
• Revoyez le politicien de la fatigue push.
• Rotation des clés de service, vérification du poivre/KMS.
• Exercice : perte de la clé de FIDO2, échec du TOTP, break-glass.

16) Feuille de route pour la mise en œuvre

Semaines 1-2 : audit d'authentification, activer WebAuthn et TOTP, configurer le breach-check, mettre à jour la politique de mot de passe (pasphrases).
Semaines 3-4 : mettre en place re-auth pour le risque élevé, number-matching dans push, SIEM-alerts ; Donner FIDO2 clés aux employés.
Mois 2 : MFA adaptatif (signaux de risque), gestionnaire de mot de passe complet, portail de réinitialisation self-service, codes de sauvegarde.
Mois 3 + : Promotion A/B du MFA aux joueurs, exercices périodiques, optimisation UX et réduction du MFA-fatigue, automatisation des rapports KPI.

TL; DR

Authentification forte = pasphrases + WebAuthn (obligatoire) + TOTP (réserve) + re-auth pour les actions à risque, protection contre le stuffing/brute, hachage fiable (Argon2id), gestionnaire de mots de passe et audit de chaque étape. Cela réduit la compromission des comptes, simplifie la conformité et presque pas le trot UX si vous le faites correctement.