Skip to content

SQRL potrebbe davvero essere così sicuro come dicono?

Basta fare ricerche su altri siti web perché sei nello spazio esatto, abbiamo la soluzione che desideri e senza problemi.

Soluzione:

Nel complesso, il protocollo non sembra aumentare la sicurezza rispetto alla tecnologia esistente. Se state cercando il modo migliore per proteggere la vostra identità online, questo è senza dubbio il modo migliore per proteggere la vostra identità online. non è questo. Ma analizziamo i pro e i contro:

Vantaggi

È impossibile "condividere" una password nel senso stretto del termine: un sito web dannoso non può utilizzare l'autenticazione fornita a un sito per accedere a un altro sito.

Un attacco di forza bruta contro il token di autenticazione non è fattibile.

Le credenziali non vengono memorizzate sul computer dell'utente. Questo protegge da un piccolo sottoinsieme di attacchi diretti alla workstation. In particolare, si è protetti dagli attacchi che rubano la password dal computer. L'utente è non protetto contro qualsiasi tipo di dirottamento di sessione o di attacco di acquisizione del browser, tuttavia, e ora si è anche suscettibili di attacchi legati al telefono. Per saperne di più, più avanti.

Svantaggi

Questa tecnica è pericolosamente suscettibile agli attacchi MITM e all'ingegneria sociale. Probabilmente più di qualsiasi altro schema di autenticazione in uso, comprese le password. La fase di autenticazione e quella di avvio del login sono intrinsecamente scollegate, nel senso che il telefono si autenticherà correttamente rispetto a qualsiasi codice QR presentato, indipendentemente da come o dove viene presentato all'utente.

Quindi, ad esempio, un sito di phishing può mostrare un codice QR di login autentico che fa accedere l'aggressore al posto dell'utente. Gibson confida che gli utenti vedano il nome della banca, del negozio o del sito sull'app del telefono durante l'autenticazione e che quindi esercitino una vigilanza sufficiente a sventare gli attacchi. La storia suggerisce che questo è improbabile, e l'aspettativa più ragionevole è che vedere il nome corretto sull'app rassicuri falsamente l'utente facendogli credere che il sito sia legittimo perché è stato in grado di attivare la familiare richiesta di login sul telefono. La cautela che gli utenti hanno già imparato a conoscere per quanto riguarda la sicurezza delle password non si traduce necessariamente in nuove tecniche di autenticazione come questa, che è ciò che rende l'app probabilmente meno resistente all'ingegneria sociale.

Questa tecnica combina sia l'autenticazione che l'identità in un oggetto fisico che è frequentemente perso o rubato. In questo senso è più simile a un passaporto che a una password. Chiunque entri in possesso del vostro telefono è improvvisamente esclusivamente in possesso della vostra identità: non solo l'aggressore può impersonarvi, ma senza una seconda copia su un secondo telefono (improbabile), ora avete perso la capacità di identificarvi. Le chiavi di autenticazione non sono revocabili, quindi senza un recupero fuori banda da ogni singolo sito, non è possibile recuperare la propria identità. E anche se esiste un recupero fuori banda, di fronte a due utenti, uno in possesso dell'identità e l'altro no, potrebbe essere difficile capire perché il gestore del sito dovrebbe fidarsi di voi.

Questa tecnica combina tutti i token di autenticazione in un'unica chiave a meno che non se ne creino altri manualmente. In questo modo l'unica chiave diventa un bersaglio molto ghiotto per gli aggressori. Inoltre, la chiave è memorizzata sul telefono, che di solito ha una sicurezza interna ridicola. La combinazione di obiettivi insolitamente ghiotti con una sicurezza al di sotto degli standard non vi rende sicuri.

Alternative

L'aspetto più problematico di questo schema è il suo scarso confronto con le alternative disponibili.

L'opzione più sicura e universalmente accettata oggi è lastpass, keepass e altri sistemi di password integrati nei browser. In particolare, la crittografia lato client allevia la necessità di fidarsi di terzi. E soprattutto, l'integrazione del browser rende praticamente impossibile il phishing. LastPass o KeePass inseriranno la password solo se servita dal dominio corretto, il che significa che se viene presentato un sito dannoso, l'utente non avrà accesso alla sua password.

Inoltre, LastPass ha recentemente aggiunto una funzione che invita gli utenti a cambiare le password che non sono globalmente uniche. Questo aiuta a prevenire il riutilizzo delle password, il che significa che il vantaggio principale della tecnica di Gibson può essere facilmente ottenuto utilizzando questo strumento oggi sui siti esistenti, senza l'ulteriore insicurezza che il suo schema implica.

Gli attuali schemi di autenticazione a secondo fattore che utilizzano telefoni o dispositivi simili per proteggere i login degli utenti lo fanno già in modo tale da non rendere l'utente immediatamente vulnerabile al furto di identità in caso di furto del dispositivo. La sicurezza aggiuntiva dell'autenticazione a due fattori risiede nel fatto che né il dispositivo né la password possono essere utilizzati se rubati senza l'altro. La tecnica di Gibson è ampiamente resistente all'inclusione in uno schema a due fattori, il che rende indisponibile questo livello di protezione.

TL;DR:

La tecnica di autenticazione di Gibson non crea benefici sufficienti a superare i costi di sicurezza aggiuntivi che impone. Questi costi sono una parte fondamentale dello schema stesso e non possono essere risolti senza demolire l'intero progetto.

Si potrebbe sostenere che è meglio di niente, ma non si può sostenere che è meglio di qualsiasi cosa che abbiamo già.

Aggiornamenti di Gibson

Gibson ha recentemente annunciato una protezione aggiuntiva contro il phishing, perché questa è stata una delle principali critiche. La protezione è la seguente: Se NON si utilizzano i codici QR, il telefono cellulare, ecc. e si dispone invece di un agente di autenticazione sul sistema (ad esempio nel browser), il server può verificare che la risposta di autenticazione provenga dallo stesso IP della richiesta di autenticazione. Questo è un bene, ma lo scopo di questo protocollo è quello di trasferire la vostra identità al vostro cellulare. Se l'unico modo sicuro di usare il protocollo è quello di non usare la sua caratteristica principale, allora forse dovremmo ripensare a ciò che stiamo cercando di ottenere.

Teoricamente si potrebbe continuare a usare il cellulare se (e solo se) il cellulare sapesse che sta usando lo stesso IP del computer. Cosa che, ovviamente, non può sapere perché non conosce l'indirizzo IP del vostro computer.

Una soluzione migliore

Come già detto, se la misura di autenticazione è nel browser, allora l'intero problema del phishing è immediatamente risolto senza alcuno sforzo o verifica da parte dell'utente. Anche l'utente meno capace non può essere indotto ad autenticarsi al sito sbagliato, perché il token di autenticazione del sito è associato al nome del dominio e il browser non consente l'autenticazione al dominio sbagliato. Si tratta di una tecnica già in uso oggi, completamente automatica, che non richiede la collaborazione del sito né alcuna intelligenza da parte dell'utente.

Questo metodo può essere rafforzato richiedendo un secondo fattore di autenticazione (come una chiave variabile nel tempo su un telefono cellulare) che, ancora una volta, è già disponibile e in uso oggi, e che protegge l'utente (soprattutto) da eventuali errori da parte del sito o dell'azienda di destinazione.

Per quanto riguarda le preoccupazioni sulla vulnerabilità dell'autenticazione lato browser agli attacchi delle postazioni client: se è vero, è anche vero che se il browser è compromesso, allora nessun utilizzo di quel browser è sicuro, indipendentemente dal meccanismo di autenticazione utilizzato. Gli autori di malware possono (e già lo fanno) aspettare che l'utente si autentichi da solo utilizzando la sua tecnica super-sicura, e poi inviare silenziosamente il traffico necessario per "possedere" il suo account, il tutto senza che l'utente si accorga di nulla. Né SQRL né qualsiasi altro sistema di autenticazione possono proteggere l'utente di un browser compromesso, così come le serrature delle porte possono proteggervi da un incendio. Acquistare serrature ignifughe non è una soluzione.

Dove il prossimo

Se state cercando una garanzia assoluta di protezione dall'impersonificazione, allora guardate il token Fido U2F. Questo standard brilla laddove l'SQRL non è all'altezza e offre un'immunità garantita agli attacchi MITM (ad esempio, phishing). Lo fa autenticando non solo l'utente, ma anche il canale, in modo da garantire che (a) il vostro account non possa essere autenticato senza il token e che (b) il token possa essere usato solo per autenticare una connessione alla macchina a cui è collegato. Vedere questa risposta per ulteriori informazioni.

SQRL non è certamente esente da difetti, ma è certamente superiore alla maggior parte delle soluzioni di autenticazione primarie oggi ampiamente utilizzate sul web in termini di sicurezza e (e questo è importante) di usabilità. Permettetemi di spiegare.

Idee sbagliate

Innanzitutto, vorrei chiarire alcune idee sbagliate presenti in alcune delle altre risposte a questa domanda. Molte di queste risposte sono obsolete e sono state scritte prima delle modifiche alla documentazione di SQRL che affrontano i problemi in esse presentati, mentre altre sembrano porre un'enfasi eccessiva sui difetti di SQRL che sono presenti anche in molte altre soluzioni di autenticazione esistenti ampiamente utilizzate, ignorando i suoi vantaggi. Cerchiamo quindi di chiarire alcune idee sbagliate, che ne dite?

Mito: SQRL richiede la scansione dei codici QR per funzionare

Questo non è vero. I codici QR sono una comodità che facilita l'uso di SQRL su computer sui quali l'utente non ha impostato il software client SQRL. Il sito web di SQRL afferma quanto segue:

Tre modi per andare .smartphone opzionale:

Sebbene l'ispirazione originaria per lo sviluppo di questo sistema sia stata la scansione da parte di uno smartphone di un codice QR sulla pagina di login di un sito web, una piccola aggiunta a questo modello consente due modalità di funzionamento più significative: È sufficiente che l'immagine del codice QR sia anche un link cliccabile allo stesso URL codificato nel codice QR. In questo modo si ottengono tre modi per effettuare il login:

  • Scansione del codice con uno smartphone: Utilizzando il modello descritto sopra, lo smartphone di un utente scansiona il codice QR che appare sulla pagina di login di un sito web e l'utente si collega a quel sito.
  • Toccare il codice con uno smartphone: Per accedere a un sito web sullo smartphone, quando il codice SQRL visivo è anche un collegamento di tipo URL (utilizzando sqrl:// come schema), l'applicazione SQRL installata nello smartphone riceverà tale collegamento e collegherà in modo sicuro l'utente al sito sul telefono.
  • Fare clic sul codice sullo schermo di un computer desktop o portatile: Per utilizzare il sistema SQRL su qualsiasi sistema desktop o portatile, occorre installare un'applicazione SQRL per desktop che si registri per ricevere i link sqrl:// (in modo simile a come un'applicazione SQRL riceve il link). (Questo è simile al modo in cui un programma di posta elettronica si registra per ricevere i link mailto:). In questo modo gli utenti possono utilizzare sul desktop la stessa soluzione che utilizzano sullo smartphone. Quando un sito web offre un codice SQRL, l'utente fa semplicemente clic sul codice con il cursore del mouse e l'applicazione SQRL installata localmente si apre, richiede la password SQRL, conferma il dominio e quindi effettua il login.

Mito: La chiave master SQRL è memorizzata in modo completamente in chiaro e non protetto sul telefono.

Non so perché alcuni abbiano fatto questa supposizione, perché mi sembra ovvio che non sia così. La chiave master SQRL è protetta nello stesso modo in cui si protegge un database di password: con una password master forte. Rubare il telefono di un utente non vi darebbe automaticamente accesso alla sua identità online, a meno che non abbiate anche la sua password principale. Maggiori dettagli sulla gestione delle chiavi sono illustrati nella pagina sulla gestione delle chiavi lato client di SQRL sul sito web di SQRL.

Mito: Se la chiave master viene rubata, non è possibile cambiare le credenziali di accesso.

Anche questo è falso. SQRL offre un modo integrato per consentire al vero titolare dell'account di aggiornare le proprie credenziali di accesso nel caso di una chiave compromessa. Questa funzione è nota come Identity Lock:

Il "blocco dell'identità" impedisce il cambio di identità e consente il recupero: Anche questo aspetto è abbastanza significativo da meritare una propria pagina di descrizione dettagliata: "Una volta che l'identità di un utente è stata stabilita con un server web, il client SQRL è in grado di gestire il protocollo di blocco dell'identità. incapace di di cambiare tale identità. Ciò significa che se dovesse accadere il peggio e venisse utilizzata una password molto debole e facilmente indovinabile, o se il telefono o il desktop di un utente venissero violati per ottenere la chiave master dell'identità e la password, nessuna terza parte malintenzionata può cambiare l'identità online dell'utente per impedirgli di accedere ai propri account online. Inoltre, caricando una "chiave di sblocco dell'identità" normalmente offline, il vero proprietario dell'identità può ritirare e sostituire l'identità online perduta o rubata, essenzialmente per riprendersela da qualsiasi aggressore, rendendo inutile l'identità precedente.

Plausibile: SQRL è più vulnerabile al phishing rispetto alle soluzioni di autenticazione esistenti.

Ok, questo è in realtà parzialmente vero. Quando si utilizza SQRL tramite la scansione di un codice QR, la protezione contro il phishing è davvero minima. A meno che l'utente non si assicuri che il sito web mostrato nella barra degli URL del browser sia lo stesso visualizzato dall'applicazione SQRL Client, potrebbe autorizzare una sessione di login per l'aggressore. Questo è ancora meglio delle password, che darebbero al phisher accesso permanente al loro account (e a qualsiasi altro account che hanno altrove e che condividono la stessa password) fino a quando non cambiano la password, ma non è così buono come altre soluzioni che si integrano con il browser dell'utente, come le chiavi U2F, WebAuthn, i certificati client e (a determinate condizioni) i gestori di password.

Tuttavia, quando si utilizza un client SQRL sullo stesso dispositivo con cui si effettua l'accesso, SQRL dispone di alcune protezioni contro il phishing. Queste protezioni sono spiegate sul sito web di SQRL, nella sezione Come SQRL può contrastare gli attacchi di phishing. Esiste anche la possibilità di integrare SQRL con i browser (eventualmente tramite plugin) per fornire una protezione molto più forte contro gli attacchi di phishing, al pari di soluzioni come WebAuthn e i certificati client.

Nel complesso, classificherei SQRL allo stesso livello dei gestori di password per quanto riguarda la protezione dal phishing. Ha il potenziale per fornire una forte protezione contro il phishing quando è installato sullo stesso dispositivo su cui l'utente effettua l'accesso, ma fornisce una protezione minima quando è installato su un dispositivo diverso.

Confronto con le alternative

Confrontiamo ora SQRL con le soluzioni di autenticazione esistenti e ampiamente utilizzate.

Le password

SQRL è nettamente superiore alle password sotto molti aspetti. Non solo è più comodo da usare una volta configurato, poiché gli utenti non devono preoccuparsi di ricordare o riscrivere più password diverse per ogni sito, ma protegge anche dal riutilizzo delle password, dalle password deboli, dal keylogging e, in una certa misura, dal phishing.

Gli svantaggi di SQRL rispetto alle password sono che è più difficile da implementare per i gestori di siti web, non è così diffuso, richiede più tempo per la configurazione iniziale, richiede un certo sforzo per il trasferimento su un nuovo dispositivo e fornisce un singolo punto di guasto per tutti gli account dell'utente se la chiave master viene rubata (anche se quest'ultimo punto è anche il caso delle password se un utente utilizza la stessa password su ogni sito).

Gestori di password

Per molti versi, SQRL è molto simile ai gestori di password. Entrambi forniscono un'unica ancora di fiducia centralizzata che serve come una sorta di proxy di autenticazione tra gli utenti e i singoli servizi. Ci sono però un paio di modi in cui SQRL è superiore ai gestori di password.

Il vantaggio principale che penso abbia SQRL rispetto ai gestori di password è che è più facile e più sicuro da usare su computer non fidati o solo parzialmente fidati. Ad esempio, supponiamo che un utente voglia accedere a un sito web utilizzando un computer di una biblioteca pubblica. Con un gestore di password, dovrebbe accedere alla password del sito sul telefono e riscriverla manualmente sul computer, oppure scaricare il proprio gestore di password e il database delle password sul computer della biblioteca, sbloccare il database con la propria password principale e quindi accedere. Il primo scenario è scomodo per l'utente ed espone la sua password in chiaro per quell'unico sito al computer non attendibile (e a qualsiasi malware presente sul computer non attendibile, compresi i keylogger). Il secondo scenario è ancora peggiore, perché è scomodo ed espone l'intero database di password decifrate e la master password dell'utente al computer non attendibile. Con SQRL, l'utente dovrebbe solo scansionare un codice QR sullo schermo del computer non attendibile, il che è molto più comodo per l'utente ed espone solo una singola sessione di accesso (senza credenziali riutilizzabili come la password) al computer non attendibile.

Un altro vantaggio di SQRL rispetto ai gestori di password è che è più facile recuperare lo scenario peggiore: il furto del database delle password e della chiave master dell'utente. Con un gestore di password non solo dovreste cambiare la password su ogni sito, ma dovreste anche preoccuparvi che l'aggressore cambi le vostre password (eventualmente bloccando il vostro account). L'aggressore ha anche il vantaggio di possedere un elenco di tutti i siti su cui avete un account, rendendo molto più facile lo sfruttamento del furto di un database di password. Con SQRL, il furto della chiave master è ancora una situazione terribile, ma l'aggressore non dispone di un elenco di siti su cui avete un account (dovendo invece tirare a indovinare) e non può modificare la vostra password per bloccarvi. Una volta caricata la chiave di sblocco dell'identità, è anche un po' più comodo cambiare le credenziali di accesso su ogni sito, poiché il client SQRL è in grado di farlo automaticamente per ogni sito visitato al momento dell'accesso. (Non c'è bisogno di passare attraverso i moduli di "modifica della password").

Infine, credo che SQRL abbia un piccolo ma importante vantaggio rispetto ai gestori di password per quanto riguarda il suo obiettivo di sostituire completamente le password, e cioè che i siti hanno la possibilità di imporre l'uso di SQRL rispetto alle password tradizionali. Finché gli utenti avranno la possibilità di scegliere una sicurezza insufficiente, riutilizzando la stessa password su ogni sito, questo accadrà ancora. Se l'SQRL inizia a essere adottato su larga scala, i siti possono effettivamente iniziare a eliminare gradualmente l'uso delle password. Questo non può essere fatto con i gestori di password, che si basano sull'uso delle password per funzionare.

In termini di svantaggi, non riesco a pensare a una situazione in cui SQRL sia necessariamente peggiore dei gestori di password in termini di sicurezza. Il principale svantaggio di SQRL è che richiede il supporto dei gestori dei siti web, mentre i gestori di password non richiedono un supporto particolare da parte dei servizi esistenti. Ciò significa che è possibile iniziare a utilizzare i gestori di password fin da subito, ma SQRL dovrà aspettare che i siti lo implementino per poter essere utilizzato. Questa è una barriera significativa all'adozione.

Certificati client

Il vantaggio principale di SQRL rispetto ai certificati client è la convenienza. Attualmente i certificati client sono complicati da configurare, difficili da trasferire tra i computer e presentano problemi di privacy quando lo stesso certificato viene utilizzato su siti diversi. Sebbene in teoria si possa costruire un sistema che utilizzi i certificati client per risolvere questi problemi, ci sarebbe anche il problema della scarsa integrazione con le interfacce utente dei siti web e i server web, che sono problemi più difficili da risolvere. Non mi dilungherò troppo, perché su browserauth.net c'è già un ottimo articolo sui problemi di usabilità dei certificati client.

In termini di sicurezza, i certificati client hanno lo svantaggio di richiedere il coinvolgimento di una CA. Questo è (potenzialmente) costoso e richiede la fiducia nella CA di terze parti. Inoltre, se si sceglie di ignorare le CA e di autofirmare i propri certificati, si deve affrontare il problema della revoca dei certificati. I certificati client hanno anche gli stessi problemi di sicurezza e convenienza dei gestori di password quando gli utenti vogliono accedere a un computer non attendibile; devono trasferire il loro certificato al computer non attendibile, il che è scomodo e potenzialmente espone la loro identità principale al malware su quel computer.

In breve, fino a quando qualcuno non proporrà una soluzione migliore e facile da usare utilizzando i certificati client che risolva (almeno la maggior parte) di questi problemi, non credo che i certificati client siano un serio concorrente di SQRL (o, se è per questo, delle password).

Autenticazione a 2 fattori

Ho pensato di parlarne: SQRL e l'autenticazione a due fattori sono non si escludono a vicenda. SQRL sostituisce il primo fattore della 2FA: le password. Altre misure aggiuntive come i codici OTP o le chiavi FIDO U2F possono ancora essere utilizzate con SQRL.

WebAuthn

Ora ecco dove le cose si fanno interessanti. WebAuthn è un nuovo standard W3C (più recente di SQRL) progettato per fornire un'API standard che i siti web possono usare per autenticare gli utenti con chiavi pubbliche sul web. Proprio come SQRL, supporta l'uso del telefono dell'utente per autenticare una sessione di login su un dispositivo esterno, oltre ad alcuni altri metodi di autenticazione (come le chiavi di sicurezza di secondo fattore).

È qui che SQRL trova finalmente la sua strada, almeno dal punto di vista della sicurezza. WebAuthn non solo fornisce tutte le stesse protezioni contro il riutilizzo delle password, le password deboli e il keylogging di SQRL, ma fornisce anche una protezione ancora più forte contro il phishing, integrandosi con il browser dell'utente. anche quando autorizza una sessione di login per un PC su cui l'utente non ha precedentemente impostato il software client dell'autenticatore. Ciò è possibile perché in questo caso WebAuthn comunica direttamente con il browser dell'utente utilizzando protocolli di comunicazione bidirezionali come Blutooth o NFC, invece di comunicare con il sito web utilizzato dall'utente tramite un codice QR unidirezionale.

Dal punto di vista dell'usabilità, le cose sono un po' più complicate. Almeno in superficie, WebAuthn vince ancora una volta. Poiché si tratta di uno standard W3C già implementato in diversi browser, in teoria gli utenti possono iniziare a utilizzare WebAuthn senza dover installare alcun software di terze parti. In pratica, però, la maggior parte delle implementazioni di WebAuthn esistenti si concentra sul suo utilizzo come forma di autenticazione di secondo fattore, o come modo per riautenticare un utente che ha precedentemente effettuato l'accesso sullo stesso dispositivo tramite un metodo di login diverso (di solito una password). Come fattore di autenticazione primario, WebAuthn è ancora piuttosto carente di implementazioni valide.

Altre considerazioni minori includono il fatto che SQRL ha un metodo incorporato per la rotazione delle chiavi degli account in caso di furto della chiave principale, mentre WebAuthn si affida ai siti web per implementare il proprio sistema di revoca delle chiavi, e il fatto che WebAuthn richiede alcuni hardware opzionali (come Bluetooth o NFC) per autenticarsi su una macchina remota, mentre SQRL può funzionare su qualsiasi macchina con un display funzionante.

Nel complesso, ritengo molto probabile che WebAuthn finisca per rendere obsoleto SQRL. SQRL può avere un po' di respiro per ora, ma WebAuthn ha un sostegno molto più forte da parte dei fornitori di browser, degli operatori di siti e di altre organizzazioni di terze parti (come il W3C). Una volta che WebAuthn avrà un paio di implementazioni che ne consentiranno l'uso come fattore di autenticazione primario, mi aspetto che inizierà a conquistare il web molto rapidamente.

Avvertenze

SQRL è ancora in fase di sviluppo attivo, quindi il materiale presentato in questa risposta è soggetto a modifiche. Man mano che lo sviluppo prosegue, mi aspetto che alcune delle vulnerabilità e delle incertezze contenute in questa risposta vengano affrontate. La maggior parte della discussione si svolge attualmente nel newsgroup SQRL su grc.com.

Come al solito, prendete tutto ciò che riguarda Steve Gibson con una vagonata di sale. Link obbligatorio a attrition.org.


Diamo un'occhiata alla descrizione di Gibson del suo protocollo.

Gibon's rubbish

  • Il codice QR presentato vicino alla richiesta di accesso contiene l'URL del servizio di autenticazione del sito. L'URL include un lungo numero casuale generato in modo sicuro, in modo che ogni presentazione della pagina di login mostri un codice QR diverso. (In ambito crittografico questo lungo numero casuale è noto come "nonce").

  • L'applicazione di autenticazione SQRL dello smartphone esegue un hashish crittografico del nome di dominio del sito, unito alla chiave master dell'utente, per produrre una coppia di chiavi pubbliche specifiche del sito.

  • L'app firma crittograficamente l'intero URL contenuto nel codice QR utilizzando la chiave privata specifica del sito. Poiché l'URL include un numero casuale lungo e sicuro (il nonce), la firma è unica per quel sito e quel codice QR.

  • L'applicazione invia una query HTTPS POST sicura all'URL del codice QR, che è il servizio di autenticazione del sito. Il POST fornisce la chiave pubblica specifica del sito e la firma crittografica corrispondente dell'URL del codice QR.

  • Il sito Web di autenticazione riceve e conferma la query POST restituendo un HTTP standard "200 OK" senza altri contenuti. L'applicazione SQRL conferma il successo dell'invio del codice QR firmato dall'utente.

  • Il sito di autenticazione dispone dell'URL contenente il nonce restituito dalla pagina di accesso tramite lo smartphone dell'utente. Dispone inoltre di una firma crittografica di tale URL e della chiave pubblica specifica dell'utente. Utilizza la chiave pubblica per verificare che la firma sia valida per l'URL. Questo conferma che l'utente che ha prodotto la firma ha utilizzato la chiave privata corrispondente alla chiave pubblica. Dopo aver verificato la firma, il sito di autenticazione riconosce l'utente ora autenticato tramite la sua chiave pubblica specifica del sito.

La cosa più importante che salta all'occhio è l'uso di una "chiave principale" da parte dell'utente. Se leggo correttamente il protocollo, questa singola chiave master controlla l'intera identità online dell'utente.

Presumibilmente, questa chiave principale è memorizzata nel telefono dell'utente in un database dell'applicazione. Il che apre un enorme vettore di attacco sotto forma di malware progettato specificamente per rubare la chiave master.

Confrontiamo quindi la differenza tra ciò che accade quando viene compromessa una password e ciò che accade quando viene compromessa la chiave master. Supponendo che si seguano le buone pratiche di password lunghe, uniche e altamente casuali memorizzate in un password manager, tutto ciò che si deve fare è cambiare una singola password se viene compromessa. Cosa succede se la chiave master viene compromessa? Dovrete in qualche modo ottenere tutto siti con cui ci si è autenticati a riconoscere che la chiave master è stata compromessa. L'unico problema è che, non avendo altri mezzi per autenticarsi con il sito, come nomi utente o indirizzi e-mail, come farà il sito a sapere che siete proprio voi a cercare di revocare la chiave master?

Come tutto ciò che viene da Gibson, questo schema SRQL è altamente difettoso e non offre alcun vantaggio rispetto ai metodi convenzionali.

Hai la possibilità di confermare il nostro lavoro pubblicando un commento o valutandolo, ti ringraziamo.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.