GH GambleHub

Criteri di password e MFA

1) Obiettivi e ambito

Obiettivo: ridurre il rischio di compromissione degli account dipendenti/partner e giocatori, garantire la conformità agli standard di sicurezza interni e ai regolatori.
Copertura: tutti gli account aziendali (SSO/IdP), i pannelli admine, i pagamenti e le console KYC, i servizi/bot e gli account utente dei giocatori.

2) Principi di base

Phishing-resistant predefinito: TOTP Push SMS/e-mail OTP (ultimo solo come fallback).
Least Privilege + JIT - Privilegi sono concessi in modo minimo e temporaneo, MFA obbligatorio durante l'aumento.
Passwords as last resort - Concentrarsi su pasfrasi e gestori di password Proibire le password brevi commemorative.
Sicurezza by Default: MFA abilitato per impostazione predefinita per le azioni critiche - re-auth.
Osservabilità: tutti gli eventi di autenticazione/richiesta/reimpostazione sono nei registri di revisione.

3) Requisiti di password/saldatura

3. 1 Dipendenti/ammini

Formato: saldatura a 14 caratteri, spazi consentiti non sono consentiti i requisiti di «complessità» di tipo «A1!»: è invece possibile verificare le perdite (have-I-been-pwned-stile locale/tramite API-hash).
Riutilizzo: non reuse degli ultimi 10, non password aziendale per servizi esterni.
Rotazione: solo in caso di compromissione/rischio; cambio periodico forzato - non applicabile (per evitare password deboli).
Storage: solo nel gestore delle password aziendale Impedimento dei file locali o dei browser automatici al di fuori dei profili MDM.

3. 2 Giocatori

Un minimo di 10-12 caratteri o un generatore di saldatura; Indicazione visiva della forza Blocco delle password popolari.
Attivare «mostra la password» e «incolla dal gestore» non imporre vincoli non standard (emoji/caratteri - è possibile).

4) Hash e segreti

Algoritmo: Argon2id (memoria 256 MB, iterazioni 3, parallelismo 1); ammettiamo bcrypt (cost ≥ 12) come legasi.
Il sale è unico: 16, + byte per registrazione. Pepe (pepper) - Segreto di sistema in HSM/KMS.
Aggiornamento: quando si accede legasi-hash, è trasparente «ricondurre» al profilo corrente.
Chiavi di servizio/API token: non password - Gestione tramite il gestore segreto, rotazione pianificata e in caso di incidenti.

5) MFA: fattori e priorità

FattoreResistenza al phishingDove applicare
FIDO2/WebAuthn (chiavi, piattaforma TouchID/Windows Hello)altadipendenti/admini, operazioni high-risk nei giocatori
TOTP (RFC 6238)mediadipendenti e giocatori (fallback principale)
Push (conferma nell'applicazione)mediadipendenti/giocatori; proteggersi da MFA-fatige (rate-limit, number-match)
SMS/e-mail OTPbassasolo come riserva in caso di perdita del dispositivo e per low-risk
Obbligatorio:
  • Backup dei codici di backup (10, monouso), archiviazione offline
  • MFA-enforcement: per l'accessibilità e le azioni di pagamento senza esclusioni;
  • Number-matching in push, divieto di «accettare con un solo clic».

6) Criteri di sessione e re-auth

Durata: web 12 ore ( ), console admine 8 ore, pannelli critici 4 ore

Idle timeout: 15-30 min per Ammiraglio.
Re-auth con MFA: in caso di pagamento/cambio di identità/modifica e-mail/MFA/rilascio di token API.
Device binding: MDM/dispositivo registrato per i dipendenti; per i giocatori - memorizzazione di dispositivi affidabili con valutazione del rischio.

7) Protezione dagli attacchi di autenticazione

Credential stuffing: IP/device/user-based rate-limits, ritardi di protezione, analisi comportamentali, controllo delle password.
Brute force: progressivi ritardi/capch dopo N fallimenti; blocchi morbidi (temporanei), senza lockout prolungato per i giocatori.
Password spraying - Rilevamento per anomalie (molti account con password singola).
MFA-fatige - Limite di query push, number-match, notifica all'utente.
Bot/anti-automation: preferibilmente, segnali comportamentali, fissazione TLS, per pannelli admine.

8) Procedure (SOP)

8. 1 Onboording del dipendente

1. Account SSO tramite SCIM;

2. rilascio di chiave FIDO2 (minimo 2: principale + ridondante) e TOTP;

3. Installazione del gestore password

4. conferma di formazione (phishing, MFA).

8. 2 Perdita dispositivo/reimpostazione MFA

1. Il blocco temporaneo delle sessioni tramite il portale;

2. Verifica documenti + conferma tramite responsabile

3. rilascio di nuovi fattori

4. Controllo del registro degli ingressi in 30 giorni.

8. 3 Break-glass (accesso di emergenza)

Solo per il ripristino; fattore: token master memorizzato HSM + secondo approvatore Tempo massimo di 30 minuti; Registrazione completa della sessione Sicurezza + DPO post-review.

8. 4 Reimposta password del giocatore

Canale: e-mail/telefono, collegamento usa e getta 15 min; dopo la reimpostazione: impostazione obbligatoria dell'MFA al successivo accesso (forzatura morbida con bonus/motivazione).

9) Regole per diverse categorie di crediti

9. 1 Dipendenti/venditori

Obbligatorio WebAuthn + TOTP; Divieto SMS-MFA.
Accesso agli admini solo con dispositivi MDM/corp-VPN; JIT al miglioramento dei privilegi.
Vietare gli account «condivisi» locali; Solo quelli di nome.

9. 2 Giocatori

MFA morbido-obbligatorio: banner di motivazione, bonus di inclusione; rigido - a high-risk (pagamenti/cambio di identità).
Supporto della disponibilità: frasi chiave/lettori di visualizzazione, canali fallback.

9. 3 Account di assistenza/API

Senza password; solo autenticazione reciproca (mTLS, OIDC client-creds, firma webhoop).
Le chiavi sono il segreto manager; rotazione e controllo.

10) Integrazione con l' IdP/SSO

IdP centrale (OIDC/SAML); Riferimento di gruppo ai ruoli (RBAC as code).

Adattative MFA (geo/nuovo dispositivo/anomalie)

SCIM-Provigening/de-Provigening offboarding 15 minuti dopo il licenziamento.

11) Registro e controllo

События (аудит-обязательные): `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 in WORM, firma/catena hash; aggancio a «trace _ id», «attore _ id», «purpose».

12) Metriche e KPI/KRI

MFA adoption (dipendenti): 100% WebAuthn, 100% TOTP come riserva.
MFA adoption (giocatori): ≥ 30-50% in 6 mes (a seconda del mercato).
Compromised logins: 0; la percentuale di tentativi con password perse bloccati nel perimetro è del 100%.
Avg time to offboard: ≤ 15 мин.
Push fatigue alerts/1000 MAU: ↓ MoM.
Password reset success rate: ≥ 98% senza accedere allo zapport.
Re-autoh coverage: 100% per le operazioni high-risk.

13) Esempi di regole (sezioni)

13. 1 Criteri di lunghezza e verifica delle perdite (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 Enforsment MFA

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

13. 3 Re-auth per azioni sensibili

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

14) Relazione con altri controlli

RBAC/ABAC/SoD: MFA è obbligatorio per assegnare/modificare ruoli, sollevamenti JIT e operazioni «APPROVE _».
Registri e archivi dei fogli - Consultate Registri di revisione e tracce di accesso, Criteri di conservazione dei tubo.
Incidenti: in caso di sospetto compromissione - immediato password + token reset, ritiro delle sessioni, forensica (vedere Procedure per la fuga di dati).

15) Assegno fogli

Prima del rilascio dell'autenticazione

  • Abilitato, TOTP come riserva, i codici di backup vengono rilasciati.
  • Verifica delle password e degli elenchi lessicali.
  • Rate-limits e protezione contro credential stuffing.
  • Re-auth per le operazioni sensibili.
  • Logi/verifiche e alert in SIEM.

Trimestrale

  • Analisi dell'adozione MFA; Motivatori A/B per i giocatori.
  • Ruota il criterio Push-stanchezza.
  • Rotazione delle chiavi di servizio, controllo del peperoncino/KMS.
  • Esercitazione: perdita della chiave FIDO2, interruzione TOTP, break-glass.

16) Road map di implementazione

Settimane 1-2: controllo dell'autenticazione, attivazione di WebAuthn e TOTP, configurazione di breach-check, aggiornamento del criterio delle password.
Settimane 3-4: implementare re-auth per high-risk, number-matching in push, SIEM-alert; distribuire le chiavi FIDO2 ai dipendenti.
Mese 2: MFA adattivo, gestore delle password completo, portale di reimpostazione self-service, codici di backup.
Mese 3 +: A/B promozione MFA giocatori, esercitazioni periodiche, ottimizzazione UX e riduzione MFA-fatige, automazione dei rapporti KPI.

TL; DR

Forte autenticazione = pasfrasi + WebAuthn (obbligatorio) + TOTP (riserva) + re-auth per azioni rischiose, protezione da stuffing/brute, hash affidabile (Argon2id), gestore password e controllo di ogni passo. Questo riduce la compromissione degli account, semplifica la conformità e quasi non lo strato UX se si fa bene.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Telegram
@Gamble_GC
Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.