Login passwordless con OTP: il problema della sicurezza e dell’usabilità

Che cos’è il login passwordless con OTP

Un’autenticazione passwordless non significa un accesso senza verifiche — significherebbe soltanto che la verifica non si basa su una password statica che l’utente deve ricordare a memoria.

Nel caso di un OTP, il flusso tipico segue una sequenza abbastanza lineare: l’utente inserisce un identificativo, per esempio un indirizzo email o un numero di telefono; il sistema verifica che quell’identificativo possa effettivamente essere usato nel flusso di accesso; viene generato o richiesto un codice temporaneo; il codice arriva attraverso un canale configurato, tipicamente email o SMS; l’utente lo inserisce nell’app; il servizio di autenticazione ne controlla validità, scadenza e numero di tentativi residui; e infine il backend crea la sessione applicativa con i permessi previsti per quell’utente specifico.

Il codice, in tutto questo, non dovrebbe mai diventare una nuova password permanente. Deve avere una durata limitata nel tempo, non essere riutilizzabile dopo una verifica riuscita, e non essere sufficiente da solo a bypassare le regole autorizzative dell’applicazione.

Perché le password non bastano sempre

Le password restano uno strumento valido, questo va detto chiaramente, ma portano con sé diversi punti di attenzione che vale la pena elencare senza troppi giri di parole. Devono essere ricordate e aggiornate periodicamente. Possono essere riutilizzate su servizi diversi, spesso proprio per la fatica di ricordarne una nuova ogni volta. Possono essere intercettate da phishing o malware, in modi che l’utente medio non riconosce affatto. Vengono spesso recuperate tramite procedure che diventano, di fatto, un secondo metodo di accesso — con tutti i rischi che questo comporta. Generano un volume non trascurabile di richieste di assistenza quando l’utente semplicemente le dimentica. E possono creare difficoltà concrete a chi utilizza l’app solo saltuariamente, magari una volta al mese, il tempo sufficiente per aver già scordato tutto.

In un contesto aziendale, poi, la sicurezza non riguarda soltanto il singolo utente che ha smarrito la propria password. Un account compromesso può esporre dati personali, informazioni sulle assenze, documenti interni o dati relativi all’organizzazione del lavoro — cose che vanno ben oltre il fastidio individuale di un accesso bloccato.

Il passwordless non risolve automaticamente tutti questi problemi, ed è importante non illudersi che lo faccia. Piuttosto, sposta il punto di attenzione: dalla memoria dell’utente al canale che riceve l’OTP, e alla qualità dei controlli applicati dal sistema. Se l’email è compromessa, o se il numero di telefono è finito sotto il controllo di un’altra persona, anche un codice tecnicamente corretto smette di essere una prova sufficiente dell’identità di chi lo sta usando.

OTP via email o SMS: un compromesso pratico

Email e SMS restano i canali più diffusi per un motivo semplice: non richiedono all’utente di installare un’app aggiuntiva solo per generare codici. Sono quindi particolarmente adatti a tutti quegli scenari in cui la priorità principale è ridurre la frizione iniziale, senza per questo rinunciare del tutto al controllo.

OTP via email

L’email è comoda soprattutto quando l’indirizzo aziendale è già associato all’account e viene normalmente usato dalla persona nel proprio lavoro quotidiano. Offre anche una cronologia consultabile del messaggio — utile se qualcosa va storto — e può risultare più pratica di un SMS su dispositivi con connettività telefonica limitata o incerta.

I punti a cui prestare attenzione, però, non mancano. La casella di posta deve essere adeguatamente protetta, altrimenti tutto il castello crolla a monte. Il messaggio può finire nello spam o arrivare in ritardo, con conseguenze fastidiose sull’esperienza dell’utente. Il codice non dovrebbe mai comparire nell’oggetto della mail o in contenuti facilmente esposti dalle notifiche push del telefono. E la procedura non dovrebbe rivelare se un indirizzo risulta effettivamente registrato, perché farlo può facilitare l’enumerazione degli account da parte di chi ha intenzioni poco pulite.

OTP via SMS

L’SMS ha dalla sua l’immediatezza e la familiarità: praticamente chiunque sa leggere e digitare un codice ricevuto per messaggio. Il numero di telefono, però, non è affatto un fattore invulnerabile. Sono possibili il furto o la sostituzione fraudolenta della SIM, intercettazioni tecniche, accesso a un dispositivo lasciato sbloccato, e attacchi di social engineering rivolti direttamente all’operatore telefonico per ottenere un duplicato della SIM.

Per questo l’SMS può essere un buon compromesso per un rischio moderato, ma non andrebbe mai considerato automaticamente equivalente a un’autenticazione forte in ogni scenario possibile. Per dati o operazioni ad alto impatto possono servire fattori aggiuntivi, policy più restrittive o metodi più resistenti al phishing rispetto a un semplice messaggio di testo.

Un canale non è una policy di sicurezza

La scelta tra email e SMS dovrebbe sempre dipendere dal rischio concreto della situazione, dal tipo di dati trattati, dal contesto organizzativo e dalle procedure di recupero dell’account già esistenti. La comodità del canale conta, senza dubbio, ma non può mai sostituire il controllo sull’intero ciclo di autenticazione — dall’invio del codice fino alla revoca della sessione.

Sicurezza: cosa deve controllare il sistema

La sicurezza di un login OTP va progettata su più livelli contemporaneamente. Il client mobile può migliorare l’esperienza quanto vuole, ma l’autorità finale deve restare sempre sul servizio di autenticazione e sul backend, mai sul dispositivo dell’utente.

Scadenza e uso singolo

Un codice deve scadere dopo un intervallo di tempo limitato, e non può essere riutilizzato una volta che è stato verificato con successo. Questo controllo deve avvenire lato server o presso il provider di autenticazione — non basta che l’applicazione mobile lo dia semplicemente per scontato.

Limite ai tentativi

Un utente, o un attaccante, non dovrebbe mai poter provare codici all’infinito. Il sistema deve applicare limiti per codice, per account, per dispositivo e, quando ha senso farlo, anche per indirizzo IP o altri segnali di rischio. Anche qui, il limite va applicato fuori dal client: qualunque controllo lasciato solo all’app può essere aggirato con relativa facilità.

Rate limiting e reinvio

Il pulsante “Reinvia codice” deve rispettare un periodo di cooldown, sia per evitare richieste duplicate sia per ridurre l’abuso del canale scelto. Il countdown mostrato nell’app serve soprattutto alla UX, però: il backend deve comunque rifiutare richieste troppo ravvicinate e applicare il proprio rate limiting indipendente da qualunque cosa faccia l’interfaccia.

Risposte non rivelatrici

Un messaggio come “indirizzo non presente” può sembrare innocuo, ma in realtà permette a un estraneo di verificare quali persone hanno un account nel sistema. Quando il caso d’uso lo consente, è preferibile una risposta neutra — qualcosa come “Se i dati sono associati a un account, riceverai le istruzioni per proseguire” — che non conferma né smentisce nulla.

La scelta del messaggio va comunque calibrata sul flusso aziendale specifico: in alcuni contesti l’utente deve sapere subito che il proprio account non è stato configurato, in altri è più importante non divulgare informazioni che potrebbero essere sfruttate.

Protezione dei dati sensibili

L’OTP non dovrebbe mai finire scritto nei log applicativi, salvato in chiaro nello storage locale, o incluso nei messaggi di errore mostrati all’utente. Lo stesso vale per token, identificativi tecnici e dettagli della sessione, che vanno gestiti secondo un principio di minimizzazione — tenere solo ciò che serve davvero, per il tempo strettamente necessario.

La connessione deve essere protetta, e le credenziali di sessione vanno conservate con meccanismi appropriati alla piattaforma su cui gira l’app. In un contesto mobile questo significa valutare con attenzione Keychain su iOS e Keystore su Android, evitando di trattare un generico storage locale come se fosse un archivio sicuro per i token — non lo è, e non lo diventa solo perché comodo.

Sessione e autorizzazioni

La verifica dell’OTP dimostra, nel migliore dei casi, che chi sta accedendo controlla il canale associato a quell’account. Non assegna automaticamente tutti i permessi dell’applicazione, e non dovrebbe mai essere trattata come se lo facesse.

Dopo la verifica, il backend deve costruire una sessione con le autorizzazioni corrette, controllare che l’account sia effettivamente attivo, e applicare ruoli, sede, azienda e le policy previste per quello specifico profilo. Autenticazione e autorizzazione sono due fasi diverse, con scopi diversi, e devono restare distinte anche nel modo in cui vengono implementate.

GDPR e accessi aziendali

Un’app HR può trattare dati personali e, a seconda delle funzioni disponibili, anche informazioni relative all’organizzazione del lavoro, alle presenze e alle assenze dei dipendenti. Il login non è quindi un dettaglio isolato da sistemare in fretta: fa parte a pieno titolo delle misure con cui l’organizzazione protegge l’accesso ai propri dati.

Il GDPR non impone in modo generale un unico metodo di login valido per ogni applicazione esistente. Chiede piuttosto di valutare il rischio concreto e di adottare misure tecniche e organizzative adeguate, tenendo conto della natura dei dati trattati, delle finalità del trattamento e del contesto specifico in cui ci si trova.

Prima di adottare un flusso OTP, è opportuno chiarirsi le idee su alcuni punti fondamentali: quali dati diventano accessibili dopo l’autenticazione; chi è il titolare del trattamento e quali ruoli hanno i fornitori coinvolti nel processo; quali dati vengono registrati nei log e per quanto tempo restano conservati; come vengono gestiti la revoca, il cambio del numero di telefono, la perdita dell’accesso alla casella email o l’uscita di un dipendente dall’azienda; quali informazioni vengono effettivamente fornite agli interessati nell’informativa privacy; e come vengono gestiti assistenza, recupero account e incidenti di sicurezza quando qualcosa va storto.

La tracciabilità degli accessi deve restare proporzionata e motivata, non un pretesto per accumulare dati all’infinito. Un log utile può includere l’esito del tentativo, data e ora, l’account coinvolto e le informazioni tecniche necessarie alla sicurezza — ma non dovrebbe mai trasformarsi in una raccolta indiscriminata di dati, né contenere OTP o token in chiaro.

Quando un fornitore esterno gestisce componenti del trattamento per conto dell’azienda, responsabilità, istruzioni, sicurezza e gestione degli incidenti vanno definite contrattualmente e operativamente, non lasciate all’implicito. Per gli aspetti specifici del contesto aziendale, resta comunque necessaria la valutazione del titolare, del DPO o del consulente competente — questo articolo può orientare, non sostituire quella valutazione.

Attenzione al riferimento alla SCA

La Strong Customer Authentication prevista dalla PSD2 riguarda i servizi di pagamento, e non si applica automaticamente al login di un’app HR. Usare un OTP, di per sé, non rende quindi un accesso “conforme PSD2” — è un’equivalenza che si sente spesso, ma che semplicemente non regge.

Il riferimento alla SCA può essere utile per capire il principio generale dell’autenticazione basata su più elementi indipendenti, ma non va mai presentato come una certificazione o come una regola valida per ogni applicazione esistente. Per un sistema HR occorre valutare la normativa effettivamente applicabile, il rischio reale del trattamento e le policy proprie dell’organizzazione — non prendere in prestito un quadro normativo pensato per tutt’altro contesto.

Quando l’OTP non è sufficiente

Un OTP via email o SMS può essere del tutto adeguato per un accesso ordinario a rischio contenuto, ma può non bastare più quando si parla di operazioni che modificano dati particolarmente delicati, di esportazioni massive o accesso amministrativo, di approvazioni con effetti economici o organizzativi rilevanti, di utenti con privilegi elevati, o di scenari in cui il canale email o telefonico scelto non è abbastanza affidabile per il rischio in gioco.

In questi casi vale la pena valutare un secondo fattore, una chiave di sicurezza fisica, un’app di autenticazione dedicata, una biometria locale, oppure una procedura di approvazione separata per le operazioni più delicate. Vale anche la pena ricordare che la biometria sul dispositivo non sostituisce necessariamente l’identità verificata dal backend: spesso serve semplicemente a sbloccare, in modo locale, una credenziale che è già protetta altrove — non è un livello di sicurezza aggiuntivo indipendente, ma una comodità che si appoggia a qualcos’altro.

Checklist prima del rilascio

Prima di mettere in produzione un login OTP, conviene ripassare questi punti uno per uno:

• il codice ha durata limitata e uso singolo;
• esiste un limite ai tentativi di verifica;
• il reinvio è limitato lato backend, non solo nella UI;
• le risposte non rivelano inutilmente l’esistenza di un account;
• OTP, token e credenziali non finiscono nei log;
• il canale email o SMS è coerente con il rischio del caso d’uso;
• sessione, ruoli e autorizzazioni vengono creati dal backend;
• esiste una procedura per cambio numero, perdita dell’email e revoca dell’account;
• i log sono minimizzati, protetti e conservati per un periodo motivato;
• l’informativa e i ruoli privacy sono stati verificati;
• i casi di errore, timeout, codice scaduto e dispositivo offline sono stati testati.

Conclusione

Il login passwordless con OTP è utile quando l’obiettivo è ridurre la frizione senza rinunciare a un controllo temporaneo sull’accesso. Non è però una scorciatoia, e sarebbe un errore trattarlo come tale: la sicurezza dipende dal canale scelto, dal rate limiting, dalla scadenza dei codici, dalla gestione della sessione e dalle procedure che circondano l’intero ciclo di vita dell’account.

Nel caso di un’app HR, la domanda corretta non è semplicemente “password o OTP?” — è piuttosto: quali dati stiamo proteggendo, da quali minacce concrete, con quale esperienza utente e con quali responsabilità organizzative in gioco?

Chiariti questi principi, diventa molto più semplice progettare il flusso tecnico che li mette in pratica. Nell’articolo 08 vediamo come questi requisiti vengono tradotti in React Native: dall’inserimento dell’identificativo al componente a sei cifre, fino alla verifica email/SMS, al cooldown e alla creazione della sessione applicativa.

Domande frequenti