Le password costituiscono un problema, e lo sono per dei motivi che la maggior parte delle persone che le utilizzano ignorano. Una password che non è più in possesso dell'utente che l'ha creata garantisce la perdita della sicurezza, indipendentemente dalla sua complessità o da quanto possa essere difficile da indovinare.
La maggior parte dei lettori ammetterà senza problemi che le password sono difficili da ricordare e da gestire, soprattutto quando i loro requisiti diventano sempre più complessi. Fortunatamente, oggi sono disponibili degli eccellenti pacchetti software e componenti aggiuntivi per browser che aiutano a gestirle. La maggior parte dei lettori, tuttavia, potrebbe essere sorpreso nell'apprendere che i problemi connessi alle password sono molto più radicati di quanto si possa comunemente presumere: questi problemi sono sostanzialmente connessi al fatto che esse sono, per loro natura, intrinsecamente insicure.
Si potrebbe allora dire: "Ma le password sono sempre memorizzate in formato crittografato!" Questo è vero, ma è una verità ahinoi parziale. La verità è che anche una password crittografata può essere violata, sebbene (e per fortuna) con uno sforzo enorme, anche se è stata crittografata con tutti i crismi. Un problema sempre più urgente deriva dalla natura stessa delle password: per utilizzare una password in modo diretto, è obbligatorio gestirla in chiaro.
A questo punto si potrebbe ribattere: "Ma la mia password viene trasmessa in modo sicuro tramite HTTPS!". Questo è innegabilmente vero.
E si potrebbe anche aggiungere: "Ma io so che il server memorizza la mia password in forma crittografata e sicura, in modo che nessuno possa accedervi!". Beh, questa dichiarazione è un vero e proprio atto di fede nei confronti del server. Anche così, diciamo pure che anche questa affermazione potrebbe essere vera.
Ad ogni buon conto, rimane un caveat non indifferente: un divario nell'uso end-to-end delle password. Si consideri che una volta che il server riceve una password, nel tempo che intercorre tra l'essere trasmessa in modo sicuro e l'essere memorizzata, in modo altrettanto sicuro, la password deve essere letta ed elaborata. Sì, come testo in chiaro!
E non è finita: dato che in molti hanno la tendenza a pensare in termini di software, è facile dimenticarsi della vulnerabilità dell'hardware. Ciò significa che anche se il software è in qualche modo affidabile, la password a un certo punto deve risiedere nella memoria. E, a un certo punto, deve essere trasmessa tramite un bus condiviso alla CPU. Ciò fornisce ai potenziali malintenzionati numerosi vettori di attacco. Naturalmente questi vettori di attacco sono molto meno probabili di quelli presentati dalla trasmissione e la memorizzazione permanente, ma non meno gravi (le recenti vulnerabilità della CPU come Spectre e Meltdown dovrebbero costituire un severo promemoria).
L'unico modo per risolvere questo problema è eliminare completamente le password. C'è speranza! La comunità di ricerca e il settore privato stanno lavorando sodo per fare esattamente questo, e stanno emergendo e maturando numerosi nuovi standard. Sfortunatamente, le password sono così onnipresenti che ci vorrà molto tempo per trovare un accordo e mandarle in pensione, introducendo nuovi standard e nuove tecnologie.
Noi di Cloudflare ci domandiamo sempre con insistenza se ci sia qualcosa che può essere fatto subito, senza ritardi. L'approfondimento di oggi su OPAQUE è una possibile risposta. OPAQUE è uno dei tanti esempi di sistemi che consentono a una password di essere utile senza mai abbandonare l'utente. A nessuno piacciono le password, ma fintanto che sono in uso, possiamo almeno assicurarci che non vengano mai trafugate.
Durante l'internato che ho svolto quest'estate presso Cloudflare ho creato un'implementazione proof-of-concept di OPAQUE con TLS Exported Authenticators (OPAQUE-EA), una variante specifica di OPAQUE che può essere eseguita sul Web. È possibile provare la versione demo del mio lavoro ed esplorare il codice open-source.
Sono la prima ad ammettere che l'autenticazione basata su password è una gran scocciatura. Le password sono difficili da ricordare, noiose da digitare e notoriamente insicure. Le iniziative per ridurre o sostituire le password, però, sono promettenti. Ad esempio, WebAuthn è uno standard per l'autenticazione Web basato principalmente sulla crittografia a chiave pubblica che utilizza token hardware (o software). Ma anche così, le password continuano a rimanere, in modo fastidiosamente persistente, un comunissimo meccanismo di autenticazione. Che questo sia dovuto alla loro facilità di implementazione, alla dimestichezza che gli utenti hanno con esse o alla semplice loro onnipresenza sul Web e altrove, ci piacerebbe rendere l'autenticazione basata su password il più possibile sicura, fintanto che è in uso.
Il mio stage presso Cloudflare si è incentrato su OPAQUE, un protocollo crittografico che risolve uno dei problemi di sicurezza più manifesti nell'autenticazione basata su password sul Web: sebbene le password siano generalmente protette nel transito da HTTPS, i server le gestiscono in chiaro per verificarne la correttezza. La gestione delle password in chiaro è pericolosa, in quanto l'accidentale registrazione o memorizzazione nella cache potrebbe portare a una violazione dalle conseguenze catastrofiche. L'obiettivo del progetto, più che sostenere l'adozione di un particolare protocollo, è quello di dimostrare che OPAQUE rappresenta, tra le tante sul mercato, una valida opzione per l'autenticazione. Poiché il caso del Web è quello con cui ho più dimestichezza — come probabilmente molti lettori — lo userò come esempio principale, ma ciò non significa che sia l'unico (e nemmeno il migliore) ambiente per OPAQUE.
Autenticazione Web 101: Password-over-TLS
Che cosa accade esattamente quando si digita una password sul Web? Il sito deve verificare che la password digitata sia la stessa di quella originariamente registrata su di esso. Ma come avviene questo controllo?
Generalmente, il nome utente e la password vengono inviati a un server. Il server controlla quindi che la password registrata associata al nome utente corrisponda alla password fornita. Naturalmente, per impedire a un aggressore che intercetti il traffico Internet di rubare la password, la connessione al server deve essere crittografata tramite HTTPS (HTTP-over-TLS).
Nonostante l'impiego di HTTPS, rimane ancora un problema palese in questo flusso: il server deve memorizzare da qualche parte una rappresentazione della password. I server sono difficili da proteggere, e le violazioni sono all'ordine del giorno. Una falla in questa rappresentazione può portare a problemi di sicurezza catastrofici. (Per i dati sulle ultime violazioni, consultare https://haveibeenpwned.com/).
Per rendere queste falle meno devastanti, i server spesso applicano una funzione hash alle password dell'utente. Una funzione hash associa a ogni password un valore univoco e casuale. È facile applicare l'hash a una password, ma quasi impossibile invertire la funzione e recuperarla. (Detto questo, chiunque può indovinare una password, applicare la funzione hash e verificare se il risultato è lo stesso.)
Con l'hashing delle password, le password in chiaro non vengono più memorizzate sui server. Un aggressore che rubi un database di password non avrà più accesso diretto alle password. Al contrario, l'aggressore dovrà applicare l'hash a molte password potenziali e confrontare i risultati con gli hash trafugati.
Sfortunatamente, se il server esegue solo l'hashing delle password, gli aggressori possono scaricare le tabelle arcobaleno precalcolate contenenti gli hash di trilioni di password potenziali e recuperare quasi istantaneamente le password in chiaro. (Vedere https://projectrainbowcrack.com/table.htm per un elenco di tabelle arcobaleno).
Tenendo presente questo, un'efficace strategia di difesa approfondita consiste nell'utilizzare l'hashing "salato", in cui il server esegue l'hashing della password concatenata con un valore casuale, per ciascun utente, chiamato "sale". Il server inoltre salva il sale accanto al nome utente, cosicché l'utente non lo visualizza mai né ha bisogno di inviarlo. Quando l'utente invia una password, il server ricalcola questa funzione hash utilizzando il sale. Un aggressore che rubi i dati delle password, cioè le rappresentazioni delle password e i valori salt, dovrà quindi indovinare le password comuni una ad una e applicare la funzione di hashing (salato) a ciascuna ipotesi di password. Le attuali tabelle arcobaleno non sono d'aiuto, in quanto non tengono conto dei sali, per cui l'aggressore si trova a dover creare una nuova tabella arcobaleno per ogni utente!
Questa operazione (auspicabilmente) rallenta abbastanza l'attacco da consentire al servizio di informare gli utenti di una violazione, di modo che possano cambiare le loro password. Inoltre, gli hash salati dovrebbero essere rinforzati applicando un hash più volte per rallentare ulteriormente gli attacchi. (Vedere https://blog.cloudflare.com/keeping-passwords-safe-by-staying-up-to-date/ per una disamina più dettagliata).
Queste due strategie di mitigazione, ovvero la crittografia della password in transito e l'archiviazione di hash salati e rinforzati, costituiscono al giorno d'oggi le prassi più affidabili.
Rimane tuttavia aperta una grande falla nella sicurezza. Password-over-TLS (come lo chiameremo) richiede agli utenti di inviare le password in chiaro ai server durante il login, poiché i server devono visualizzare queste password per poterle confrontare con quelle registrate. Anche un server benintenzionato potrebbe accidentalmente memorizzare nella cache o registrare i tentativi di inserimento della password o danneggiarsi nel corso della verifica delle password. (Ad esempio, nel 2019 Facebook si rese conto di aver accidentalmente memorizzato centinaia di milioni di password di utenti in chiaro). Idealmente, i server non dovrebbero mai visualizzare una password in chiaro.
Ma questo è un bell'enigma: come è possibile controllare una password, se non la si è mai vista? Inserendo OPAQUE: un protocollo PAKE (Password Authenticated Key Exchange) che dimostra la conoscenza di una password e ottiene contemporaneamente una chiave segreta. Prima di descrivere in dettaglio OPAQUE, riassumeremo le funzionalità PAKE in generale.
Prove di password con Password-Authenticated Key Exchange
Password-Authenticated Key Exchange (PAKE) venne proposto da Bellovin e Merrit [1] nel 1992, con la motivazione iniziale di consentire l'autenticazione con password senza che si potessero verificare attacchi a dizionario basati su dati trasmessi attraverso un canale non sicuro.
Sostanzialmente, un PAKE semplice, o simmetrico, è un protocollo crittografico che consente a due soggetti che condividono solo una password, di creare un'efficace chiave segreta condivisa. Gli obiettivi del PAKE sono i seguenti:
1) Le chiavi segrete corrisponderanno se le password corrispondono, in caso contrario avranno un aspetto casuale.
2) I partecipanti non devono fidarsi di soggetti terzi (in particolare, di nessuna infrastruttura a chiave pubblica).
3) La chiave segreta risultante non viene appresa da nessuno che non partecipi al protocollo, inclusi coloro che conoscono la password.
4) Il protocollo non rivela la password di una delle parti all'altra (a meno che le password non corrispondano), né agli intercettatori.
In sintesi, l'unico modo per attaccare con successo il protocollo consiste nell'indovinare correttamente la password durante la partecipazione allo stesso. (Fortunatamente, questi attacchi possono essere in gran parte ostacolati con la limitazione della frequenza, cioè impedendo a un utente di effettuare l'accesso dopo un certo numero di tentativi con password errate).
Considerati questi requisiti, Password-over-TLS non è chiaramente un PAKE, in quanto:
- Si basa su WebPKI, che ripone la fiducia in terze parti denominate "Certificate Authorities" (vedere https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/ per una spiegazione approfondita di WebPKI e di alcune sue lacune).
- La password dell'utente viene rivelata al server.
- Password-over-TLS non fornisce all'utente alcuna garanzia che il server conosca la sua password o una sua derivata — un server potrebbe accettare qualsiasi input dall'utente senza alcun controllo.
Detto questo, il semplice PAKE è comunque un'alternativa peggiore rispetto a Password-over-TLS, semplicemente perché richiede al server di memorizzare le password in chiaro. Abbiamo bisogno di un PAKE che consenta al server di memorizzare gli hash salati, se vogliamo sconfiggere la prassi attualmente in uso.
Un miglioramento rispetto a un PAKE semplice è quello che viene denominato "PAKE asimmetrico" (aPAKE), in quanto solo il client conosce la password, mentre il server conosce una password hash. Un aPAKE riunisce le quattro proprietà del PAKE, più un'ulteriore:
5) Un aggressore che ruba i dati delle password memorizzati sul server, deve eseguire un attacco con dizionario per recuperare la password.
Il problema della maggior parte degli attuali protocolli aPAKE, tuttavia, è che non consentono un hash salato (o, se lo fanno, richiedono che il sale venga trasmesso all'utente, il che significa che l'aggressore ha accesso al sale in anticipo e può iniziare a calcolare una tabella arcobaleno per l'utente prima di rubare qualsiasi dato). Vorremmo, pertanto, aggiornare la proprietà di sicurezza come di seguito:
5*) Un aggressore che ruba i dati delle password memorizzati sul server, deve eseguire un attacco con dizionario per utente per recuperare la password, dopo che i dati sono stati compromessi.
OPAQUE è il primo protocollo aPAKE con una dimostrazione di sicurezza formale dotato di questa proprietà: consentire un sale completamente segreto.
OPAQUE - I server proteggono i segreti senza conoscerli!
OPAQUE è ciò che viene definito un aPAKE avanzato, il che significa semplicemente che resiste a questi attacchi di precalcolo utilizzando un hash segretamente salato sul server. OPAQUE venne proposto e formalmente analizzato da Stanislaw Jarecki, Hugo Krawcyzk e Jiayu Xu nel 2018 (per la massima trasparenza, Stanislaw Jarecki è il mio referente accademico). Il nome "OPAQUE" è la combinazione di due nomi di protocolli crittografici: OPRF e PAKE. Conosciamo già il PAKE, ma cos'è un "OPRF"? OPRF sta per Oblivious Pseudo-Random Function, un protocollo tramite il quale due parti calcolano una funzione F (chiave, x) che, pur essendo deterministica, esegue l'output di valori dall'aspetto casuale. Una parte inserisce il valore x, mentre l'altra inserisce la chiave: la parte che inserisce x apprende il risultato F (chiave, x) ma non la chiave, mentre la parte che fornisce la chiave non apprende nulla. (Ci si può avventurare nella matematica degli OPRFS qui: https://blog.cloudflare.com/privacy-pass-the-math/).
Il nucleo di OPAQUE è un metodo di archiviazione dei segreti utente per conservarli su un server, senza dare al server l'accesso a tali segreti. Invece di memorizzare un hash tradizionale della password salata, il server memorizza una busta segreta per l'utente, "chiusa" da due pezzi di informazioni: la password, conosciuta solo dall'utente, e una chiave segreta casuale (come un sale), conosciuta solo dal server. Per effettuare l'accesso, il client avvia uno scambio crittografico che rivela la chiave della busta al client, ma, significativamente, non al server.
Il server invia quindi la busta all'utente, che può ora recuperare le chiavi crittografate. (Le chiavi incluse nella busta sono una coppia di chiavi private-pubbliche per l'utente e una chiave pubblica per il server). Queste chiavi, una volta sbloccate, saranno gli input di un protocollo AKE (Authenticated Key Exchange), che consente all'utente e al server di creare una chiave segreta che potrà essere utilizzata per crittografare le future comunicazioni.
OPAQUE si compone di due fasi, che sono la registrazione delle credenziali e il login tramite scambio delle chiavi.
OPAQUE: fase di registrazione
Prima di registrarsi, l'utente si iscrive a un servizio, selezionando un nome utente e una password. La registrazione ha inizio con il flusso OPRF che abbiamo appena descritto: Alice (l'utente) e Bob (il server) eseguono uno scambio OPRF. Il risultato è che Alice ha una chiave casuale rwd, derivata dall'output OPRF F (chiave, password), in cui la chiave è una chiave OPRF di proprietà del server specifica per Alice, e la password è la password di Alice.
All'interno del suo messaggio OPRF, Bob invia la chiave pubblica per la sua identità OPAQUE. Alice genera quindi una nuova coppia di chiavi private/pubbliche, che sarà la sua identità OPAQUE permanente per il servizio di Bob, e crittografa la propria chiave segreta insieme alla chiave pubblica di Bob con la rwd (chiameremo questo risultato "busta crittografata"). Invia questa busta crittografata insieme alla sua chiave pubblica (non crittografata) a Bob, che archivia i dati che lei ha fornito, unitamente al segreto OPRF specifico di Alice, in un database indicizzato secondo il suo nome utente.
OPAQUE: fase di login
La fase di login è molto simile. Inizia allo stesso modo della registrazione: con un flusso OPRF. Tuttavia, sul lato server, invece di generare una nuova chiave OPRF, Bob cerca quella che ha creato al momento della registrazione di Alice. Lo fa cercando il nome utente di Alice (che lei fornisce nel primo messaggio) e recuperando il record che ha su di lei. Questo record contiene la chiave pubblica e la busta crittografata di Alice, più la chiave OPRF di Bob per Alice.
Invia anche la busta crittografata che Alice può decodificare con l'output del flusso OPRF. (Se la decodifica non va a buon fine, lei interrompe il protocollo — questo probabilmente indica che ha digitato la sua password in modo errato o che Bob non è chi dice di essere). Se la decodifica ha esito positivo, Alice ha ora la propria chiave segreta e la chiave pubblica di Bob. Alice inserisce queste chiavi in un protocollo AKE con Bob che, a sua volta, inserisce la sua chiave privata e la chiave pubblica di Alice, operazione che fornisce a entrambi una nuova chiave segreta.
Integrare OPAQUE con un AKE
Una domanda importante da porsi qui è: quale AKE è adatto per OPAQUE? La specifica CFRG emergente delinea diverse opzioni, tra cui 3DH e SIGMA-I. Tuttavia sul Web abbiamo già un AKE a nostra disposizione: TLS!
Ricordiamoci che TLS è un AKE perché fornisce un'autenticazione unilaterale (e reciproca) con derivazione del segreto condiviso. Il nucleo di TLS è uno scambio di chiavi Diffie-Hellman, che di per sé non è autenticato, il che significa che le parti che lo eseguono non hanno modo di verificare con chi lo stanno eseguendo. (Questo rappresenta un problema, dato che quando si accede alla propria banca o a qualsiasi altro sito Web che memorizza i dati privati, si vuole avere la certezza che quel soggetto sia chi dice di essere). L'autenticazione utilizza principalmente i certificati, emessi da entità attendibili tramite un sistema denominato Public Key Infrastructure (PKI). Ogni certificato è associato a una chiave segreta. Per dimostrare la sua identità, il server presenta il certificato al client e firma l'handshake TLS con la sua chiave segreta.
La modifica di questa onnipresente autenticazione basata su certificati sul Web forse non è il punto migliore da cui iniziare. Un miglioramento, piuttosto, verrebbe dall'autenticazione del segreto condiviso di TLS utilizzando OPAQUE, una volta completato l'handshake TLS. In altre parole, una volta che un server viene autenticato con il suo tipico certificato WebPKI, i client potrebbero successivamente autenticarsi sul server. Questa autenticazione potrebbe avere luogo "post handshake" nella connessione TLS utilizzando OPAQUE.
Exported Authenticators è un meccanismo per l'autenticazione “post-handshake" in TLS. Consente a un server o client di fornire prova di un' identità senza dover configurare una nuova connessione TLS. Ricordiamoci che, nel caso standard del Web, il server stabilisce la loro identità con un certificato (dimostrando, ad esempio, che si tratta di "cloudflare.com"). Ma se lo stesso server possiede anche identità alternative, dovranno eseguire nuovamente TLS per dimostrare chi sono.
Il flusso base di Exported Authenticator ricorda un classico protocollo challenge-response, e funziona come riportato di seguito. (Prenderemo in considerazione solo il caso di autenticazione del server, in quanto quello del client è simmetrico).
In qualsiasi momento dopo aver stabilito una connessione TLS, Alice (il client) invia una richiesta di autenticazione per indicare che desidera che Bob (il server) dimostri un'identità aggiuntiva. Questa richiesta comprende un contesto (una stringa imprevedibile: si pensi ad essa come a una sfida) ed estensioni che includono informazioni sull'identità che il client vuole ricevere. Ad esempio, il client potrebbe includere l'estensione SNI per richiedere al server un certificato associato a un determinato nome di dominio diverso da quello inizialmente utilizzato nella connessione TLS.
Al ricevimento del messaggio del client, se dispone di un certificato valido corrispondente alla richiesta, il server manda indietro un Exported Authenticator che dimostra di possedere la chiave segreta per il certificato. (Questo messaggio ha lo stesso formato di un messaggio di autenticazione dal client nell'handshake TLS 1.3: contiene un Certificate, un CertificateVerify e un messaggio Finished). Se il server non può o non desidera autenticarsi con il certificato richiesto, risponde con un autenticatore vuoto che contiene solo un messaggio Finished ben strutturato.
Il client controlla allora che l'Exported Authenticator ricevuto sia ben strutturato, quindi verifica che il certificato presentato sia valido e, in tal caso, accetta la nuova identità.
In sintesi, Exported Authenticators fornisce l'autenticazione a un livello superiore (come il livello dell'applicazione) in modo sicuro, sfruttando la crittografia ben controllata e i formati di messaggio di TLS. In più, è vincolato alla sessione TLS, di modo che i messaggi di autenticazione non possono essere copiati e incollati da una connessione TLS ad un'altra. In altre parole, Exported Authenticators fornisce esattamente i giusti agganci necessari per aggiungere a TLS l'autenticazione basata su OPAQUE.
OPAQUE with Exported Authenticators (OPAQUE-EA)
OPAQUE-EA consente a OPAQUE di operare in qualsiasi momento dopo che una connessione TLS è già stata configurata. Ricordiamoci che Bob (il server) memorizzerà la propria identità OPAQUE, in questo caso una chiave di firma e una chiave di verifica, e che Alice memorizzerà la sua identità — crittografata — sul server di Bob. (Il flusso di registrazione in cui Alice memorizza le sue chiavi crittografate è lo stesso del normale OPAQUE, tranne per il fatto che memorizza una chiave di firma, ragion per cui passeremo direttamente al flusso di login). Alice e Bob eseguono due flussi EA di autenticazione delle richieste, uno per ciascun soggetto, e i messaggi del protocollo OPAQUE viaggiano nella sezione estensioni degli EA. Vediamo nel dettaglio come funziona.
Per prima cosa, Alice genera il suo messaggio OPRF in base alla sua password. Crea una richiesta di autenticazione richiedendo l'identità OPAQUE di Bob e include (nel campo delle estensioni) il suo nome utente e il messaggio OPRF, quindi li invia a Bob tramite la connessione TLS stabilita.
Bob riceve il messaggio e cerca il nome utente di Alice nel suo database. Recupera il record OPAQUE di Alice contenente la sua chiave di verifica e la busta crittografata, più la propria chiave OPRF. Utilizza quindi la chiave OPRF per il messaggio OPRF e crea un Exported Authenticator che dimostra la titolarità della sua chiave di firma OPAQUE, con un'estensione contenente il proprio messaggio OPRF e la busta crittografata. Inoltre, invia una nuova Authenticator Request chiedendo ad Alice di dimostrare la titolarità della sua chiave di firma OPAQUE.
Alice analizza il messaggio e completa la valutazione OPRF tramite il messaggio di Bob per ottenere la rwd di output, e usa la rwd per decodificare la busta. Questa operazione rivela la sua chiave di firma e la chiave pubblica di Bob. Utilizza quindi la chiave pubblica di Bob per validare la corrispondente prova di Authenticator Response e, se viene verificata, crea e invia un Exported Authenticator dimostrando di detenere la nuova chiave di firma decodificata. Bob controlla la validità dell'Exported Authenticator di Alice, e se viene verificato, accetta il suo login.
Il mio progetto: OPAQUE-EA su HTTPS
Tutto quanto descritto sopra è supportato da moltissima teoria, che deve ancora trovare la sua strada per tradursi in pratica. Il mio progetto era quello di trasformare la teoria in realtà. Ho iniziato dalle descrizioni scritte di Exported Authenticators, OPAQUE e una bozza preliminare di Opaque-in-TLS. Il mio obiettivo era quello di passare da queste a un prototipo funzionante.
La mia demo mostra la fattibilità dell'implementazione di OPAQUE-EA sul Web, rimuovendo completamente le password in chiaro dalla rete, anche se crittografate. Ciò fornisce una possibile alternativa all'attuale flusso password-over-TLS con migliori proprietà di sicurezza, ma nessuna modifica visibile all'utente.
Vale la pena conoscere alcuni dettagli relativi all'implementazione. In informatica, l'astrazione è uno strumento potente. Significa che spesso possiamo affidarci a strumenti e API esistenti per evitare la duplicazione degli sforzi. Per il mio progetto ho fatto grande affidamento su mint, un'implementazione open source di TLS 1.3 in Go, ideale per la prototipazione. Ho anche utilizzato la libreria CIRCL. Ho creato librerie per Exported Authenticators, il nucleo di OPAQUE, e OPAQUE-EA (che lega insieme i due).
Ho realizzato la demo Web avvolgendo la funzionalità OPAQUE-EA in un semplice server HTTP e client che si scambiano messaggi su HTTPS. Poiché un browser non può eseguire Go, ho compilato da Go a WebAssembly (WASM) per ottenere la funzionalità Go nel browser e ho scritto un semplice script in JavaScript per richiamare le funzioni WASM di cui avevo bisogno.
Dato che gli attuali browser non danno accesso alla connessione TLS sottostante sul lato client, ho dovuto implementare una soluzione alternativa per consentire al client di accedere alle chiavi dell'exporter, ovvero facendo in modo che il server calcolasse semplicemente le chiavi e le inviasse al client su HTTPS. Questa soluzione alternativa riduce la sicurezza della demo risultante: significa che la fiducia viene riposta nel server affinché fornisca le chiavi corrette. Ad ogni modo, la password dell'utente è ancora sicura, anche nel caso in cui un server dannoso fornisse chiavi errate — semplicemente non hanno la certezza di essersi effettivamente registrate in precedenza con quel server. In futuro, tuttavia, i browser potrebbero includere un meccanismo per supportare le chiavi esportate e consentire a OPAQUE-EA di essere eseguito con le sue proprietà di sicurezza al completo.
È possibile esplorare la mia implementazione su Github e persino seguire le istruzioni per attivare il proprio server e client OPAQUE-EA di prova. Vorrei tuttavia sottolineare che l'implementazione è da intendersi esclusivamente come verifica concettuale e non deve essere utilizzata per sistemi di produzione senza un'ulteriore importante revisione.
Limiti di OPAQUE-EA
Nonostante le sue eccezionali proprietà, ci saranno sicuramente alcuni ostacoli nel trasformare OPAQUE-EA da proof-of-concept a meccanismo di autenticazione a tutti gli effetti.
Supporto del browser per le chiavi di esportazione TLS. Come accennato brevemente in precedenza, per eseguire OPAQUE-EA in un browser, è necessario accedere ai segreti dalla connessione TLS chiamati "chiavi di esportazione". Non vi è modo di farlo negli attuali browser più popolari, quindi sarà necessario aggiungere il supporto per questa funzionalità.
Revisione dei database delle password. Per adottare OPAQUE-EA, i server non devono solo aggiornare la loro logica di controllo delle password, ma anche rivedere completamente i relativi database. Poiché OPAQUE si basa su rappresentazioni speciali di password che possono essere generate solo in modo interattivo, le password con hash salate esistenti non possono essere aggiornate automaticamente ai record OPAQUE. I server dovranno probabilmente eseguire uno speciale flusso di registrazione OPAQUE utente per utente. Poiché OPAQUE si basa sul buy-in sia dal client che dal server, i server potrebbero dover supportare il vecchio metodo per un bel po' prima che tutti i client si mettano al passo.
Affidamento su standard emergenti. OPAQUE-EA si basa su OPRFS, che è in fase di omologazione, e Exported Authenticators, un modello proposto. Ciò significa che il supporto per queste dipendenze non è ancora disponibile nella maggior parte delle librerie crittografiche esistenti, per cui i primi utenti potrebbero dover implementare questi strumenti in prima persona.
RiepilogoFinché le persone utilizzeranno le password, vorremmo rendere la procedura il più sicura possibile. I metodi attuali si basano sulla pratica rischiosa di gestire le password in chiaro sul lato server verificandone la correttezza. I PAKE (e in particolare gli aPAKE) consentono l'accesso sicuro tramite password senza mai permettere al server di visualizzare le password. OPAQUE è uno dei migliori aPAKE sul mercato e può essere completamente integrato in TLS. È possibile controllare il codice qui.
[1] Bellovin, S. M., and Merritt, M. “Encrypted key exchange: Password-based protocols secure against dictionary attacks.” Proc. IEEE Computer Society Symposium on Research in Security and Privacy (Oakland, May 1992), 72–84.