> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Protezione dai bot al login: stuffing e brute force > Didit protegge registrazione e login da bot, credential stuffing, brute force, email usa e getta, reti rischiose e impossible travel. > [!WARNING] > > 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. ```json theme={null} { "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](https://docs.didit.me/it/authentication/events-and-webhooks.md), dove le regole possono leggere `event.device.bot_score`. > [!NOTE] > > `AUTOMATION_FRAMEWORK_DETECTED` è un controllo diverso. È un [avviso di analisi IP e dispositivo](https://docs.didit.me/it/core-technology/ip-analysis/warnings-ip-analysis.md) 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: ```json theme={null} { "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](https://docs.didit.me/it/authentication/events-and-webhooks.md): `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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.