Un futuro senza password: costruire verso sistemi di autenticazione più sicuri e utilizzabili

Sostituzione delle password con chiavi private in una metafora di facile comprensione

Con l'introduzione dell'iniziativa EOSIO Labs ™, abbiamo iniziato a innovare all'aperto per quanto riguarda il futuro delle tecnologie blockchain basate su EOSIO. La nostra prima versione nell'ambito di questa iniziativa esplora il futuro della gestione delle chiavi private e le sue implicazioni sulla sicurezza e sulla gestione delle chiavi: Universal Authenticator Library (UAL). Ciò che sta alla base della filosofia di questa versione è l'esplorazione di un problema più ampio, incentrato sul modo in cui password e autenticazione sono state implementate su Internet, Blockchain o altro. Sebbene non vi sia alcuna versione software che accompagni questo post, questo articolo ha lo scopo di discutere i problemi che affliggono i sistemi di autenticazione esistenti e i moderni tentativi di andare oltre le password associate a tali problemi. Proporremo quindi, in astratto, un nuovo modello che utilizza la metafora di un "pass", come un biglietto aereo o una tessera della biblioteca, per affrontare questi problemi in modo sicuro e utilizzabile.

Il problema dell'udito

Gli attuali metodi di autenticazione degli utenti soffrono di quello che chiameremo "The Hearsay Problem". Per sentito dire è qualsiasi informazione ricevuta da una parte in merito alle dichiarazioni o azioni di una seconda parte che non possono essere adeguatamente comprovate. La nostra posizione è che tutte le informazioni provenienti da sistemi che si basano sugli attuali metodi all'avanguardia di autenticazione degli utenti si qualificherebbero come un semplice sentito dire se una delle parti coinvolte dovesse mettere in discussione la validità delle informazioni.

Per illustrare, immagina un post sui social media scarsamente accolto presumibilmente scritto da un noto politico che minaccia di distruggere la carriera di detto politico. Come facciamo a sapere con certezza che il politico ha, in effetti, creato il maledetto posto? Mentre l'autore avrebbe potuto davvero essere il politico in questione, potrebbe anche essere chiunque abbia accesso all'account dei social media del politico. Per estendere questo ragionamento, il pool di possibili "autori" potrebbe includere un numero qualsiasi di persone vicine al politico o hacker avversari in un attacco mirato. Eppure nessuno, incluso il politico e il fornitore di servizi di social media, sarebbe in grado di presentare prove conclusive, non circostanziali, che il politico fosse o non fosse definitivamente l'autore del posto in questione.

Per utilizzare la terminologia legale e tecnica, questa caratteristica è definita ripudibilità e non è un tratto desiderato. Due fattori principali portano a questa caratteristica della ripudiabilità nel nostro esempio di social media sopra; il primo fattore è uno schema di autenticazione che richiede la divulgazione di un segreto per convalidare il possesso di quel segreto. Negli schemi di sicurezza (come le password) soggetti a questo fattore, è impossibile creare registri delle attività dell'utente verificabili da chiunque non sia la parte e la controparte. Il secondo fattore è la mancanza di mezzi per dimostrare che i dati all'interno di un sistema che rappresentano effettivamente l'intento dell'utente, il che ci porta a un altro problema che stiamo chiamando, "Il controllo in bianco".

Il problema del controllo del bianco

Il problema di verifica del vuoto è presente in qualsiasi sistema che può agire per conto dell'utente senza la necessità del consenso esplicito dell'utente su tale azione specifica. È anche presente se il mezzo per acquisire il consenso dell'utente è qualcosa di meno di un registro di prova del fatto che l'utente è stato informato delle implicazioni di ogni singola azione e ha esplicitamente acconsentito a ciascuna azione.

Nell'esempio sopra, questo problema aggiunge il servizio di social media stesso e molti dei suoi dipendenti all'elenco delle parti che avrebbero potuto pubblicare il post dannoso. Come possiamo dimostrare che il servizio di social media o uno dei suoi dipendenti non ha avuto un accesso compromesso alla "posta" per conto del politico? Un esempio di posta in gioco di questo problema che mostra l'adeguatezza del nome "Il problema dell'assegno in bianco" è quello di un conto bancario. Dal punto di vista tecnologico, non c'è nulla che impedisca alla tua banca di liquidare o bloccare i tuoi fondi, e non ci sarebbe alcun modo per provare qualsiasi illecito, poiché la Banca potrebbe fabbricare registrazioni di transazioni apparentemente legittime. Ciò porterebbe senza dubbio gravi conseguenze che colpiscono in modo significativo molte parti interessate.

I "due diventano uno"

Un osservatore astuto potrebbe aver notato che questi problemi sono in realtà due risultati dello stesso problema di fondo: la mancanza di registri di verifica dimostrabili. Mentre ci sono tecnologie che affrontano questa fondamentale carenza nei nostri sistemi attuali, come i sistemi basati su certificati basati sulla crittografia asimmetrica, devono ancora raggiungere un livello di facilità d'uso che li rende accessibili al grande pubblico. Affrontando questa sfida con metafore di facile comprensione per una soluzione teorica che presenteremo di seguito, abbiamo l'opportunità di migliorare la sicurezza e l'usabilità di tutti i nostri sistemi, per ogni tipo di utente e migliorare l'esperienza degli utenti nel processo .

Le password

Quando si discute della sicurezza informatica, è necessario definire due termini di base: "autenticazione", che è il processo mediante il quale un utente dimostra di essere chi afferma di essere in possesso di particolari credenziali identificative, in genere con un nome utente e una password; e "autorizzazione", che è il processo mediante il quale le azioni di un utente all'interno di una piattaforma software sono consentite o limitate in base alla loro identità.

Dagli anni '60, le password sono state il metodo di fatto che consente all'utente di autenticarsi su un dispositivo o servizio. L'autenticazione con password è ormai una tecnologia ben nota per gli ingegneri. Per gli utenti, le password sono diventate un concetto semplice da comprendere; sono comodi e familiari anche per utenti non tecnici. Ma mentre la loro semplicità e familiarità sono un punto di forza, le password soffrono anche di molte debolezze.

Tali debolezze sono sia di natura tecnologica che umana. Alcuni di essi sono stati ampiamente discussi, anche nei dettagli esaustivi nelle NIST Digital Identity Guidelines, quindi non li ripeteremo qui. Ciò che è importante ricordare, tuttavia, è che le password non abilitano registri verificabili affidabili delle azioni che un utente ha autorizzato. Per autenticarsi con una password, deve essere rivelato e, al fine di verificare la validità della password di un utente, i fornitori di servizi devono averli archiviati in una forma di infrastruttura centralizzata. Ciò significa che nessuno, tranne il fornitore di servizi, può avere la certezza che tutti i registri di controllo che tengono sono rappresentazioni accurate delle azioni di un utente. Per questo motivo, i sistemi che si basano su password per l'autenticazione sono soggetti sia al problema Hearsay che al problema del controllo del vuoto, come descritto sopra.

Moderni tentativi di migliorare o sostituire le password

Nel corso degli anni ci sono stati diversi tentativi di migliorare o sostituire progressivamente le password. Di seguito esamineremo alcuni dei casi di maggior successo insieme ai loro punti di forza e di debolezza.

Gestori di password

L'esistenza di Password Manager rappresenta l'ammissione di alcuni dei difetti fondamentali delle password. Tentano di migliorare la situazione liberando l'utente dal dover generare e ricordare password sufficientemente complesse, consentendo quindi password monouso che soddisfano un livello di rigore di sicurezza molto più elevato.

Se utilizzati correttamente, i gestori di password migliorano la sicurezza e, in misura limitata, l'usabilità dei sistemi con autenticazione basata su password. Tuttavia, chiunque abbia cercato di insegnare ai propri genitori, figli o amici non tecnici a utilizzare le iterazioni odierne del software di gestione delle password è dolorosamente consapevole del fatto che non sono né ampiamente adottati né utilizzabili abbastanza per diventarlo.

Dal punto di vista tecnico, non esistono standard per i gestori di password. Tentano di indovinare quando un utente sta creando un account, accedendo o aggiornando la propria password per essere più conveniente, ma spesso falliscono. Forniscono la base per una soluzione migliorata, ma alla fine sono ancora solo password e sono ancora soggetti sia a The Hearsay Problem che a The Blank Check Problem.

Autenticazione a due fattori

In riconoscimento della debolezza delle password, sono stati fatti tentativi di sovrapporre ulteriore sicurezza per garantire che la password stessa non sia l'unico punto di errore. Questo approccio è generalmente chiamato un secondo fattore o autenticazione a due fattori (2FA). Esistono una varietà di implementazioni di 2FA e, sebbene tutte aggiungano diversi gradi di sicurezza incrementale ai sistemi di autenticazione basati su password, la compensano con una maggiore complessità in termini di installazione e funzionamento dell'utente finale. Una soluzione 2FA comune si basa sui messaggi SMS per fornire password one-time (OTP) basate sul tempo. Proprio come le password stesse, le soluzioni a due fattori soffrono del problema di non essere verificabili e vulnerabili alle pratiche di sicurezza dei gestori telefonici che inviano messaggi SMS al dispositivo.

Questa mancanza di verificabilità dimostrabile significa che 2FA non risolve ancora il problema Hearsay o The Blank Check Problem.

Lo standard WebAuthn

WebAuthn è un nuovo standard di autenticazione proposto dal World Wide Web Consortium (W3C), una comunità internazionale di organizzazioni membri, uno staff a tempo pieno e il pubblico che lavora insieme per sviluppare standard Web. WebAuthn si avvicina molto alla risoluzione di tutti questi problemi per le transazioni basate sul Web utilizzando la crittografia asimmetrica, anziché le password, fornendo uno degli ingredienti necessari per superare i problemi che abbiamo delineato. Tuttavia, al fine di impedire agli utenti che perdono i propri dispositivi di essere bloccati fuori da ogni servizio, WebAuthn è progettato per essere utilizzato insieme alle password, piuttosto che come sostituto.

Un altro importante limite significativo di WebAuthn è che è stato progettato come prova di presenza, non come prova del consenso. Non è definito per consentire richieste di autorizzazione per transazione verificabili dai peer. Quindi, ancora una volta, i sistemi che si basano su WebAuthn non dispongono di registri di verifica dimostrabili e sono soggetti sia al problema Hearsay sia al problema del controllo in bianco.

Blockchain come soluzione potenziale

Le blockchain hanno reso popolare l'idea di autenticare l'utente per ogni azione autorizzata, utilizzando la firma crittografica a chiave pubblica delle transazioni per raggiungere questo obiettivo. Questo è un grande miglioramento delle password e un passo oltre ciò che WebAuthn può fornire. Soddisfa anche il primo fattore necessario per affrontare il problema dell'udito: verificabilità verificabile.

Sfortunatamente, le interfacce utente blockchain di oggi non definiscono uno standard per descrivere le richieste di autorizzazione in modo umano per gli utenti in modo che possano essere visualizzate in un contesto affidabile per l'approvazione dell'utente. Senza questo standard di rendering delle richieste a misura d'uomo, gli utenti non possono sapere cosa stanno accettando. Ciò significa che anche se le blockchain creano un registro verificabile verificabile, mancano i mezzi per dimostrare che i dati all'interno di un sistema rappresentano effettivamente l'intento dell'utente. Pertanto, sono ancora soggetti ai problemi Hearsay e Blank Check.

Tornando al nostro esempio di social media, se una piattaforma di social media fosse costruita su una blockchain, sarebbero in grado di dimostrare che il politico in questione firmava, in effetti, l'azione che ha portato al post, ma non sarebbero stati in grado di provare che loro (o un altro partito) non hanno indotto il politico a firmare l'azione travisandola.

Una soluzione teorica: "Passes" invece di chiavi o password

Per migliorare la sicurezza dei nostri sistemi, abbiamo bisogno della prova del consenso dell'utente, unita a un livello di semplicità e usabilità che supera anche le password. Ciò significa che dobbiamo comunicare tecnologie complesse come la crittografia asimmetrica attraverso una metafora immediatamente comprensibile per ogni tipo di utente, non solo per i tecnologi. Un concetto che soddisfa questi criteri è quello di un "passaggio". Nel descrivere il concetto di pass, mostreremo come questa soluzione teorica di un pass utilizzata in un'applicazione Pass Manager sia in grado di soddisfare sia The Hearsay Problem che The Blank Check Problem che abbiamo delineato.

Per gli utenti, un pass rappresenta un mezzo familiare e tangibile per dimostrare il possesso di una credenziale. Ogni giorno interagiamo con i passaggi fisici come parte della nostra routine quotidiana. Come utente della biblioteca, devi semplicemente mostrare e presentare la tua tessera della biblioteca. Come passeggero di una compagnia aerea, devi semplicemente presentarti e presentare il tuo biglietto. Questi sono esempi di pass per uso singolo, per i servizi che non forniscono un pass per utilizzo singolo, è possibile presentare la patente di guida per dimostrare la propria identità.

Per supportare i casi d'uso di autenticazione e autorizzazione, introduciamo il concetto di "Pass Manager" digitale. Un Pass Manager è un paradigma senza password per i casi d'uso di registrazione, autenticazione e autorizzazione.

Cosa potresti fare con un Pass Manager?

Emissione e revoca

  • I fornitori di servizi potrebbero richiedere a Pass Manager di emettere un nuovo pass per un utente.
  • Gli utenti possono organizzare i loro passaggi in gruppi. (ad esempio i miei passaggi di lavoro e i miei passaggi personali)
  • Gli utenti possono autorizzare e rimuovere l'autorizzazione dei passaggi su più dispositivi.

Autenticazione

  • I fornitori di servizi potrebbero richiedere la prova del possesso di un pass da parte di un utente.
  • Gli utenti possono fornire prova del possesso di un pass.

Autorizzazione

  • I fornitori di servizi potrebbero richiedere la prova dell'autorizzazione di un utente per eseguire una determinata azione, con l'autorizzazione di un passaggio posseduto dall'utente.
  • Gli utenti possono vedere le richieste di autorizzazione rese chiaramente in modo umano-friendly e scegliere se autorizzare l'azione, sull'autorità di un pass che possiedono.

Come funzionerebbe un Pass Manager?

Un Pass Manager implementa un protocollo standardizzato (ancora da definire) per l'emissione e la revoca di pass, autenticazione e autorizzazione con pass. Un passaggio è un'astrazione concettuale che incapsula le informazioni sulle credenziali (chiavi).

L'esperienza di utilizzo di un Pass Manager digitale dovrebbe essere molto simile all'analogo fisico delle pass card. L'utente arriva semplicemente a un servizio (che si tratti di un'app Web, un'app nativa, un sistema di punti vendita o un chiosco) e presenta un pass per accedere o autorizzare un'azione. Questo è come uno studente universitario che utilizza il suo ID college per ottenere l'ammissione a un evento sportivo collegiale, quindi una volta all'interno, lo utilizza per acquistare cibo in uno stand con il proprio saldo del campus, ricevendo conferme d'ordine prima di impegnarsi nelle transazioni.

Sotto il cofano, una combinazione di tecnologie può funzionare in tandem per produrre sicurezza e usabilità superiori per gli utenti, tra cui firma crittografica, chiavi hardware e dati biometrici per la sicurezza delle credenziali, nonché un protocollo indipendente dal trasporto per la portabilità.

Ogni volta che il Pass Manager richiede il consenso di un utente, all'utente devono essere descritte descrizioni dell'azione a misura d'uomo e tale descrizione (o un suo derivato verificabile crittograficamente) deve essere inclusa nella risposta firmata dal Pass Manager. L'uso delle chiavi significa che i registri non sono ripudiabili e possono essere verificati da terzi e l'inclusione della descrizione a misura d'uomo nella risposta firmata può servire da prova dell'intenzione dell'utente. Queste caratteristiche risolvono sia i problemi di udito che di controllo del bianco.

Questo modello può supportare sia la tecnologia web attuale sia i futuri casi d'uso della tecnologia blockchain. È anche in grado di fornire un'esperienza utente chiara sia per i casi d'uso di accesso che per quelli di autorizzazione.

Cosa è necessario per il successo dei Pass Manager?

interoperabilità

Innanzitutto, dovrebbe essere creato un protocollo Pass Manager per consentire agli utenti la libertà di scegliere un Pass Manager più adatto alle proprie esigenze. Ciò è importante perché impedisce il blocco dei fornitori, creando il libero mercato necessario per promuovere l'innovazione sia nella sicurezza che nell'esperienza utente. In questo modo vincerà la migliore esperienza utente con una sicurezza accettabile.

Per fornire questa libertà di scelta, saranno necessari protocolli standard per l'iscrizione, l'accesso e l'autorizzazione. L'autorizzazione, in particolare, è una sfida interessante, perché richiede la definizione di uno standard per descrivere le richieste di autorizzazione agli utenti in modo comprensibile, verificabile, dimostrabile e portatile.

portabilità

In secondo luogo, il protocollo Pass Manager dovrebbe essere creato per la portabilità; significato: 1) supporto per ogni tipo di applicazione o servizio in esecuzione su qualsiasi piattaforma, 2) supporto per connettività di rete limitata o assente, 3) supporto per più dispositivi e 4) supporto per la comunicazione tra dispositivi.

Gli utenti dispongono di computer desktop, laptop, telefoni, tablet, smartwatch e chiavi USB. Pertanto è essenziale un'esperienza semplice e senza interruzioni per il rilascio e la revoca dell'accesso pass su più dispositivi. Gli utenti interagiscono anche con sistemi di punti vendita, computer pubblici non attendibili, distributori automatici e chioschi. È quindi necessaria la capacità di interagire da un dispositivo all'altro, con o senza connettività di rete, senza che i dispositivi si fidino reciprocamente.

Questi requisiti possono essere soddisfatti definendo il protocollo Pass Manager come agnostico per il trasporto. Ciò significa che il protocollo dovrebbe concentrarsi sulla definizione dei nomi e dei verbi secondo cui i sistemi di implementazione devono essere in grado di parlare in modo fluente e consentire ai trasporti attraverso i quali vengono parlati di variare. Esempi di trasporti potrebbero includere URL di protocollo personalizzati, Apple Universal Link, Intenti Android, richieste del server, codici QR, Bluetooth, NFC e API JavaScript. Con questa flessibilità, i Pass Manager possono essere veramente portatili.

usabilità

Gli utenti non dovrebbero considerare le implicazioni se stanno usando un servizio web con un back-end di database o un sistema blockchain. Nel caso della blockchain, non dovrebbero sapere su quale piattaforma o rete blockchain è costruita l'applicazione su cui si stanno basando. Dovrebbero solo considerare il loro caso d'uso. Cose come…

"Prelievo di fondi da un bancomat".

"Sto accedendo alla mia email".

"Mi piace un post sui social media."

"Sto acquistando chip da un distributore automatico."

"Sto trasferendo 100 token da Dan a Brian."

Mai cose come ...

"Sto firmando una transazione, con una chiave R1, autorizzata per il mio account blockchain11, su example.com dapp, che è basato sulla blockchain di Telos, che è costruita sulla piattaforma EOSIO."

Sicurezza

Le attuali implementazioni di password e sistemi a chiave pubblica non sono sicure per una serie di motivi. I Pass Manager devono fare di meglio.

Al fine di proteggere gli utenti dagli attacchi a honeypot centralizzati di credenziali, i dati segreti delle credenziali non devono mai essere archiviati su un'infrastruttura centralizzata in qualsiasi forma (hashing e salting non sono sufficienti). Al fine di proteggere gli utenti dal furto delle loro credenziali attraverso phishing, malware e attacchi man-in-the-middle, gli utenti non dovrebbero mai effettivamente sapere quali sono le loro credenziali e non dovrebbero mai essere inseriti manualmente o automaticamente in alcun servizio. Al fine di proteggere gli utenti dall'inganno ad aggiungere passaggi dannosi, gli utenti non dovrebbero essere in grado di aggiungere o rimuovere i passaggi stessi. Invece, un Pass Manager di fiducia dovrebbe gestirlo automaticamente per conto dell'utente in risposta all'utente che visita nuovi servizi o ottiene nuovi dispositivi.

Il futuro è aperto ai gestori di pass

In questo articolo, abbiamo presentato i problemi da risolvere per affrontare i problemi di sicurezza e usabilità con gli attuali metodi all'avanguardia per proteggere gli account degli utenti. Abbiamo presentato il concetto di Pass che sostituisce le password e il Pass Manager digitale come mezzo per risolvere questi problemi. Abbiamo discusso gli attributi necessari per il successo di un protocollo Pass Manager, ma non abbiamo definito esplicitamente il protocollo. Incoraggiamo gli sviluppatori intraprendenti a risolvere i problemi che affliggono sia la password sia i sistemi di sicurezza basati su chiavi e a considerare la metafora Pass come un modo per raggiungere tale obiettivo.

Dichiarazione di non responsabilità: Block.one fornisce il proprio contributo su base volontaria come membro della comunità EOSIO e non è responsabile di garantire le prestazioni complessive del software o di eventuali applicazioni correlate. Non forniamo alcuna dichiarazione, garanzia, garanzia o impegno in relazione alle versioni qui descritte, alla versione GitHub correlata, al software EOSIO o a qualsiasi documentazione correlata, espressa o implicita, inclusi, a titolo esemplificativo, garanzie o commerciabilità, idoneità per un particolare scopo e non violazione. In nessun caso saremo responsabili per qualsiasi reclamo, danno o altra responsabilità, sia in un'azione di contratto, illecito o altro, derivante da, in uscita o in connessione con il software o la documentazione o l'uso o altri rapporti nel software o documentazione. Eventuali risultati dei test o dati relativi alle prestazioni sono indicativi e non riflettono le prestazioni in tutte le condizioni. Qualsiasi riferimento a prodotti, risorse o servizi di terze parti o di terze parti non costituisce approvazione o raccomandazione da parte di Block.one. Non siamo responsabili e decliniamo ogni e qualsiasi responsabilità e responsabilità per l'uso o l'affidamento a tali risorse. Le risorse di terze parti possono essere aggiornate, modificate o terminate in qualsiasi momento, pertanto le informazioni qui riportate potrebbero essere obsolete o inesatte. Chiunque utilizzi o offra questo software in relazione alla fornitura di software, beni o servizi a terzi dovrà informare tali terzi di questi termini di licenza, dichiarazioni di non responsabilità ed esclusioni di responsabilità. Block.one, EOSIO, EOSIO Labs, EOS, l'eptaedro e i loghi associati sono marchi registrati di Block.one. Gli altri marchi citati nel presente documento appartengono ai rispettivi proprietari. Si noti che le presenti dichiarazioni sono un'espressione della visione di Block.one, non una garanzia di nulla, e tutti gli aspetti di essa sono soggetti a modifiche a tutti gli effetti a sola discrezione di Block.one. Chiamiamo queste "dichiarazioni previsionali", che includono dichiarazioni in questo documento, oltre a dichiarazioni di fatti storici, come dichiarazioni riguardanti lo sviluppo di EOSIO, le prestazioni attese e le caratteristiche future, o la nostra strategia aziendale, piani, prospettive, sviluppi e obiettivi. Queste dichiarazioni sono solo previsioni e riflettono le attuali convinzioni e aspettative di Block.one rispetto agli eventi futuri; si basano su ipotesi e sono soggetti a rischi, incertezze e cambiamenti in qualsiasi momento. Operiamo in un ambiente in rapido cambiamento. Di volta in volta emergono nuovi rischi. Dati questi rischi e incertezze, si consiglia di non fare affidamento su queste dichiarazioni previsionali. I risultati, le prestazioni o gli eventi reali possono differire materialmente da quanto previsto nelle dichiarazioni previsionali. Alcuni dei fattori che potrebbero far sì che risultati effettivi, prestazioni o eventi differiscano materialmente dalle dichiarazioni previsionali includono, senza limitazione: volatilità del mercato; disponibilità continua di capitale, finanziamenti e personale; accettazione del prodotto; il successo commerciale di eventuali nuovi prodotti o tecnologie; concorrenza; regolamentazione e leggi governative; e condizioni economiche generali, di mercato o commerciali. Tutte le dichiarazioni sono valide solo a partire dalla data della prima pubblicazione e Block.one non ha alcun obbligo e declina espressamente qualsiasi obbligo di aggiornare o alterare qualsiasi dichiarazione, a seguito di nuove informazioni, eventi successivi o altro. Nulla nel presente documento costituisce consulenza tecnologica, finanziaria, di investimento, legale o di altro tipo, in generale o in relazione a situazioni particolari o implementazioni. Consultare gli esperti nelle aree appropriate prima di implementare o utilizzare qualsiasi cosa contenuta in questo documento.