Finestre di soppressione degli OTP via SMS: come ridurre i reinvii duplicati senza bloccare gli utenti legittimi

Il problema operativo: i reinvii non sono una semplice funzione UX

Quando una persona richiede più volte un codice OTP via SMS, il sistema può generare codici simultanei, aumentare il costo della messaggistica, creare confusione su quale codice inserire e ampliare la superficie di abuso. Può inoltre aumentare i contatti con l'assistenza se l'utente riceve messaggi in ritardo o se un codice precedente smette di funzionare senza una spiegazione chiara.

Tuttavia, sopprimere rigidamente ogni richiesta ripetuta può anche impedire un'autenticazione legittima. Il ritardo può trovarsi nella rete, nel fornitore di messaggistica, nel terminale o nella connettività dell'utente. Inoltre, alcuni utenti non possono fare sempre affidamento sulla copertura mobile e devono disporre di metodi di autenticazione alternativi autorizzati.

La finestra di soppressione degli OTP via SMS è un controllo operativo che decide se una nuova richiesta debba essere accettata, ritardata oppure non debba generare un altro SMS. Non sostituisce i controlli di sicurezza dell'OTP: deve operare insieme alla validità limitata del segreto, all'accettazione monouso, alla limitazione dei tentativi di verifica e alla valutazione del rischio.

• Obiettivo di sicurezza: limitare l'abuso delle richieste e dei tentativi di verifica.
• Obiettivo operativo: evitare messaggi duplicati e stati incoerenti.
• Obiettivo di esperienza: comunicare l'attesa senza rivelare se esiste un account o un numero.
• Obiettivo di accessibilità: offrire metodi alternativi quando l'SMS non è utilizzabile.

Cosa governa una finestra di soppressione

Una finestra di soppressione non dovrebbe rispondere soltanto alla domanda «quanto tempo è passato dall'ultimo clic?». Deve governare una decisione completa: se creare una nuova richiesta, se riutilizzare una richiesta valida, se posticipare l'invio, se annullare un tentativo in sospeso o se indirizzare l'utente a un'alternativa autorizzata.

La decisione deve essere deterministica sul server. L'interfaccia può mostrare un conto alla rovescia, ma non deve essere l'autorità su quando sia consentito un reinvio. Il server conserva lo stato della richiesta, valuta limiti e rischio, emette il codice e decide quale segreto possa essere verificato.

È opportuno definire esplicitamente il comportamento dei codici precedenti. Una politica frequente consiste nell'invalidare i codici precedenti quando ne viene emesso uno nuovo per la stessa finalità e richiesta di autenticazione. Se si adotta questa politica, deve essere comunicata all'utente e applicata in modo atomico per evitare che due codici restino validi a causa di una condizione di concorrenza.

• Consentire: non esiste una richiesta valida che debba essere soppressa e i limiti consentono l'invio.
• Ritardare: la richiesta è legittima, ma il periodo di attesa per il reinvio è ancora attivo.
• Sopprimere: viene rilevata una duplicazione, è già in corso un'operazione equivalente oppure viene superata una restrizione applicabile.
• Escalare o cambiare canale: il rischio, l'accessibilità o un guasto tecnico confermato giustificano un percorso alternativo autorizzato.

Separare i tre timer essenziali

La validità del codice, il periodo di attesa per il reinvio e la scadenza della richiesta sono timer distinti. Confonderli produce spesso due errori: mantenere un codice accettabile più a lungo del necessario oppure negare un reinvio legittimo perché si confonde il tempo di attesa con la validità crittografica.

La validità del codice definisce fino a quando il verificatore può accettare il segreto. NIST stabilisce che l'autenticazione fuori banda deve essere completata entro 10 minuti e che lo stesso segreto deve essere accettato una sola volta durante il suo periodo di validità. Un'implementazione può scegliere una validità più breve se la propria analisi del rischio e l'esperienza utente lo giustificano.

Il periodo di attesa per il reinvio definisce quanto una persona debba attendere prima di richiedere un altro SMS. È una decisione operativa distinta: deve ridurre i clic ripetuti e il traffico duplicato, senza essere trattata come prova che il primo SMS non arriverà. La scadenza della richiesta determina quando la transazione di autenticazione viene chiusa e richiede l'avvio di un nuovo flusso.

• Validità del codice: controlla l'accettazione del segreto e la sua resistenza alla ripetizione.
• Periodo di attesa per il reinvio: controlla la frequenza dei nuovi invii.
• Scadenza della richiesta: chiude il contesto transazionale ed evita stati indefiniti.
• Limite dei tentativi di verifica: controlla i tentativi falliti e non deve essere reimpostato con l'emissione di un altro codice.

Modello di stati per una richiesta OTP

Modellate la richiesta OTP come una transazione interna con un identificatore univoco. Gli stati del fornitore di messaggistica devono essere associati a questa transazione, ma non devono controllare da soli la validità del codice né il risultato dell'autenticazione.

Un modello minimo può includere creata, accettata, inviata, stato finale comunicato, verificata, scaduta e annullata. Lo stato «stato finale comunicato» rappresenta la ricezione di un aggiornamento terminale dal sistema di messaggistica, ma non afferma che l'utente abbia visto, letto o utilizzato l'SMS.

Le transizioni devono essere controllate dal server e idempotenti. Per esempio, una verifica corretta deve chiudere la possibilità di riutilizzare il segreto, anche se in seguito arriva un callback di consegna ritardato. Allo stesso modo, un aggiornamento esterno fuori ordine non deve riaprire una richiesta scaduta, annullata o già verificata.

• Creata: esiste il contesto di autenticazione, ma l'invio non è ancora stato accettato.
• Accettata: le convalide interne sono state superate ed è stato deciso di avviare l'invio.
• Inviata: il sistema ha registrato l'emissione verso la connettività di messaggistica.
• Stato finale comunicato: è stato ricevuto uno stato terminale esterno, la cui semantica deve essere conservata senza sovrainterpretarla.
• Verificata: il segreto valido è stato restituito e accettato una sola volta.
• Scaduta o annullata: la richiesta non può più produrre un'autenticazione corretta.

Prove per decidere un reinvio e limiti dei DLR

La prova più solida per l'autenticazione è la verifica riuscita del segreto entro il suo periodo di validità. Un evento di trasporto non sostituisce la risposta esplicita dell'utente né prova che il codice sia stato ricevuto, letto o inserito nel terminale.

Per decidere un reinvio, ordinate le prove in base alla loro funzione. Gli eventi interni indicano se esiste già una richiesta attiva, se un codice è ancora valido, se vi è stata una verifica o se sono stati raggiunti i limiti. La risposta di invio consente di sapere se il sistema di messaggistica ha accettato o rifiutato l'operazione secondo la propria interfaccia. I DLR possono fornire informazioni sullo stato di consegna riportato, ma la loro interpretazione dipende dalla semantica disponibile nella catena di messaggistica.

Un DLR segnalato come consegnato non deve essere trattato come conferma indipendente di ricezione fisica, lettura o possesso legittimo del terminale. Un DLR in sospeso non prova neppure un guasto. La politica di soppressione deve evitare sia il reinvio immediato per assenza di DLR sia il blocco automatico dovuto alla presenza di un DLR consegnato.

• Usate lo stato interno per mantenere l'autorità della decisione.
• Conservate la risposta di invio e il relativo identificatore di correlazione.
• Memorizzate il DLR originale, il momento della sua ricezione e il suo collegamento con il messaggio.
• Non trasformate un DLR in prova di lettura, identità, consenso o successo dell'autenticazione.
• Convalidate l'OTP sul server anche se è stata segnalata una consegna.

Regole pratiche per scenario

Nella prima richiesta, convalidate e normalizzate la destinazione secondo il quadro internazionale di numerazione applicabile, create la transazione, generate il segreto di breve durata e registrate l'evento prima di avviare l'invio. Il risultato deve essere associato a identificatori di richiesta, codice e messaggio senza registrare il segreto in testo semplice.

In caso di reinvio anticipato, se esiste una richiesta attiva e il periodo di attesa non è terminato, non generate automaticamente un altro codice. Restituite una risposta generica che indichi l'attesa applicabile e mantenete la possibilità di inserire il codice attuale. Se il reinvio è consentito al termine dell'attesa, applicate in modo atomico la politica scelta per il codice precedente.

Quando il codice è scaduto, chiudete la richiesta precedente e createne una nuova solo se i limiti e i segnali di rischio lo consentono. Se la piattaforma conferma un guasto tecnico prima che l'invio sia stato accettato, può essere definita un'eccezione di nuovo tentativo; tale eccezione deve essere tracciata e non deve trasformarsi in un meccanismo illimitato di generazione.

In caso di cambio di canale, non presumete che l'SMS sia adatto a tutti i casi. L'uso del PSTN per l'autenticazione fuori banda comporta rischi che devono essere valutati. Considerate i segnali di rischio disponibili, come cambi di dispositivo, SIM o portabilità, e indirizzate verso un autenticatore alternativo autorizzato quando la politica lo richiede.

• Prima richiesta: creare il contesto, registrare, inviare e attivare i timer.
• Reinvio durante l'attesa: mantenere valido il codice e mostrare il tempo di attesa.
• Codice scaduto: chiudere il contesto precedente prima di emetterne uno nuovo.
• Guasto tecnico confermato: applicare un'eccezione limitata, idempotente e verificabile.
• Cambio di canale: preservare il contesto di rischio e non indebolire i controlli di verifica.

DLR in sospeso, rifiutati o consegnati: trattamento prudente

Un DLR in sospeso indica che per quell'operazione non è ancora disponibile un aggiornamento terminale. Non è un motivo sufficiente per emettere immediatamente un altro SMS. Mantenete la finestra di attesa e consentite all'utente di inserire il codice finché resta valido.

Un rifiuto o un guasto segnalato può giustificare una politica di nuovo tentativo controllato se viene confermato che l'invio non è stato accettato o non è avanzato secondo i criteri interni definiti. Anche in questo caso, il nuovo tentativo deve essere soggetto a limiti e a una chiave di idempotenza affinché i ritentativi di rete non creino messaggi multipli.

Se viene segnalata la consegna, mantenete la regola di non equivalenza: il sistema può registrare quello stato per l'analisi operativa, ma non deve bloccare ogni alternativa né concludere che l'utente disponga già del codice. L'autenticazione si completa soltanto quando il verificatore accetta il segreto valido restituito dalla persona.

• In sospeso: attendere, conservare la richiesta e non inferire un guasto.
• Rifiutato: verificare il significato tecnico dell'evento prima di ritentare.
• Consegnato: registrare come segnale di trasporto, non come lettura né autenticazione.
• Fuori ordine: conservare l'evento per la diagnosi senza far retrocedere lo stato interno.
• Duplicato: accettare il callback in modo idempotente ed evitare effetti ripetuti.

Controlli antiabuso senza bloccare gli utenti legittimi

La soppressione dei reinvii deve combinarsi con limiti di richiesta e limiti di verifica. Gli OTP brevi richiedono di limitare i tentativi di verifica falliti per ridurre l'indovinamento online. L'emissione di un nuovo codice non deve reimpostare questo contatore di errori.

Non basate il controllo soltanto su un indirizzo IP. OWASP raccomanda di associare i contatori degli errori all'account e di usare IP, dispositivo, posizione, ora e comportamento come segnali complementari. Per le richieste OTP, il numero di destinazione, l'account, la sessione e il dispositivo possono fornire contesti diversi; nessuno di essi deve essere considerato di per sé una prova di identità.

Applicate misure graduali invece di un'unica risposta binaria. NIST contempla attese crescenti, rilevamento dei bot e valutazione adattiva come tecniche che possono integrare la limitazione. Esaminate i falsi positivi: viaggi, reti condivise, dispositivi nuovi, copertura limitata e necessità di accessibilità possono spiegare comportamenti legittimi.

• Limiti per account: proteggono il flusso di autenticazione associato.
• Limiti per numero: riducono la pressione di invio verso una destinazione specifica.
• Limiti per sessione e dispositivo: aiutano a rilevare ripetizioni automatizzate nello stesso contesto.
• IP e altri segnali: forniscono contesto, ma non devono essere l'unico criterio.
• Escalation graduale: attesa, verifica aggiuntiva, alternativa autorizzata o revisione, in base al rischio.