Password e accessi in un software aziendale: come proteggerli.

01 / Le password

Le password non vanno conservate

Sembra un paradosso, ma un software ben fatto non conosce le password dei suoi utenti. Al loro posto conserva un’impronta: il risultato di un calcolo che parte dalla password ma non si può percorrere all’indietro. Al login il sistema rifà lo stesso calcolo e confronta le due impronte.

Se un giorno il database venisse rubato, l’attaccante troverebbe impronte, non password. E non le potrebbe leggere nemmeno chi gestisce il server.

Non tutte le impronte sono uguali

Con algoritmi vecchi o veloci, un computer moderno prova miliardi di password al secondo finché non trova quella giusta. Argon2, vincitore della Password Hashing Competition e oggi raccomandato da OWASP, è progettato per essere volutamente lento e richiedere molta memoria per ogni tentativo: un singolo login non se ne accorge, un attacco su larga scala diventa poco praticabile.

02 / I tentativi

Bloccare chi prova a indovinare

Ogni pagina di accesso su Internet riceve tentativi automatici: programmi che provano password comuni su nomi utente comuni. Un software ben progettato li conta e, dopo pochi errori, blocca temporaneamente quell’account.

Il dettaglio che fa la differenza è cosa si blocca. Bloccare solo l’indirizzo IP non basta, perché gli attacchi arrivano da migliaia di indirizzi diversi. Bloccare per nome utente ferma l’attacco senza impedire agli altri clienti di lavorare.

03 / Le app

L’accesso dalle app: i token

Quando un software ha anche un’app per smartphone, l’app non conserva la password: al primo accesso riceve un token, una chiave personale legata a quel dispositivo, e la usa per le richieste successive.

• il token scade dopo un certo periodo e va rinnovato con un nuovo accesso;
• se il telefono viene perso, si revoca quel token senza cambiare la password e senza toccare gli altri dispositivi;
• si può chiudere la sessione su tutti i dispositivi con un solo comando;
• anche i token vengono conservati sul server come impronte, non in chiaro.

Nei progetti in Django uso Knox, una libreria che gestisce proprio questi token con scadenza, revoca e un limite di dispositivi per utente.

04 / I permessi

Ognuno vede solo ciò che gli spetta

Un buon login non basta se, una volta entrati, si può vedere troppo. In un portale clienti l’errore classico è mostrare un ordine a chiunque ne conosca il numero: basta cambiare una cifra nell’indirizzo per vedere quello di un altro cliente.

La protezione va costruita alla base: ogni lettura dei dati parte già filtrata per l’utente collegato, e i documenti riservati si scaricano solo dopo un controllo dei permessi, mai da un link pubblico.

05 / Esperienza sul campo

Come l’ho fatto in un progetto

Nel portale clienti di Toscana Stampaggi ho applicato tutti questi principi:

• password conservate con Argon2;
• dopo 5 tentativi sbagliati l’account viene bloccato per 15 minuti, con registro dei tentativi consultabile dagli amministratori;
• l’app mobile accede con token Knox revocabili e un numero massimo di dispositivi per utente;
• ruoli separati per amministratori, operatori e clienti: un account non può essere contemporaneamente cliente e personale interno;
• ogni pagina e ogni endpoint ha un test automatico che verifica che un cliente non possa vedere i dati di un’altra azienda;
• tutto il traffico passa in HTTPS.

Le domande da fare al fornitore

• Come vengono conservate le password? Se la risposta è “cifrate” o “nel database”, chiedi quale algoritmo.
• Cosa succede dopo dieci tentativi di accesso sbagliati?
• Se un dipendente perde il telefono, come si blocca il suo accesso?
• Come vi assicurate che un cliente non veda i dati di un altro?

Sono domande semplici, ma le risposte dicono molto sulla cura con cui un software è stato costruito.