Consegna degli SMS OTP e frodi

Dove si verificano le fughe delle password monouso, che cosa una ricevuta di consegna può e non può dire, e i controlli e le metriche che mantengono funzionante un flusso OTP.

practitioner · 4 min di lettura · Lezione 5 / 8

Una password monouso dimostra il controllo di un numero nel momento in cui viene inserita. Non dimostra l’identità, e una ricevuta di consegna non dimostra che una persona l’abbia letta. La consegna, l’intercettazione, il riciclo dei numeri e il modulo stesso determinano se la verifica regge.

Dati essenziali

  • Un OTP dimostra il controllo di un numero in quel momento, non l’identità.
  • Una ricevuta di consegna riporta uno stato della rete, non il fatto che una persona abbia letto il codice.
  • Il riciclo dei numeri, il SIM swap, l’inoltro e il phishing sono le principali vie di fuga di un codice.
  • I limiti di frequenza, la registrazione del mittente e le verifiche sul numero riducono gli abusi; nessuno di essi dimostra l’identità.

Che cosa dimostra un OTP

Un OTP risponde a una sola domanda: la persona che si ha davanti può ricevere ora un messaggio su questo numero? È utile per il recupero dell’account e per l’accesso, perché lega la sessione a qualcosa che l’utente controlla. Non è un documento di identità. Il numero può essere riciclato, spostato su una nuova SIM, inoltrato o letto da un’altra persona del nucleo familiare.

La distinzione conta in fase di progettazione. Se l’azione ha un valore basso, un OTP è proporzionato. Se l’azione sposta denaro, cambia una password o aggiunge un beneficiario, abbinare il codice a una seconda verifica: un ritardo, una conferma in una sessione già esistente, una richiamata su un canale noto o una revisione manuale. Il codice è un fattore, non l’intera decisione.

Il percorso e i punti in cui un codice può sfuggire

  1. Applicazione
  2. Gateway SMPP
  3. SMSC
  4. HLR / HSS
  5. MSC / MME
  6. Telefono
  7. Ricevuta di consegna
La stessa catena che consegna il codice crea anche i punti in cui può essere osservato, ritardato o inviato al terminale sbagliato. Fonte: 3GPP TS 23.040: architettura SMS
Descrizione testuale

L’applicazione invia il codice a un gateway, il centro messaggi individua l’abbonato e la centrale di servizio consegna al terminale. Una ricevuta torna lungo la stessa catena. Un codice può sfuggire nell’applicazione, nel terminale, attraverso il numero stesso o tramite la persona che lo riceve. Il percorso di rete spiega la consegna; non spiega la persona che condivide il codice.

Dove sfugge un OTP

Un SIM swap sposta il numero su una nuova scheda. L’attaccante convince un punto vendita o un servizio di assistenza di essere il titolare, e il codice successivo arriva alla nuova SIM. Il riciclo dei numeri ha lo stesso effetto senza alcun attaccante: un operatore riassegna un numero inattivo e il nuovo titolare riceve un codice destinato al vecchio account. In entrambi i casi conviene verificare se un numero è stato portato o riassegnato di recente.

L’inoltro e la trascrizione della segreteria in testo inviano il messaggio a un’altra casella. Il phishing copia il modulo e raccoglie direttamente il codice, quindi la rete non vede mai un attacco. L’intercettazione sul percorso di rete è più rara ed è fuori dal controllo dell’applicazione; la risposta pratica è un secondo fattore, non un codice più lungo. Per le definizioni, consultare la voce del glossario OTP.

I controlli utili

Limitare la frequenza con cui un numero, un indirizzo IP e un dispositivo possono richiedere un codice. Usare una validità breve, un solo utilizzo per codice e legare il codice alla sessione che lo ha richiesto. Registrare il mittente e mantenere il contenuto semplice: un codice che sembra un messaggio di marketing può essere filtrato, e un codice filtrato genera un ticket di assistenza, non un accesso.

Verificare il numero prima di fidarsene. Un numero che non può ricevere SMS, che è stato portato di recente o che ha uno storico di reimpostazioni merita un passaggio aggiuntivo. Per le azioni di valore elevato, richiedere una sessione già esistente o un secondo canale. Registrare la richiesta, l’invio, la ricevuta e l’inserimento del codice come eventi distinti, in modo da distinguere un problema di consegna da un problema dell’utente.

Progettare il codice stesso con la stessa cura. Generarlo da una fonte crittografica, memorizzarne un hash, farlo scadere in pochi minuti, consentire un solo utilizzo riuscito e limitare i tentativi per codice e per sessione. Non rivelare se il numero esiste. Creare il record dell’account prima dell’invio, in modo che un nuovo tentativo non possa aprire un account che non viene mai completato.

Cinque metriche, con le definizioni

Ogni metrica risponde a una domanda diversa. Nessuna di esse misura l’identità.
MetricaDefinizioneChe cosa indica
Tasso di consegnaRicevute con stato consegnato divise per i messaggi inviatiSe la rete ha accettato il messaggio; non se una persona lo ha letto
Tasso di completamentoCodici inseriti divisi per i messaggi consegnatiSe il messaggio e il modulo hanno funzionato per l’utente
Tempo di consegnaMediana e 95° percentile dall’invio alla ricevutaSe la rotta è lenta e quanto attende un utente prima di richiedere un nuovo invio
Tasso di reinvioReinvii divisi per i messaggi consegnatiSe gli utenti attendono troppo, digitano male o non vedono mai il primo messaggio
Tasso di bloccoRichieste respinte dalle regole di rischio divise per i tentativiSe le regole sono troppo restrittive, troppo permissive o il traffico è abusivo

Tenerne traccia per mercato, mittente e rotta. Un’unica media globale nasconde la rotta che non funziona.

Misurare il flusso, non l’invio

Un invio che restituisce un ID messaggio non è un codice consegnato. Un codice consegnato non è un accesso completato. Costruire il funnel a partire dagli eventi che si controllano: invio, ricevuta, inserimento del codice, esito positivo. Poi confrontarlo con la visione del fornitore. Uno scarto tra il proprio tasso di consegna e quello del fornitore può essere una ricevuta che non ha mai raggiunto il proprio endpoint di ricezione, non un messaggio che non ha mai raggiunto il terminale.

Rivedere il flusso quando una metrica si muove. Un calo del completamento con un tasso di consegna stabile indica il modulo, la scadenza del codice o il mittente. Un calo della consegna con un tasso di invio stabile indica la rotta, il numero o il filtro dei contenuti. Un aumento dei reinvii indica il tempo di consegna. Correggere il passaggio indicato dai dati, non quello più facile da modificare.

Fissare una data di revisione per l’intero flusso. I numeri cambiano titolare, le rotte cambiano e i modelli invecchiano. Un flusso che funzionava al lancio può smettere di funzionare senza segnali sei mesi dopo, con lo stesso codice e lo stesso fornitore.

Verifichi ciò che ha imparato

  1. Un utente inoltra il codice a un amico. Il codice dimostra ancora l’identità?

    No. Dimostra che il numero poteva ricevere il codice in quel momento. Chiunque abbia il codice può usarlo.

  2. Una ricevuta indica consegnato, ma l’utente non vede mai il codice. Che cosa si verifica?

    Lo stato del terminale, l’app di messaggistica e il filtro antispam, il mittente e la rotta. Una ricevuta di consegna riporta lo stato della rete, non ciò che mostra il terminale.

  3. Perché il tasso di completamento è più utile del tasso di consegna?

    La consegna si ferma alla rete. Il completamento include l’utente, la scadenza del codice e il modulo, che è dove si manifesta la maggior parte dei problemi.

Le risposte vengono mostrate su richiesta. Nulla viene valutato, salvato o inviato.

Domande frequenti

Un OTP equivale all’autenticazione a due fattori?

Un OTP può essere il secondo fattore. Da solo è un unico fattore: il possesso del numero in quel momento.

I codici più lunghi sono più sicuri?

La lunghezza aiuta contro i tentativi di indovinare il codice, ma non ferma un SIM swap, l’inoltro o il phishing. Aggiungere una seconda verifica per le azioni di valore elevato.

Una ricevuta di consegna può dimostrare che l’utente ha letto il codice?

No. Riporta uno stato della rete, come consegnato, scaduto o non consegnato. Non dice nulla sulla lettura o sulla digitazione.

Conviene reinviare automaticamente?

Reinviare su azione dell’utente, non a tempo. I reinvii automatici moltiplicano i costi e possono mascherare un problema di rotta.

Che cosa conviene registrare?

La richiesta, l’invio con il relativo ID messaggio, la ricevuta con il relativo stato e l’esito dell’inserimento del codice. Conservarli come eventi distinti con marca temporale.

Le ricevute indicano consegnato, ma gli utenti non ricevono nulla. Che cosa verificare prima di cambiare fornitore?

Prima il proprio lato, perché una ricevuta di consegna indica che la rete ha accettato il messaggio, non ciò che ha mostrato il terminale. Passare il modello nel controllo preliminare dei contenuti SMS, contarne i segmenti con il contatore di segmenti SMS e leggere i codici di invio e di ricevuta con il decodificatore di codici SMPP e DLR. Se risultano in ordine, testare la destinazione che non funziona sui propri terminali prima di spostare il traffico, una destinazione alla volta.
  • Connessione via SMPP e HTTP

    Portare una rotta di test in produzione senza compromettere bind, finestre o ricevute: bind, throughput, keep-alive, codifica, callback e gestione degli errori.

  • Pacchetto di modelli RFQ e RFP

    Elenchi dei campi per le richieste di SMS all’ingrosso, eSIM e dati, IoT e connettività verso la Cina, più la checklist online che si invia come RFQ.

  • Report di esempio di test della rotta

    Un esempio statico e privo di dati sensibili di report di test della rotta: che cosa verifica un test della rotta, come si leggono i fallimenti e che cosa attiva una revisione della rotta.

Metterlo in pratica

Ci indichi il traffico, la destinazione e la misurazione di cui ha bisogno; le risponderemo con il passo successivo.