Cluster · autenticazione a due fattori aziendale
2FA obbligatorio sul gestionale: perché e come si implementa
Perché un gestionale con dati di clienti richiede il secondo fattore, come si passa da una demo aperta a un sistema serio e cosa trova un test di sicurezza.
Tempo di lettura: 10 min
Guida operativa · Casi studio
Il secondo fattore obbligatorio su un gestionale aziendale non è un adempimento burocratico: è ciò che separa un'applicazione che si può usare con dati veri da una che si può solo mostrare.
Questo articolo racconta un passaggio concreto: come un gestionale nato come demo — con account di prova e credenziali visibili nella schermata di login — è diventato un sistema con cui gestire dati di clienti reali. E cosa ha trovato il test di sicurezza fatto alla fine.
Il progetto è il CRM per il noleggio auto realizzato per Rial Rent, che contiene anagrafiche, documenti e contratti di oltre settanta clienti.
In sintesi
- Demo e produzione sono due prodotti diversi: serve un momento esplicito in cui si passa dall'uno all'altro.
- Le password non si conservano mai in chiaro: solo come hash con un algoritmo pensato per le password.
- Il secondo fattore rende inutile una password rubata, che è lo scenario più probabile.
- Il login deve rispondere in tempo costante: altrimenti i tempi rivelano quali email esistono.
- Il test di sicurezza va fatto da chi non ha scritto il codice: chi costruisce non vede i propri punti ciechi.
Il punto di partenza: una demo che funzionava troppo bene
La prima versione aveva account di prova e le relative credenziali stampate nella schermata di accesso. È una scelta ragionevole per far provare un prodotto: chi riceve il link entra, guarda, capisce.
Diventa un problema nel momento esatto in cui nel sistema entrano dati veri. Da quell'istante, chiunque abbia l'indirizzo dell'applicazione — trovato in una chat, in una email inoltrata, nella cronologia di un browser — può entrare e vedere anagrafiche, documenti e contratti.
Cosa c'è nella versione seria
- Password solo come hash. Mai in chiaro, mai reversibili, con un algoritmo progettato per le password — quindi volutamente lento — e non con una funzione di hash generica.
- Sessioni con token firmati. Un solo algoritmo di firma accettato, dichiarato esplicitamente lato server.
- Secondo fattore obbligatorio. Codice TOTP da app sul telefono, con attivazione guidata al primo accesso. Non opzionale: obbligatorio per tutti i ruoli.
- Limite di tentativi. Per indirizzo IP e per email, così che provare password in sequenza smetta di essere praticabile.
- Risposta a tempo costante. Il login impiega lo stesso tempo che l'email esista o no.
- Utenti governati. Creazione riservata agli amministratori, con invito via email e password temporanea da cambiare.
Perché TOTP e non SMS
| Metodo | Pro | Contro |
|---|---|---|
| TOTP da app | Nessun costo, nessun servizio esterno, non intercettabile sulla rete telefonica | Se l'utente perde il telefono serve una procedura di recupero |
| SMS | Familiare per tutti | Costo per messaggio, dipendenza da un fornitore, vulnerabile alla sostituzione della SIM |
| Nessun costo | Se l'email è compromessa il secondo fattore non aggiunge nulla |
Per un gestionale interno con un numero chiuso di utenti, TOTP è quasi sempre la scelta giusta: zero costi ricorrenti e nessuna dipendenza esterna.
Perché il tempo costante conta
È il dettaglio meno intuitivo e va spiegato, perché sembra paranoia.
Se il sistema, ricevuta un'email che non esiste, risponde subito "credenziali errate", mentre per un'email esistente impiega un attimo in più a verificare la password, quella differenza di tempo è un'informazione. Misurandola su molti tentativi si costruisce l'elenco delle email registrate — e da lì si passa a un attacco mirato.
La correzione è semplice concettualmente: il percorso di verifica deve costare lo stesso in entrambi i casi.
Cosa ha trovato il test di sicurezza
Dopo l'irrobustimento è stato fatto un test di sicurezza sul risultato, condotto separatamente da chi aveva scritto il codice. Ha trovato e fatto chiudere quattro categorie di problema. Le raccontiamo come categorie, senza dettagli riproducibili.
- Aggiramento del secondo fattore. Esisteva un modo di usare il token emesso durante la fase di attivazione del 2FA come se fosse un token di sessione completa. Un token va legato allo scopo per cui è stato emesso, non solo all'utente.
- Confusione dell'algoritmo di firma. Il server accettava più algoritmi di firma per i token: una categoria di attacco nota, che si chiude accettando un solo algoritmo dichiarato lato server e rifiutando quanto indicato nel token stesso.
- Enumerazione degli utenti dai tempi. Nonostante l'intenzione, alcuni percorsi rispondevano in tempi diversi e rivelavano l'esistenza delle email.
- Documento accessibile a un ruolo sbagliato. Un file riservato risultava scaricabile da un ruolo che non doveva vederlo: il controllo era sull'interfaccia, non sull'endpoint che serviva il file.
L'ultimo è il più istruttivo. Nascondere un pulsante non è un controllo di accesso. Se l'indirizzo che serve il documento non verifica il ruolo, chi lo conosce lo scarica comunque. È l'errore più comune nelle applicazioni con più ruoli, ed è invisibile finché qualcuno non lo cerca.
L'attivazione: dove si nascondono gli errori
Rendere obbligatorio il secondo fattore significa che ogni utente, al primo accesso, deve configurarlo. È un momento delicato per due ragioni.
La prima è di esperienza: chi non ha mai usato un'app di autenticazione va accompagnato, altrimenti chiama e si fa disattivare il 2FA — e a quel punto la misura è vanificata dall'organizzazione invece che dalla tecnica.
La seconda è di sicurezza, ed è più sottile. Durante l'attivazione l'utente è in uno stato intermedio: ha superato la password ma non ha ancora un secondo fattore. Serve un token per completare quel passaggio, e quel token non deve valere come sessione completa.
È esattamente il problema trovato dal test di sicurezza sul progetto: il token della fase di attivazione poteva essere usato per accedere alle funzioni normali. La correzione è concettualmente semplice — legare ogni token allo scopo per cui è stato emesso, non solo all'utente — e va prevista in fase di progetto.
- Un token emesso per completare l'attivazione vale solo per quel percorso.
- Un token di sessione completa si emette solo dopo la verifica del secondo fattore.
- Il server verifica lo scopo dichiarato, non solo la validità della firma.
- La procedura di recupero, per chi perde il telefono, passa da un amministratore.
Quanto costa fare le cose per bene
Vale la pena essere espliciti su questo, perché la sicurezza viene spesso rimandata con l'argomento del costo.
Le misure descritte in questo articolo — hash delle password, token con scopo, TOTP, limiti sui tentativi, tempo costante, ruoli verificati sugli endpoint — non richiedono infrastruttura aggiuntiva né servizi a pagamento. Sono lavoro di sviluppo, e la maggior parte è più economica se fatta all'inizio che aggiunta dopo.
Quello che ha un costo separato è il test di sicurezza, ed è la voce che viene tagliata per prima. È anche l'unica che trova ciò che il team non può vedere: chi ha scritto il codice conosce le proprie intenzioni, e verifica il sistema contro quelle. Un occhio esterno lo verifica contro quello che fa davvero.
Il quadro sul trattamento dei dati è in AI e GDPR.
Esempi pratici
Una password riutilizzata. Un utente usa sulla propria email la stessa password del gestionale, e quel servizio subisce una violazione. Senza secondo fattore, chi ha la lista entra. Con il secondo fattore, la password rubata non basta.
Un link condiviso per errore. L'indirizzo dell'applicazione finisce in una chat di gruppo. Con le credenziali in home page è un incidente; con accesso governato è un link che non porta da nessuna parte.
Un collaboratore che se ne va. Con utenti creati e revocati da un amministratore, l'accesso si chiude in un minuto. Con un account condiviso, bisogna cambiare la password a tutti — e qualcuno se ne dimentica.
Un settore con dati sensibili. Se il gestionale contiene documenti d'identità o dati sanitari il ragionamento si irrigidisce ulteriormente: vale la pena leggere AI e sicurezza dei dati e AI e privacy aziendale.
Errori da evitare
Lasciare le credenziali di prova quando entrano dati veri. È l'errore che rende inutile tutto il resto.
Rendere il secondo fattore opzionale. Se è facoltativo, lo attiva chi già è attento — cioè chi ne ha meno bisogno.
Controllare i permessi solo nell'interfaccia. Il controllo sta sull'endpoint, non sul pulsante.
Accettare più algoritmi di firma. È una comodità che apre una categoria di attacco conosciuta.
Considerare il test di sicurezza un extra. È il passaggio che trova le cose che il team non può vedere, e va messo a piano fin dall'inizio.
Come applicarlo in azienda
- Dichiara il passaggio da demo a produzione. Scrivi cosa cambia quel giorno: credenziali, dati, backup, accessi.
- Rendi il secondo fattore obbligatorio per tutti, con attivazione guidata al primo accesso.
- Sposta i controlli di permesso sugli endpoint, non sull'interfaccia. Poi verificali chiamandoli direttamente.
- Governa gli utenti: creazione e revoca in mano agli amministratori, nessun account condiviso.
- Metti a piano un test di sicurezza fatto da qualcuno che non ha scritto il codice, e budgeta il tempo per chiudere quello che troverà.
L'impostazione dei ruoli, che è il presupposto di tutto questo, è descritta nel caso studio del CRM.
Conclusione
Il secondo fattore obbligatorio non è la parte interessante di un gestionale, ed è quella senza cui il resto non si può usare. La differenza fra una demo e un sistema di produzione non è la quantità di funzioni: è che nel secondo ci sono dati di persone reali, e questo cambia tutte le regole.
Le due cose da fare: dichiarare esplicitamente il momento in cui la demo finisce, e far verificare il risultato a qualcuno che non l'ha costruito.
Vuoi capire quali processi della tua azienda possono essere automatizzati con l'AI? Giallo Studio può aiutarti a trasformare il problema in un workflow reale. Il servizio completo è in software su misura, la forma installabile in PWA e web app.
Schema consigliato: Article + HowTo + FAQPage + BreadcrumbList
Risorse correlate
FAQ
Perché un gestionale interno dovrebbe avere il secondo fattore?
Perché contiene dati personali di clienti, documenti e contratti, ed è raggiungibile da internet. La password da sola cade con il riuso su altri servizi o con una campagna di phishing: il secondo fattore rende inutile la password rubata.
Cos'è un codice TOTP?
È un codice numerico che cambia ogni pochi secondi, generato da un'app sul telefono a partire da un segreto condiviso con il server. Non viaggia via SMS, quindi non è esposto agli attacchi sulla rete telefonica, e non richiede nessun servizio esterno a pagamento.
Le credenziali di prova in home page sono un problema?
Per una demo no, sono uno strumento di vendita. Diventano un problema nel momento esatto in cui nel sistema entrano dati veri di clienti: da quel momento chiunque abbia l'indirizzo può entrare. Serve un passaggio esplicito in cui si dichiara che la demo è finita.
Perché il login deve rispondere in tempo costante?
Perché se rispondere a un'email inesistente richiede meno tempo che verificare una password sbagliata, i tempi di risposta rivelano quali email sono registrate. È un modo silenzioso di costruire un elenco di utenti validi da attaccare.
Serve davvero un test di sicurezza esterno?
È il passaggio che trova le cose che chi ha scritto il codice non vede, perché conosce le proprie intenzioni e non i propri punti ciechi. Nel progetto descritto ha trovato quattro categorie di problema, tutte in aree che sembravano coperte.
Chi deve poter creare gli utenti?
Solo gli amministratori, con invito via email e password temporanea da cambiare al primo accesso. L'autoregistrazione su un gestionale interno non ha senso: gli utenti sono un elenco chiuso e governato.