Protezione dai bot al login: stuffing e brute force

L’autenticazione è una novità. La protezione resta disattivata finché non la attivi. I limiti di frequenza e i limiti ai tentativi con i codici si applicano sempre.

La protezione dai bot viene applicata a ogni registrazione, accesso e reimpostazione della password. Verifica ogni tentativo rispetto a sei policy. Ogni policy ha una modalità:

Modalità	Cosa succede
Disattivato	La policy non viene verificata.
Registra	Il tentativo prosegue. Un evento `risk_logged` registra la corrispondenza.
Verifica	La persona deve superare una prova aggiuntiva prima che il tentativo prosegua.
Blocca	Il tentativo fallisce con `403 {"error": "attempt_blocked"}`.

Configurare la protezione

Leggi e modifica le impostazioni con GET e PATCH su protection/ nell’API di gestione dell’autenticazione della tua applicazione, oppure dalla console.

{
  "enabled": true,
  "breached_password_check": true,
  "policies": {
    "bots": "block",
    "stuffing": "block",
    "brute": "challenge",
    "disposable": "block",
    "vpn": "challenge",
    "travel": "block"
  }
}

enabled e breached_password_check sono false per impostazione predefinita. Le modalità descritte sopra sono quelle predefinite una volta attivata la protezione.

Policy

Policy	Corrisponde quando
`bots`	Il client riporta un punteggio bot pari o superiore a 0,8, oppure lo user agent è un browser headless o automatizzato noto.
`stuffing`	Un dispositivo o un IP prova 10 o più account diversi entro 15 minuti, oppure la password è una password compromessa nota.
`brute`	L’account ha 5 o più tentativi falliti. Contano le password errate e i codici errati di email, telefono e autenticatore.
`disposable`	Una registrazione usa un dominio email usa e getta.
`vpn`	L’IP appartiene a una rete VPN, Tor o di data center.
`travel`	L’accesso avviene a più di 500 km dal precedente, a una velocità superiore a 1.000 km/h, entro 24 ore.

Le policy vpn e travel usano l’analisi IP di Didit. Se questa verifica non è disponibile, il tentativo prosegue: un accesso non fallisce mai a causa di questa indisponibilità. La posizione usata da travel si aggiorna solo dopo un accesso completato.

Forza bruta e blocco

La modalità brute decide cosa succede dopo 5 tentativi falliti:

Blocca: la persona deve reimpostare la password prima di poter accedere di nuovo.
Verifica: l’account viene bloccato per 15 minuti e il tentativo successivo richiede una prova aggiuntiva.
Disattivato o Registra: nessun blocco.

La reimpostazione della password resta disponibile dopo un blocco per forza bruta, e una reimpostazione annulla il blocco. Il tuo team può anche sbloccare un account dalla console. Se non hai mai salvato le impostazioni di protezione, si applica una regola più semplice: 5 password errate bloccano l’account per 15 minuti.

Punteggio bot e segnali del dispositivo

Invia i segnali del dispositivo nelle chiamate di runtime con queste intestazioni. Le pagine ospitate le inviano per te.

Intestazione	Contenuto
`X-Didit-PID`	Un ID dispositivo persistente, da 8 a 128 caratteri tra `A-Z a-z 0-9 . _ : -`.
`X-Didit-FP-Hash`	Un’impronta digitale del dispositivo.
`X-Didit-FP-Bot-Score`	Un punteggio bot da 0 a 1. I valori fuori da questo intervallo vengono ignorati.

Questi segnali forniscono il contesto per una decisione, non una prova di identità. Vengono trasmessi anche con ogni evento di accesso, dove le regole possono leggere event.device.bot_score.

AUTOMATION_FRAMEWORK_DETECTED è un controllo diverso. È un avviso di analisi IP e dispositivo sulle sessioni di verifica, generato quando l’SDK di verifica segnala un framework di automazione del browser. Non viene eseguito durante l’accesso: in quel caso, l’automazione viene rilevata dalla policy bots descritta sopra.

Verifiche

Un tentativo sottoposto a verifica restituisce questo invece di un codice di accesso:

{
  "protection_required": true,
  "challenge": "...",
  "methods": ["passkey", "email_code"],
  "options": { "...": "WebAuthn options when a passkey is offered" },
  "expires_in": 300
}

Completa la procedura con POST protection/complete/:

{"challenge", "method": "email_code", "code"} con il codice a 6 cifre inviato all’email della persona, oppure
{"challenge", "method": "passkey", "response"} con la risposta WebAuthn.

Hai 5 tentativi entro 5 minuti. Se la persona non ha alcuna prova disponibile, la chiamata restituisce 403 {"error": "protection_factor_unavailable"}.

Password compromesse

Con breached_password_check: true, Didit verifica le nuove password e quelle reimpostate rispetto alle password compromesse note. La password non viene mai inviata da nessuna parte. Una password compromessa viene rifiutata con password_breached. In fase di accesso, una password compromessa conta come corrispondenza di stuffing. Se il controllo non è disponibile, la password viene accettata.

Modalità attacco

Attiva la modalità attacco durante un attacco in corso:

POST protection/attack-mode/ con {"duration_hours": 1} (oppure 6 o 24) restituisce 201.
DELETE protection/attack-mode/ la termina in anticipo. Termina anche da sola al termine della durata.

Mentre la modalità attacco è attiva:

ogni registrazione e ogni accesso devono superare una verifica con passkey. Il codice via email non viene accettato. Le nuove registrazioni e le persone senza passkey non possono completare l’operazione finché la modalità attacco non termina.
una registrazione da una rete VPN, Tor o di data center viene bloccata.

Limiti di frequenza

Ogni route di runtime è limitata per IP e per applicazione:

Route	Al minuto	All’ora
Discovery e JWKS	1.200	12.000
API di runtime e pagine ospitate	30	300
Codici email, codici telefonici e callback dei provider	5	20

Oltre il limite, la chiamata restituisce 429. Rispetta l’intestazione Retry-After quando viene inviata. I tentativi di accesso sono limitati anche al minuto: 60 per IP, 15 per account, 30 per dispositivo, 3.000 per applicazione e 20 richieste di codice SMS o WhatsApp per prefisso del numero di telefono. I rinnovi dei token hanno un proprio limite per applicazione, 6.000 al minuto, quindi i rinnovi non consumano i tuoi accessi.

Eventi

Ogni decisione viene registrata come evento di autenticazione: risk_logged, attempt_challenged, attempt_blocked, challenge_passed, challenge_failed, attack_mode_started e attack_mode_ended. L’evento indica quale policy ha generato la corrispondenza.

Provala

In un’applicazione sandbox, prova ogni modalità che attivi: un tentativo bloccato, una verifica superata e una fallita, un blocco e il suo ripristino, e la modalità attacco attivata e disattivata. Nella tua interfaccia mantieni messaggi di errore generici, così non rivelano se un account esiste.

Guide

Autenticazione

Model Context Protocol (MCP)

SDK web

SDK nativi

SDK server

Integrazioni

Protezione dai bot al login: stuffing e brute force

Configurare la protezione

Policy

Forza bruta e blocco

Punteggio bot e segnali del dispositivo

Verifiche

Password compromesse

Modalità attacco

Limiti di frequenza

Eventi

Provala

​Configurare la protezione

​Policy

​Forza bruta e blocco

​Punteggio bot e segnali del dispositivo

​Verifiche

​Password compromesse

​Modalità attacco

​Limiti di frequenza

​Eventi

​Provala

Configurare la protezione

Policy

Forza bruta e blocco

Punteggio bot e segnali del dispositivo

Verifiche

Password compromesse

Modalità attacco

Limiti di frequenza

Eventi

Provala