- L'utente richiede un codiceAccesso, pagamento o registrazione
- La tua app chiama l’API di verificaUna richiesta per codice
- BroadNet consegna il codiceSul miglior canale disponibileFallback in caso di mancata consegnaSMSWhatsAppVoce
- L'utente inserisce il codiceVerifica rispetto al codice emesso
- VerificatoAccesso consentito
Cos'è un OTP
Una password monouso (OTP) è un codice valido per un singolo accesso o transazione. È il secondo fattore nell'autenticazione a due fattori: qualcosa che l'utente riceve, dimostrando il controllo di un numero di telefono o di un autenticatore, in aggiunta a una password che conosce.
Gli OTP sono i messaggi più critici che la maggior parte delle aziende invia. Un codice in ritardo o mancante equivale a un accesso fallito, una registrazione abbandonata o una vendita persa, quindi il traffico OTP viene trattato come una classe distinta, con budget di latenza rigorosi e finestre di validità brevi.
La verifica del numero è il compito correlato di dimostrare che un utente controlla effettivamente un dato numero di telefono — il fondamento della sicurezza dell'account, della riduzione delle frodi e di dati di contatto puliti.
Come vengono generati i codici: HOTP e TOTP
L'HOTP (RFC 4226) genera un codice a partire da un segreto condiviso e un contatore usando HMAC. Ogni utilizzo incrementa il contatore, così i codici non si ripetono. È alla base dei token basati su eventi.
Il TOTP (RFC 6238) sostituisce il contatore con l'ora corrente suddivisa in intervalli fissi (comunemente 30 secondi), così che entrambe le parti derivino lo stesso codice dallo stesso segreto e dallo stesso orologio. È ciò che usano le app di autenticazione, e funziona offline perché non serve consegnare alcun messaggio.
Per gli OTP consegnati via SMS, il codice è solitamente un breve valore numerico casuale generato lato server, associato alla sessione o al dispositivo, e scaduto dopo il primo utilizzo o un timeout. Sei cifre sono il valore predefinito comune, che bilancia usabilità e resistenza al tentativo casuale.
Canali di consegna e fallback
L'SMS è il canale OTP predefinito grazie alla sua portata universale, ma non è l'unico. La voce OTP legge il codice ad alta voce e aiuta in mercati con scarsa capacità di consegna via SMS o per l'accessibilità. WhatsApp e RCS possono consegnare i codici in modo ricco dove l'utente è raggiungibile.
La verifica tramite flash call è un'alternativa efficiente in termini di costo: la piattaforma effettua una chiamata che l'app rileva ed elimina automaticamente, verificando il numero dalle ultime cifre del numero chiamante senza che l'utente risponda. Elimina del tutto il costo dell'SMS e l'inserimento manuale del codice.
Una cascata (waterfall) di canali combina questi elementi: prova il canale uno, e se la consegna non è confermata entro pochi secondi, passa al successivo. La cascata deve avere tempi definiti e deve evitare di inviare lo stesso codice su due canali contemporaneamente, il che raddoppia costo ed esposizione alla frode.
Autocompilazione, progettazione del messaggio e latenza
I messaggi OTP ben progettati convertono meglio. Mantenga il corpo minimo, riconoscibile per il brand e coerente, così da superare i filtri sui contenuti, e supporti le convenzioni di autocompilazione della piattaforma — come il formato del codice monouso legato all'origine sull'ultima riga — così che il codice venga inserito automaticamente.
Non inserisca mai il codice all'interno di un link cliccabile che potrebbe essere oggetto di phishing; lo mantenga solo copiabile o digitabile. Localizzi il testo circostante mantenendo stabili il codice e il token del brand, così che l'autocompilazione e il riconoscimento da parte dell'utente continuino a funzionare.
Misuri la latenza end-to-end fino al telefono (dall'invio al DLR), non solo il tempo di accettazione dell'invio, e imposti un periodo di validità breve così che un codice ritardato scada invece di arrivare non più valido. Attivi il fallback in caso di DLR mancante entro il suo budget di latenza, non solo in caso di errore esplicito.
Difendersi dall'AIT / SMS pumping
Il traffico gonfiato artificialmente (AIT), detto anche SMS pumping, è una frode in cui gli aggressori attivano invii OTP apparentemente genuini verso numeri che controllano, gonfiando la sua fattura senza che vi sia un vero utente. È l'area a più alto ritorno sull'investimento da difendere per la maggior parte dei mittenti.
I controlli principali sono i limiti di frequenza — per numero di telefono, per IP, per impronta del dispositivo, per account — oltre a un limite massimo di reinvii per sessione e a un attrito aggiuntivo (una sfida o un CAPTCHA) quando la velocità aumenta bruscamente da un'unica fonte.
Osservi il tasso di conversione per destinazione: il traffico gonfiato mostra un'ondata di richieste con inserimento del codice quasi nullo, e un picco improvviso verso un intervallo di paesi insolito è la firma classica. Validare i numeri con una ricerca HLR / di number intelligence prima dell'invio respinge in anticipo numeri non validi e ad alto rischio.
- Gli OTP sono una classe di traffico distinta e sensibile alla latenza; l'HOTP è basato su contatore e il TOTP (RFC 6238) è basato sul tempo.
- I canali includono SMS, voce, WhatsApp/RCS e flash call; li combini in una cascata di fallback con tempi definiti.
- Supporti l'autocompilazione, tenga i codici fuori dai link, usi una validità breve e misuri la latenza di consegna end-to-end.
- L'AIT / SMS pumping si difende con limiti di frequenza, limiti sui reinvii, monitoraggio della conversione e controlli sul numero prima dell'invio.