Gestione delle password: una soluzione per evitare attacchi e compromissioni

L’autenticazione mediante username e password continua ad essere molto usata, spesso perché i committenti non ne vogliono sentire di proposte più sicure provenienti dai progettisti, i quali sanno bene che esistono modi di autenticarsi che offrono una sicurezza più elevata.

Nell’autenticazione username/password, client e server giocano ruoli critici e si possono formulare linee guida sia per il lato client che per quello server. Vediamole entrambe.

Password, come gestirle per evitare problemi: miti da sfatare, regole da seguire

Qualche tempo fa ci siamo già occupati di autenticazione, sottolineando l’importanza dei password manager, descrivendo gli attacchi a dizionario e parlando di KDF (key derivation function). Qui assumeremo note tali nozioni e rimandiamo alla sua lettura qualora non lo fossero. Le useremo per definire linee guida di riferimento, sia per il lato client che per quello server. Non chiederemo requisiti sull’infrastruttura. Iniziamo dal client.

Il lato client

Per i meno tecnici diremo subito che lato client indica il computer (notebook o desktop), tablet, cellulare, o smart-diavoleria che viene usato per connettersi a un server che fornisce un qualche servizio: applicazione web, file server, identity provider, sistema operativo di rete ecc.

Password manager a parte, il problema della scelta della password rimane fondamentale e sono da esecrare quei comportamenti che tendono a scriverle su un post-it, magari a portata di mano.

Per proteggerci da un attacco a dizionario sceglieremo una password che non assomiglia a una parola di una qualche lingua. “Assomiglia” è un termine poco preciso, ma si rende l’idea esponendo le tecniche per cui a partire da una parola di un dizionario ne creiamo una che le assomiglia. Due esempi:

1. da “suffragio” creiamo “SuFFr@g10”
2. da “multiplexer” creiamo “mUlt1pl€XeR!”

Sono parole ricavabili da un qualche dizionario: non ne possiamo essere certi, ma la probabilità è alta. Il web mette anche a disposizione enormi liste di password trapelate in qualche compromissione, che verranno certamente tentate dall’attaccante. Le password migliori sono stringhe casuali, come “h&%-ps7tr^”, anche generabili con l’ausilio di qualche tool, o stringhe simili a quelle usate qualche anno fa da Microsoft per attivare Windows o Office, “drtfe-fdpnr-hybao-hjdhq-yppwas” comunque impossibili da ricordare senza l’ausilio di un password manager.

Sorvoleremo sulle tecniche di social engineering che si usano per ottenere password, non perché poco importanti ma perché numerosissime e non descrivibili in maniera asettica come una formula di matematica.

Si suppone che venga usato un software standard, che possa supportare l’utente nel gestire una password manager, perché se l’attaccante indovina la password la sicurezza si annulla; restiamo distanti dai vincoli sintattici che richiedono maiuscole, minuscole, cifre, simboli speciali ecc., perché vessatori e inducenti a comportamenti scorretti e pericolosi. Aborriamo la regola che una password debba distinguersi dalla precedente in almeno due caratteri, perché vorrebbe dire memorizzare le password. Abbiamo già notato in diverse occasioni che la somma dei tempi persi dagli utenti per cambiare/recuperare/aggiornare una password vale molto più della riduzione del rischio indotta da regole vessatorie. E comunque, ripeto, quel che davvero conta è rimanere lontani dalle parole di un dizionario. Se si decidesse di memorizzare password nel browser queste potrebbero essere attaccate attraverso la variante di MITM chiamata MITB (man-in-the-browser).^[11]

Il client dovrebbe inoltre saper calcolare un hash ed effettuare encryption/decryption simmetriche.

Il client – così come il server – dovrebbe essere mantenuto esente dal malware. Sul lato client la cosa è più importante perché è lì che si digitano password e quindi un semplice keylogger potrebbe intercettarle.

Lato server

Opposto a quello client, il lato server appare più complesso ed articolato. La regola base è “mai immagazzinare le password nel lato server” ed accade che una buona metà dei server la contravvengono, dovendo dunque sobbarcarsi delle conseguenze. E quali sono? Un server è pur sempre un computer e come tale può essere attaccato in diversi modi. Non ci occuperemo della molteplicità di possibili attacchi a cui può essere esposto: i più curiosi potranno visionare l’elenco delle possibili minacce ai server, con probabilità decrescente. Owasp è l’Open Web Application Security Project, una fondazione non-profit che opera a livello mondiale per innalzare la sicurezza del software. Molte pratiche di sicurezza si rifanno ai suggerimenti Owasp, ampiamente disponibili attraverso il loro sito web.

Diciamo che i modi per compromettere un server sono molteplici e non scenderemo in dettaglio. Quello che è certo è che a valle della compromissione anche tutti i dati da esso gestiti sono compromessi, incluse le eventuali password. Questa è la ragione principale della regola base.

Si potrà obiettare che il server può gestire le password in forma criptata, usando una qualche forma di encryption simmetrica: se il server è compromesso è compromessa con tutta probabilità anche la chiave simmetrica usata per effettuare l’encryption, e quindi è facilmente disponibile la decryption, cioè le password.

Ma facciamo ordine. In linea di principio l’impianto logico dell’autenticazione basata sulle password funziona: l’utente mostra di sapere un segreto che gli altri non conoscono, il server, che mantiene una tabella di segreti, verifica che questo sia esatto: se la verifica ha esito positivo si ha il login, altrimenti fallirà. Il meccanismo è semplice, tuttavia si presta ad abusi, che non solo sfruttano l’esfiltrazione di password, ma anche attacchi replay o altri più complessi. Vediamo un possibile protocollo di autenticazione. La conversazione può svolgersi su canale non cifrato.

L’idea è che il server non memorizzi la password di un utente ma l’hash della password (salata con un salt, per robustezza rispetto la consultazione delle rainbow table); una eventuale compromissione del server non sarà pertanto fonte di password esfiltrate. Nella figura si fa riferimento a due nonces, che altri non sono che numeri casuali (grandi), da usarsi solo per quella occasione: salt e nonce possono viaggiare non cifrati perché il salt senza la password è inutile, il nonce cambia ogni volta. Il client, inviando n’, mostra la corretta conoscenza della password (mai inviata). Un commento sul token di autenticazione t non inviato in chiaro. Ogni volta che il client vorrà accedere a una risorsa protetta, invece di autenticarsi di nuovo, potrà inviare il valore successivo di t (t +1), poi quello ancora successivo (t + 2) ecc., sempre cifrato con k_x, in maniera tale da inviare solo informazioni che hanno validità una sola volta, ma che siano verificabili dal server data la conoscenza di k_x. Lo schema può essere arricchito introducendo un ulteriore nonce, generato questa volta dal client e inviato nel terzo messaggio, che diviene k_x{nonce_client, nonce_server}, dove evidentemente nonce_server corrisponde a nonce della figura: ciò serve a rendere vana la compromissione di k_x. In tal caso il server nel messaggio successivo dovrebbe dimostrare di aver compreso correttamente nonce_client, cifrandolo assieme a t. Lo schema resiste allora alla compromissione, al replay attack e vari altri attacchi basati su MITM o eavesdropping, mentre il reflection attack non ha qui senso.

Pur essendo vero che lo schema è frutto della creatività del sottoscritto, gli schemi commerciali di buona qualità non se ne discostano molto. L’idea può essere usata su LAN o su Internet, con la stessa validità. Molti schemi hanno invece peggiore qualità, poiché richiedono la memorizzazione della password nel server o l’invio in chiaro di dati comunque sensibili.

In definitiva abbiamo presentato una soluzione che permette lato server di non memorizzare password e di non essere proni ad attacchi basati su rainbow tables, prevenendo vari tipi di attacchi e compromissioni.

Conclusioni

Abbiamo definito linee guida per l’autenticazione, limitandoci a quella di base. Autenticazioni più sicure sono basata sulla condivisione di una chiave, o sulla crittografia a chiave pubblica (una firma digitale sicuramente autentica), fino a giungere agli schemi ticket-based come ad esempio Kerberos.

Molti anni fa Lamport inventò le one-time password (a lungo usate negli istituti bancari), mentre nel 2021 il sottoscritto, assieme a un suo studente, pubblicò un lavoro che presentava uno schema di autenticazione basato sul segreto alla Shamir, premiato con il “best paper award.”