Budget di latenza per OTP via SMS: come definire scadenza e obiettivi senza affidarsi alla media
Scopri come scomporre, misurare e governare la latenza di un OTP via SMS con percentili, segmentazione e segnali funzionali, senza confondere accettazione, DLR e utilizzo reale del codice.
Quale problema risolve un budget di latenza in un flusso OTP via SMS
Un budget di latenza OTP SMS trasforma un'aspettativa imprecisa —«il codice deve arrivare rapidamente»— in un modello operativo misurabile. La sua funzione è separare le fasi del percorso, assegnare responsabilità, scegliere segnali osservabili e decidere per quanto tempo un codice rimane valido senza basarsi su una media globale di consegna.
In un flusso di autenticazione fuori banda, il verificatore genera un segreto temporaneo, lo invia tramite un canale secondario come l'SMS e l'utente lo restituisce tramite il canale primario. Pertanto, il percorso rilevante non termina quando una piattaforma accetta la richiesta di invio né necessariamente quando arriva un rapporto di consegna: termina quando il verificatore accetta una presentazione valida dell'OTP.
Il budget serve a prendere decisioni di prodotto e operative: definire una scadenza ragionevole, stabilire quando mostrare l'opzione di reinvio, rilevare degradi per destinazione o instradamento ed evitare di attribuire alla rete mobile un ritardo che ha origine nell'applicazione o in una coda interna.
- Definisci il risultato funzionale come la convalida riuscita dell'OTP, non soltanto come l'invio del messaggio.
- Modella separatamente le fasi prima di stabilire qualsiasi obiettivo temporale.
- Misura per segmenti operativi; un valore globale può nascondere degradi concentrati.
- Mantieni la sicurezza come vincolo di progettazione: il codice deve essere temporaneo e accettato una sola volta.
Perché la latenza media non è utile per definire la scadenza di un codice
La media risponde male a una domanda di prodotto critica: quanto tempo serve alla grande maggioranza degli utenti legittimi per completare il flusso. Un insieme di consegne rapide può abbassare la media anche in presenza di una coda significativa di esperienze lente. Se la scadenza viene definita sulla base di tale media, i casi nella coda continuano a scadere anche se l'indicatore aggregato appare sano.
La scadenza non rappresenta soltanto il trasporto dell'SMS. Deve coprire il tempo dalla creazione del segreto fino al suo inserimento e alla convalida, inclusi l'elaborazione interna, la trasmissione, l'eventuale ritardo di rete, la disponibilità del terminale e il tempo necessario all'utente per leggere e inserire il codice.
NIST indica che, negli OTP basati sul tempo, la durata di validità deve considerare la deriva di clock prevista, una tolleranza per il ritardo di rete e il tempo di inserimento da parte dell'utente. Questo principio evita di progettare una scadenza sulla base di una singola misura di latenza del provider o dell'instradamento.
- Non usare la media come criterio principale per la scadenza né come unico SLO.
- Osserva percentili elevati del tempo fino alla convalida, insieme ai tassi di successo e di scadenza.
- Analizza finestre temporali comparabili, non soltanto aggregati storici.
- Distingui tra un ritardo di trasporto e una convalida tardiva causata dall'interazione dell'utente.
Definizioni operative e timestamp minimi
Prima di misurare, definisci con precisione ciascun evento e registra il relativo timestamp. Definizioni ambigue generano confronti non validi tra team, provider o destinazioni. Utilizza un identificatore di correlazione interno per il tentativo di autenticazione e un identificatore del messaggio per l'invio, mantenendo non sensibili i dati di correlazione.
Una sequenza pratica parte dalla creazione dell'OTP e dalla sua associazione con la transazione di autenticazione. Registra poi la richiesta al canale di invio, l'accettazione della richiesta tramite API o SMPP, gli eventi disponibili di accodamento e invio, qualsiasi DLR ricevuto e, infine, la convalida riuscita o fallita del codice.
L'accettazione tramite API o SMPP attesta soltanto che il provider ha ricevuto correttamente il comando o la richiesta. Non attesta che l'SMS sia arrivato al dispositivo. Allo stesso modo, un DLR è un segnale asincrono il cui significato dipende dal rapporto ricevuto e dalla catena di consegna; deve essere conservato come evidenza operativa, senza trattarlo come prova di lettura né come orologio definitivo della consegna.
- t0: creazione dell'OTP e apertura del suo periodo di validità.
- t1: richiesta di invio emessa dall'applicazione.
- t2: accettazione tramite API o SMPP e assegnazione dell'identificatore del messaggio, se presente.
- t3: eventi di invio o di modifica dello stato disponibili nella piattaforma.
- t4: ricezione del DLR e, quando disponibili, timestamp e tentativi contenuti nel rapporto stesso.
- t5: presentazione e convalida riuscita dell'OTP, oppure registrazione di scadenza, errore o abbandono.
Quali parti controlla ciascun soggetto
Il mittente controlla la progettazione dell'esperienza, la generazione del codice, la creazione della richiesta, il comportamento dell'applicazione, le proprie code, le regole di scadenza, i limiti di tentativo e la strumentazione. Può inoltre scegliere la connettività disponibile, definire politiche per destinazione e intervenire sugli instradamenti secondo i propri accordi e controlli operativi.
Il provider di messaggistica e gli intermediari controllano parti dell'accettazione, del trattamento e della consegna verso le reti connesse, in base all'architettura e agli accordi applicabili. La rete mobile controlla elementi dell'instradamento e della consegna riportata nel proprio dominio. Il terminale, la copertura disponibile, lo stato del dispositivo e il comportamento dell'utente restano fuori dal controllo diretto del mittente.
Questa separazione deve riflettersi nella diagnosi. Se aumenta il tempo tra creazione e accettazione, indaga prima sull'applicazione o sulla connettività in uscita. Se l'accettazione rimane stabile ma cambia la distribuzione di DLR o convalide per una destinazione, analizza il segmento interessato senza concludere che un singolo evento dimostri la causa.
- Applicazione: generazione, archiviazione sicura, scadenza, interfaccia utente, richiesta e convalida.
- Connettività di invio: accettazione, risposta tecnica e identificatori del messaggio.
- Instradamento e rete mobile: trattamento della consegna e segnali di stato eventualmente riportati.
- Terminale e utente: disponibilità effettiva del codice, lettura e inserimento.
- Verificatore: decisione finale di accettare o rifiutare l'OTP presentato.
Come costruire un budget di latenza per fasi
Costruisci il budget a partire dal risultato che conta: una convalida valida prima della scadenza. Inizia raccogliendo eventi provenienti da tentativi reali di autenticazione, con correlazione tra tentativo, messaggio e risultato della verifica. Escludi dalla definizione gli eventi che non possono essere collegati in modo affidabile, ma quantifica tale mancanza di correlazione come limite di osservabilità.
Calcola le distribuzioni per ciascun intervallo: da creazione a richiesta, da richiesta ad accettazione, da accettazione a qualsiasi segnale successivo disponibile e da creazione a convalida riuscita. Mantieni separati i tentativi convalidati, scaduti, abbandonati, falliti e quelli in cui il codice era errato. Mescolarli in un'unica serie nasconde problemi di sicurezza, UX e consegna.
Il budget finale non è una promessa che tutti i messaggi verranno completati entro un tempo fisso. È una politica: una finestra di validità accompagnata da limiti di reinvio, controlli sui tentativi, alternative di autenticazione quando appropriate e soglie operative per segmento.
- 1. Definisci l'evento di inizio: normalmente la creazione dell'OTP.
- 2. Definisci l'evento funzionale finale: convalida riuscita da parte del verificatore.
- 3. Registra gli intervalli intermedi con timestamp distinguibili.
- 4. Classifica l'esito di tutti i tentativi.
- 5. Calcola i percentili per segmento e finestra temporale.
- 6. Definisci la scadenza considerando trasporto, interazione umana e requisiti di sicurezza.
- 7. Rivedi la politica dopo modifiche a instradamento, prodotto, connettività o comportamento del traffico.
Percentili, finestre temporali e segmentazione per destinazione
Usa i percentili per descrivere la distribuzione, non soltanto un punto centrale. I percentili dei tempi fino alla convalida aiutano a osservare l'esperienza della parte più lenta degli utenti che completano il flusso. Devono essere letti insieme alla proporzione di tentativi che scadono, al tasso di convalida e al volume, perché un percentile calcolato su poche osservazioni può essere instabile.
Segmenta almeno per destinazione. Quando dati e volume lo consentono, aggiungi dimensioni utili per l'operatività: instradamento, mittente, tipo di numero, tipo di traffico, versione dell'applicazione o politica di rischio. Non mescolare segmenti con comportamenti diversi per poi aspettarti che un'unica soglia globale spieghi la causa di una deviazione.
Confronta ciascun segmento con la propria baseline in finestre temporali coerenti. Una finestra troppo breve reagisce al rumore; una eccessivamente lunga può ritardare il rilevamento. Stabilisci inoltre un volume minimo di osservazioni prima di prendere decisioni automatizzate o attivare un avviso.
- Misura il tempo dalla creazione alla convalida come metrica funzionale principale.
- Misura da creazione ad accettazione per isolare ritardi interni o di connettività.
- Conserva i DLR e i relativi timestamp come telemetria complementare, non come sostituto della convalida.
- Analizza percentuale di scadenze, reinvii, tentativi falliti e convalide riuscite insieme ai tempi.
- Richiedi un volume sufficiente prima di confrontare percentili tra segmenti.
Scadenza, reinvio, limiti di richiesta e prevenzione dei duplicati
La finestra di scadenza deve essere sufficientemente ampia da coprire l'esperienza legittima prevista, ma non deve trasformarsi in una sostituzione dei controlli di sicurezza. Per l'autenticazione fuori banda coperta da NIST, la transazione deve essere completata entro 10 minuti e un determinato segreto può essere accettato una sola volta durante il suo periodo di validità. Applica sempre i requisiti normativi, contrattuali e di rischio pertinenti al tuo caso d'uso.
Il reinvio non deve creare una tempesta di messaggi né ampliare indefinitamente la superficie di attacco. Prima di emettere un altro SMS, verifica se esiste un OTP valido associato alla stessa transazione e decidi esplicitamente se riutilizzarlo, invalidarlo e sostituirlo oppure limitare la richiesta. La politica deve essere coerente affinché non esistano più codici attivi ambigui senza una regola di convalida chiara.
Per i segreti brevi, limita efficacemente i tentativi falliti consecutivi. L'emissione di un nuovo segreto non deve azzerare il contatore degli errori. Puoi utilizzare attese progressive e segnali di rischio per irrigidire il flusso quando emergono schemi anomali, mantenendo alternative di autenticazione quando rischio, copertura o accessibilità lo richiedono.
- Mantieni un unico stato autorevole per ogni transazione di autenticazione.
- Rendi ogni OTP monouso.
- Definisci una politica esplicita su cosa accade all'OTP precedente dopo un reinvio.
- Limita le richieste di reinvio per account, sessione, destinazione e segnali di rischio pertinenti.
- Non azzerare i limiti dei tentativi falliti quando viene emesso un nuovo codice.
- Offri alternative di autenticazione quando SMS/PSTN non è adatto o non è disponibile.
Cosa può indicare un DLR e cosa non può dimostrare
Un DLR può fornire informazioni operative utili: stato riportato, tentativi di consegna e, in base all'interfaccia, timestamp del tentativo e della ricezione del rapporto. È utile per indagare le tendenze e per distinguere una risposta tecnica iniziale da uno stato di consegna comunicato in seguito.
Tuttavia, il DLR non dimostra da solo che l'utente abbia letto, compreso o inserito il codice. Non deve neppure essere utilizzato come orologio per decidere immediatamente che esiste un ritardo di consegna. Le ricevute o gli eventi generati dagli operatori possono arrivare in ritardo; la documentazione AWS avverte che possono essere ricevuti fino a 72 ore dopo e che non devono essere usati per determinare un ritardo di consegna in uscita.
La convalida riuscita dell'OTP è un segnale funzionale più forte: dimostra che il codice è diventato disponibile per l'utente ed è stato presentato al verificatore. Ciò non rende tuttavia irrilevante il DLR; entrambi i segnali rispondono a domande diverse e devono essere mantenuti separati.
- Accettazione dell'invio: il comando o la richiesta è stato ricevuto correttamente.
- DLR: risultato di consegna riportato in modo asincrono, con incertezza su tempistica e portata.
- Convalida riuscita: evidenza funzionale che il codice è stato presentato correttamente al verificatore.
- Assenza di DLR: non deve essere interpretata automaticamente come assenza di consegna.
- DLR Delivered: non dimostra la lettura né il corretto inserimento del codice.
Domande frequenti
Quale metrica dovrebbe guidare la scadenza di un OTP via SMS?
Il riferimento più utile è la distribuzione del tempo dalla creazione dell'OTP alla sua convalida riuscita, segmentata per destinazione e per altre dimensioni operative rilevanti. Va integrata con tassi di scadenza, reinvio e fallimento, non con una media isolata di consegna.
L'accettazione tramite API o SMPP significa che l'SMS è arrivato al telefono?
No. Indica che il comando o la richiesta è stato ricevuto correttamente dal sistema che lo accetta. Non dimostra la ricezione sul dispositivo di destinazione.
Un DLR Delivered dimostra che l'utente ha ricevuto e letto l'OTP?
No. Un DLR rappresenta un risultato di consegna riportato e può essere utile come segnale operativo, ma non dimostra lettura, comprensione né inserimento del codice. La convalida riuscita è il segnale funzionale più forte.
Quanto dovrebbe durare un OTP inviato via SMS?
Non esiste una durata universale deducibile da una media di consegna. Definiscila in base alla distribuzione dei tempi fino alla convalida, al tempo di interazione previsto, al rischio e ai requisiti applicabili. Per l'autenticazione fuori banda coperta da NIST, la transazione deve essere completata entro 10 minuti.
È necessario generare un nuovo codice ogni volta che l'utente richiede un reinvio?
Deve esistere una politica esplicita. Se viene generato un nuovo codice, definisci cosa accade al precedente per evitare ambiguità e non azzerare i controlli sui tentativi falliti. È inoltre opportuno limitare le richieste di reinvio e applicare attese o misure adattive quando necessario.
Come rilevare il degrado di un instradamento OTP?
Confronta i percentili del tempo fino alla convalida, i tassi di scadenza, i reinvii e i segnali di consegna con una baseline propria, segmentando per destinazione, instradamento, mittente o altre dimensioni disponibili. Richiedi volume sufficiente e una deviazione sostenuta prima di attribuire un picco isolato a un problema di instradamento.
Fonti consultate
- NIST SP 800-63B: autenticación fuera de banda y secretos temporalesNational Institute of Standards and Technology (NIST)
- AWS End User Messaging SMS User Guide: eventos, DLR y feedback de mensajesAmazon Web Services (AWS)
- Azure Communication Services SMS Delivery Reports APIMicrosoft
- Azure Communication Services: eventos SMSMicrosoft
- OWASP Authentication Cheat SheetOWASP Foundation