Rate limiting degli OTP via SMS: limiti per utente, numero, IP e dispositivo senza penalizzare l’autenticazione

Perché il rate limiting degli OTP è una policy operativa, non solo un controllo tecnico

Il rate limiting degli OTP via SMS protegge contemporaneamente diverse risorse: il flusso di autenticazione, il budget di messaggistica, la capacità operativa e l’esperienza di chi tenta di accedere legittimamente. Una policy troppo permissiva può facilitare richieste automatizzate, saturare il canale SMS del destinatario e generare traffico artificiale. Una policy troppo rigida può impedire accessi legittimi o diventare un vettore di denial of service contro account specifici.

L’obiettivo non è bloccare indiscriminatamente gli SMS. È decidere, in modo misurabile e rivedibile, quando consentire una richiesta, quando introdurre un’attesa o un’ulteriore frizione e quando limitare temporaneamente un’azione rischiosa. L’unità di controllo deve corrispondere all’azione protetta e al rischio osservato.

• Separare l’abuso delle richieste dagli errori nell’inserimento del codice.
• Evitare che una restrizione basata su un unico segnale, come l’IP, determini da sola il risultato.
• Misurare l’effetto di ogni limite su sicurezza, conversione, reinvii e costi.
• Mantenere un percorso di recupero autorizzato per chi non riesce a completare il flusso abituale.

Cosa proteggere in un flusso OTP via SMS

Un flusso OTP contiene azioni distinte e non dovrebbero necessariamente condividere la stessa quota. Come minimo, è opportuno trattare separatamente la richiesta iniziale del codice, il reinvio, la verifica del codice e il passaggio a un canale alternativo o di recupero. Ogni azione presenta una diversa superficie di abuso.

La verifica del codice richiede una protezione particolarmente attenta. Quando il segreto di autenticazione è breve, NIST richiede un limite effettivo ai tentativi falliti consecutivi per account e stabilisce che l’emissione di un nuovo codice non deve azzerare quel contatore. Il codice deve essere monouso e il processo fuori banda non è più valido se non viene completato entro dieci minuti.

La richiesta o il reinvio non devono modificare da soli lo stato di un account. Una richiesta ripetuta può giustificare un’attesa, un controllo aggiuntivo o una limitazione temporanea dell’azione, ma non deve produrre modifiche sensibili finché non viene presentato un segreto valido.

• Richiesta iniziale: protegge da automazione e generazione di traffico SMS.
• Reinvio: evita duplicati, affaticamento del destinatario e pressione artificiale sul trasporto.
• Verifica: limita l’indovinamento del codice e deve conservare il contatore degli errori anche se viene emesso un nuovo codice.
• Cambio di canale o recupero: richiede regole dedicate e una valutazione del rischio proporzionata.

Limitare più entità, non soltanto l’indirizzo IP

Una policy basata solo sull’IP è insufficiente. Un attaccante può distribuire i tentativi su più indirizzi, mentre utenti legittimi possono condividere la stessa uscita di rete. OWASP raccomanda di associare il contatore degli errori all’account invece di dipendere esclusivamente dall’IP.

La pratica più utile consiste nel combinare diverse dimensioni. L’account o l’identità di accesso aiutano a proteggere il processo di autenticazione; il numero MSISDN controlla la destinazione dell’SMS; l’IP fornisce contesto sull’origine; il dispositivo, la sessione e la campagna o applicazione consentono di rilevare concentrazioni. Nessun segnale deve essere interpretato da solo come prova conclusiva.

Prima di applicare quote per numero, normalizzare la destinazione in modo coerente tramite uno schema di numerazione internazionale, come E.164. Senza normalizzazione, diverse rappresentazioni dello stesso numero possono frammentare i contatori o produrre decisioni incoerenti.

• Account: essenziale per limitare errori di verifica consecutivi e proteggere dalla forza bruta distribuita.
• MSISDN normalizzato: utile per controllare richieste e reinvii diretti alla stessa destinazione.
• IP: segnale complementare per rilevare volume, automazione o concentrazione, non identità dell’utente.
• Dispositivo: aggiunge contesto, ma deve essere usato con proporzionalità perché può essere condiviso.
• Sessione: consente di collegare richieste e verifiche a un flusso specifico.
• Campagna o applicazione: aiuta a isolare i problemi e a evitare che un’integrazione influenzi le altre.

Come scegliere finestre, quote e tempi di raffreddamento

Non esiste una quota universale verificabile adatta a tutti i servizi. Le soglie devono derivare dal rischio del caso d’uso, dalla popolazione prevista, dalla tolleranza alle frodi, dalla capacità del servizio e dall’impatto del blocco di una persona legittima. Devono essere documentate e riesaminate usando i propri dati.

Una finestra fissa è semplice da spiegare e verificare, ma può concentrare le richieste vicino ai suoi limiti. Una finestra mobile offre una lettura più continua del comportamento recente, anche se richiede un’implementazione e un’osservabilità più attente. Un tempo di raffreddamento progressivo riduce la ripetizione immediata senza imporre fin dall’inizio un divieto prolungato.

OWASP individua tre elementi che devono essere espliciti: il numero di errori che attiva la restrizione, il periodo nel quale vengono conteggiati e la durata della restrizione. Descrive inoltre il blocco esponenziale, nel quale l’attesa inizia breve e aumenta dopo errori successivi.

• Usare finestre semplici quando la priorità è la spiegabilità operativa e l’audit.
• Usare finestre mobili quando è importante evitare picchi artificiali intorno a un ripristino temporale.
• Applicare un tempo di raffreddamento progressivo alle azioni ripetitive prima di ricorrere a blocchi estesi.
• Documentare per ogni regola: entità, azione, soglia, finestra, durata, eccezione autorizzata, responsabile e condizione di revoca.

Separare richiesta, reinvio e verifica evita controlli contraddittori

La richiesta iniziale e il reinvio consumano capacità di messaggistica; la verifica consuma capacità di controllo e affronta il rischio di indovinamento. Un unico contatore per l’intero flusso mescola le cause e rende più difficile indagare su ciò che accade.

Un’implementazione prudente può mantenere uno stato della challenge per sessione o transazione: destinazione normalizzata, account se presente nel flusso, identificatore della richiesta, ora di emissione, scadenza, stato di utilizzo, contatore delle verifiche fallite e riferimenti pseudonimizzati ai segnali di rischio. Il segreto OTP non deve essere registrato in chiaro.

Anche l’idempotenza è importante. Se il client ritenta una richiesta a causa di una risposta persa o di una condizione di rete, il servizio deve poter riconoscere la ripetizione in un contesto controllato invece di generare inutilmente più messaggi. Questa scelta riduce i duplicati e rende più affidabile il conteggio delle richieste.

• Non azzerare gli errori di verifica quando viene generato un nuovo codice.
• Contrassegnare il codice come utilizzato dopo un uso valido per impedirne il riutilizzo.
• Mostrare all’utente quando può richiedere un nuovo invio, senza rivelare informazioni sull’account.
• Progettare ritenti tecnici idempotenti per non confonderli con nuove richieste umane.
• Separare le code di invio dalla logica di autorizzazione: accettare una richiesta non equivale a confermare l’autenticazione.

Risposte sicure e frizione progressiva

La risposta di un endpoint OTP deve essere neutrale riguardo all’esistenza, allo stato e al possibile blocco di un account. OWASP raccomanda messaggi coerenti e una temporizzazione uniforme per ridurre l’enumerazione attraverso differenze di contenuto o tempo.

Quando un segnale di rischio aumenta, è preferibile applicare una frizione progressiva anziché un blocco ampio. Per esempio, un’attesa visibile prima del reinvio, un controllo aggiuntivo contro l’automazione o una revisione del rischio possono essere misure proporzionate. CAPTCHA può agire come difesa in profondità e può essere introdotto dopo alcuni errori, non necessariamente al primo tentativo.

Le restrizioni devono impedire l’abuso senza consentire a terzi di escludere utenti legittimi. Per questo, non è opportuno applicare una sospensione estesa dell’account unicamente perché qualcuno ha richiesto ripetutamente codici per quella destinazione.

• Usare messaggi come: “Se il flusso è valido, riceverai istruzioni o potrai continuare al termine dell’attesa”.
• Mostrare un conto alla rovescia per il reinvio associato alla transazione, non informazioni sull’esistenza di un account.
• Aumentare la frizione in base a ripetizione, velocità e concentrazione dei segnali, non a una singola osservazione isolata.
• Riservare restrizioni a maggiore impatto per rischi corroborati e per una durata definita.
• Offrire un recupero autorizzato quando il canale abituale non è praticabile.

Segnali che giustificano la revisione o il rafforzamento dei controlli

I segnali di rischio servono a dare priorità alla revisione e ad adeguare i controlli; non equivalgono da soli a un’identità o a una prova di frode. OWASP raccomanda di considerare non affidabili i dati ricevuti da client, dispositivi, reti o servizi esterni, perché possono essere mancanti, ripetuti, modificati o falsificati.

Cercare schemi di concentrazione e ripetizione: molte richieste per la stessa destinazione, attività rapida dalla stessa fonte, sequenze di reinvio senza verifica, errori persistenti del codice o volume anomalo nella stessa applicazione. Nei canali PSTN, NIST raccomanda di valutare indicatori quali cambio di dispositivo, cambio SIM, portabilità del numero o altro comportamento anomalo prima di inviare il segreto.

Il dispositivo richiede un trattamento particolarmente prudente. Può offrire un segnale utile contro abusi su larga scala, ma anche i dispositivi vengono condivisi. Non trasformare un’associazione del dispositivo in un divieto automatico di accesso per più utenti legittimi.

• Concentrazione: ripetizione su un account, un numero, una sessione o un’applicazione.
• Velocità: cadenza incompatibile con il normale utilizzo previsto del flusso.
• Schema di errore: più verifiche errate o richieste senza completamento.
• Destinazione: cambiamenti insoliti nello schema delle destinazioni all’interno di un’applicazione.
• Rischio contestuale: indicatori di cambio di dispositivo, SIM o portabilità, trattati come segnali e non come certezze.
• Qualità del segnale: dati incompleti o non affidabili devono ridurre la fiducia nella decisione, non renderla automaticamente più severa.

Cosa registrare senza conservare più dati del necessario

I log permettono di spiegare una decisione, investigare abusi e rilevare falsi positivi. OWASP raccomanda di registrare successi e fallimenti di autenticazione, tentativi di superare i limiti e attività sospette della logica di business, usando una tassonomia coerente e documentata.

Per ogni evento, conservare il contesto relativo a quando, dove, chi e cosa è accaduto: marca temporale, identificatore dell’interazione, azione, risultato, regola applicata e livello di confidenza. Usare identificatori pseudonimizzati o riferimenti protetti, quando appropriato, per account, numero, dispositivo o sessione.

Non registrare segreti OTP, password, token di accesso, valori di sessione o dati personali non necessari. Applicare mascheramento, hash, crittografia o pseudonimizzazione secondo il caso e garantire che i controlli di accesso ai log siano coerenti con la sensibilità dei dati.

• ID di interazione o transazione per correlare richiesta, invio e verifica.
• Marca temporale, azione, risultato e motivo della decisione.
• Identificatore della regola, entità limitata e stato della quota, evitando di esporre segreti.
• Riferimento pseudonimizzato alla destinazione e ad altri segnali necessari alla correlazione.
• Contesto tecnico di origine solo nella misura necessaria per sicurezza e indagine.
• Eventi di eccezione, revisione manuale e revoca per mantenere la tracciabilità.