it-swarm.dev

SQRL potrebbe davvero essere sicuro come si dice?

Mi sono appena imbattuto in https://www.grc.com/sqrl/sqrl.htm

Con Secure QR Login, il telefono scatta il codice QR visualizzato sulla pagina di accesso di un sito Web. . . . e sei registrato in modo sicuro.

Sembra che sarebbe davvero fantastico - uno dei problemi che mi viene in mente è se il lettore QR è compromesso, per visualizzare www.google.com invece di www.nsa-super-secret-place.gov/123. Quali altri problemi ha questo sistema?

35
Wayne Werner

Come al solito, prendi tutto ciò che riguarda Steve Gibson con un camion carico di sale. Attrition obbligatoria.org link .


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

Gibon's rubbish

  • Il codice QR presentato vicino al prompt di accesso contiene l'URL del servizio di autenticazione per il sito. L'URL include un numero casuale lungo generato in modo sicuro in modo che ogni presentazione della pagina di accesso visualizzi un codice QR diverso. (Nei circoli crittografici questo lungo numero casuale è noto come "nonce".)

  • L'app di autenticazione SQRL dello smartphone esegue la crittografia crittografica del nome di dominio del sito codificato dalla chiave principale dell'utente per produrre una coppia di chiavi pubblica specifica 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 sicuro (nonce), la firma è univoca per quel sito e codice QR.

  • L'app emette un HTTPS sicuro POST query all'URL del codice QR, che è il servizio di autenticazione per il sito. Il POST fornisce la chiave pubblica specifica del sito e la corrispondente firma crittografica dell'URL del codice QR.

  • Il sito Web di autenticazione riceve e riconosce la query POST restituendo un HTTP standard “200 OK” senza altri contenuti. L'app SQRL riconosce l'invio riuscito del codice QR firmato dall'utente.

  • Il sito di autenticazione ha l'URL contenente il nonce che è tornato dalla pagina di accesso tramite lo smartphone dell'utente. Ha anche una firma crittografica di tale URL e la chiave pubblica specifica del sito dell'utente. Utilizza la chiave pubblica per verificare che la firma sia valida per l'URL. Ciò 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 dalla chiave pubblica specifica del sito.

La cosa più grande che mi viene in mente è l'uso di una "chiave master" da parte dell'utente. Se sto leggendo correttamente il protocollo, quella singola chiave principale 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 spalancato sotto forma di malware progettato specificamente per rubare la chiave principale.

Quindi confrontiamo la differenza tra ciò che accade quando una password viene compromessa rispetto a ciò che accade quando la chiave master viene compromessa. Supponendo che tu stia seguendo buone pratiche di password di password lunghe, uniche e altamente casuali memorizzate in un gestore di password, tutto ciò che devi fare è cambiare una singola password se viene compromessa. Cosa succede se la chiave principale viene compromessa? Dovrai in qualche modo ottenere tutti i siti con cui ti sei autenticato per riconoscere che la tua chiave principale è stata compromessa. L'unico problema è che, dal momento che non hai altri mezzi per autenticarti con il sito come nomi utente o indirizzi e-mail, come farà il sito a sapere che sei proprio tu a provare a revocare la chiave principale?

Come tutto ciò che viene fuori da Gibson, questo schema SRQL è altamente imperfetto e non offre vantaggi rispetto ai metodi convenzionali.

12
user10211

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

Vantaggi

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

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

Le credenziali non sono memorizzate sul tuo computer. Questo ti protegge da un piccolo sottoinsieme di attacchi diretti alla workstation. In particolare, sei protetto dagli attacchi che rubano la tua password dal tuo computer. Sei no protetto contro qualsiasi tipo di attacco di sessione o di acquisizione del browser, e ora sei anche suscettibile agli attacchi relativi al telefono. Ne parleremo 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 la fase di avvio dell'accesso sono intrinsecamente disconnesse, nel senso che il telefono eseguirà correttamente l'autenticazione rispetto a qualsiasi codice QR presentato, indipendentemente da come o dove viene presentato all'utente.

Quindi, ad esempio, un sito di phishing può visualizzare un codice QR di accesso autentico che accede all'attaccante anziché all'utente. Gibson è fiducioso che gli utenti vedranno il nome della banca o del negozio o del sito nell'app del telefono durante l'autenticazione e quindi eserciteranno una vigilanza sufficiente per contrastare gli attacchi. La storia suggerisce questo improbabile, e l'aspettativa più ragionevole è che vedere il nome corretto sull'app rassicurerà falsamente l'utente nel pensare che il sito sia legittimo perché è stato in grado di innescare la familiare richiesta di accesso sul telefono. La cautela già avvertita dai responsabili degli utenti in merito alla sicurezza delle password non si traduce necessariamente in nuove tecniche di autenticazione come questa, che è ciò che rende questa app intrinsecamente meno resistente al social engineering.

Questa tecnica combina autenticazione e identità in un oggetto fisico che è frequentemente perso o rubato. In questo senso è più come un passaporto piuttosto che una password. Chiunque sia in possesso del tuo telefono è improvvisamente esclusivamente in possesso della tua identità: non solo l'attaccante può impersonarti, ma senza una seconda copia su un secondo telefono (improbabile), ora hai perso il capacità di identificarsi. Le chiavi di autenticazione non sono revocabili, quindi senza il ripristino fuori banda da ciascun sito, non è possibile recuperare la propria identità. E anche se esiste un recupero fuori banda, di fronte a due utenti, uno con il possesso dell'identità e uno senza, potrebbe essere difficile capire perché l'operatore del sito dovrebbe fidarsi di te.

Questa tecnica combina tutti i token di autenticazione in un'unica chiave a meno che non ne crei manualmente altri. Questo rende la tua chiave unica un bersaglio estremamente succoso per gli attaccanti. Inoltre, la chiave è memorizzata sul telefono, i cui dispositivi hanno in genere una sicurezza interna ridicolmente porosa. La combinazione di obiettivi insolitamente succosi con una sicurezza scadente non ti rende sicuro.

Alternative

L'aspetto più problematico di questo schema è quanto scarsamente si confronta con le alternative disponibili.

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

Inoltre, LastPass ha recentemente aggiunto una funzione che assiste gli utenti a cambiare password che non sono univoche a livello globale. Questo aiuta a prevenire il riutilizzo della password, il che significa che il vantaggio principale della tecnica di Gibson può essere facilmente ottenuto utilizzando questo strumento oggi su siti esistenti, senza l'insicurezza aggiunta che il suo schema implica.

Gli schemi di autenticazione di secondo fattore esistenti che utilizzano telefoni o dispositivi simili aiutano oggi a proteggere gli accessi degli utenti in modo tale da non renderti immediatamente vulnerabile al furto di identità in caso di furto del dispositivo. La sicurezza aggiuntiva dell'autenticazione a due fattori sta nel fatto che né il dispositivo né la password possono essere utilizzati se rubati senza l'altro. La tecnica di Gibson è in gran parte resistente all'inclusione in uno schema a due fattori, che rende questo livello di protezione non disponibile.

TL; DR:

La tecnica di autenticazione di Gibson non crea vantaggi sufficienti per superare i costi di sicurezza aggiuntivi che impone. Questi costi sono una parte fondamentale del sistema stesso e probabilmente non possono essere elaborati senza demolire l'intero progetto.

Potresti sostenere che è meglio di niente, ma non puoi sostenere che sia meglio di qualsiasi cosa abbiamo già.

Aggiornamenti di Gibson

Gibson ha recentemente annunciato una protezione aggiuntiva contro il phishing perché questa è stata una grande critica. La loro protezione è questa: se NON stai usando i codici QR, il cellulare, ecc. E hai un agente di autenticazione sul tuo sistema (nel browser, per esempio), allora il server può verificare che l'autenticazione la risposta proviene dallo stesso IP della richiesta di autenticazione. Questo va bene e bene, ma lo scopo di questo protocollo è spostare la tua identità sul tuo cellulare. Se l'unico modo sicuro per utilizzare il protocollo è non utilizzare la sua funzionalità principale, allora forse dovremmo ripensare ciò che stiamo cercando di realizzare.

Teoricamente tu potresti continui a usare il tuo cellulare se (e solo se) il tuo cellulare sapesse che stava usando lo stesso IP del tuo computer. Che, ovviamente, non può sapere perché non conosce l'indirizzo IP del tuo computer.

Una soluzione migliore

Come indicato in precedenza, se la misura di autenticazione è nel tuo browser, , l'intero problema di phishing viene immediatamente risolto senza alcuno sforzo o verifica da parte dell'utente. Anche l'utente meno capace non può essere indotto a eseguire l'autenticazione su un sito sbagliato perché il token di autenticazione del sito è associato al nome di dominio e il browser non consente l'autenticazione con il dominio sbagliato. Questa è una tecnica già in uso oggi, è completamente automatica e non richiede la collaborazione del sito o alcuna intelligenza da parte dell'utente.

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

Per quanto riguarda le preoccupazioni in merito all'autenticazione lato browser vulnerabile agli attacchi client-workstation: mentre è vero, è anche vero che se il tuo browser è compromesso, quindi nessun utilizzo di quel browser è sicuro , indipendentemente dal meccanismo di autenticazione utilizzato. Gli autori di malware possono (e già lo fanno) attendere che tu ti autentichi da solo usando la tua tecnica super-sicura, e quindi inviare silenziosamente il traffico necessario per "possedere" il tuo account, il tutto senza che tu veda nulla di sbagliato. Né SQRL né altri sistemi di autenticazione possono proteggere l'utente di un browser compromesso, non più di quanto le serrature delle porte possano proteggerti da un incendio. L'acquisto di serrature ignifughe non è una soluzione.

Where Next

Se stai cercando un garanzia assoluta di protezione dalla rappresentazione , guarda il token Fido U2F. Questo standard brilla laddove SQRL non è all'altezza e ti offre l'immunità garantita agli attacchi MITM (ad esempio phishing). Lo fa autenticando non solo l'utente, ma anche il canale, quindi sei sicuro che (a) il tuo account non può essere autenticato senza il token, e anche (b) il tuo token può essere usato solo per autenticare una connessione alla macchina a cui è collegato. Vedi questa risposta per maggiori informazioni.

36
tylerl

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

Fraintendimenti

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 SQRL che affrontano i problemi presentati in esse, mentre altre sembrano porre un'enfasi eccessiva sui difetti in SQRL che sono presenti anche in molte altre soluzioni di autenticazione esistenti ampiamente utilizzate, mentre ignorando i suoi benefici. Quindi chiariamo alcune idee sbagliate qui, vero?

Mito: SQRL richiede scansione dei codici QR per funzionare

Questo semplicemente non è vero. I codici QR sono una comodità che rende SQRL più facile da usare su computer su cui 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 originale per lo sviluppo di questo sistema sia stata uno smartphone che scansiona un codice QR sulla pagina di accesso di un sito Web, una piccola aggiunta a quel modello consente due modalità operative più significative: è sufficiente rendere l'immagine del codice QR anche un link cliccabile allo stesso URL codificato nel codice QR. Ciò comporta tre modi per accedere:

  • Scansiona il codice con uno smartphone: Utilizzando il modello sopra descritto, lo smartphone di un utente esegue la scansione del codice QR che appare sulla pagina di accesso di un sito Web e l'utente accede quel sito.
  • TOCCA IL CODICE su uno smartphone: Per accedere a un sito Web SULlo smartphone, quando il codice SQRL visivo è anche un collegamento in stile URL (usando sqrl: // come da schema) l'app SQRL installata nello smartphone riceverà quel collegamento e accederà in modo sicuro l'utente al sito sul telefono.
  • Fai clic sul codice sullo schermo di un desktop o laptop: Per utilizzare il sistema SQRL su qualsiasi sistema desktop o laptop, verrebbe installata un'applicazione desktop SQRL che verrebbe registrata stesso per ricevere sqrl: // collegamenti. (È simile al modo in cui un programma di posta elettronica registra per ricevere mailto: links.) Ciò consente agli utenti sul desktop di utilizzare la stessa soluzione che stanno utilizzando sul proprio smartphone. Quando un sito Web offre un codice SQRL, l'utente fa semplicemente clic sul codice con il cursore del mouse e verrà visualizzata l'app SQRL installata localmente, Richiedi la password SQRL, conferma il dominio e quindi effettua l'accesso.

Mito: la chiave master SQRL è memorizzata completamente non crittografata e non protetta sul telefono

Non sono sicuro del motivo per cui alcune persone hanno fatto questo assunto, poiché mi sembra ovvio che non sarebbe così. La chiave master SQRL è protetta nello stesso modo in cui proteggerebbe un database di password: con una password master sicura. Rubare il telefono di un utente non ti darebbe automaticamente accesso alla sua identità online a meno che tu non abbia anche la sua password principale. Maggiori dettagli sulla gestione delle chiavi sono spiegati nella pagina SQRL Client Key Side Management sul sito web di SQRL.

Mito: se la chiave principale viene rubata, non è possibile modificare le credenziali di accesso

Anche questo è falso. SQRL fornisce un modo integrato per consentire al titolare del conto reale di aggiornare le proprie credenziali di accesso in caso di chiave compromessa. Questa funzione è nota come Blocco identità:

"Blocco identità" impedisce la modifica dell'identità e consente il recupero: Questo è anche abbastanza significativo da meritare la sua pagina di descrizione dettagliata: " Il blocco identità protocollo "(pagina 4 nel blocco di collegamento nella parte inferiore di questa pagina.) Una volta stabilita l'identità di un utente con un server Web, il client SQRL non è impossibile per cambiare quell'identità. Ciò significa che se si verifica il peggio e viene utilizzata una password molto debole e facile da indovinare, oppure il telefono o il desktop di un utente viene violato per ottenere la chiave e la password principali dell'identità, nessuna terza parte dannosa può modificare l'identità online dell'utente per bloccarli dai propri account online. E, inoltre, caricando una "Chiave di sblocco identità" normalmente offline, il vero proprietario della propria identità può ritirarsi e sostituire la propria identità online persa o rubata per essenzialmente riprenderla da qualsiasi aggressore, rendendo inutile la sua identità precedente.

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

Va bene, quindi questo è in realtà parzialmente vero. Quando si utilizza SQRL tramite la scansione di un codice QR, la protezione contro il phishing è davvero scarsa. A meno che l'utente non stia attento a garantire che il sito Web visualizzato nella barra dell'URL del proprio browser sia uguale a quello visualizzato dall'app client SQRL, potrebbe autorizzare una sessione di accesso per l'attaccante. Questo è ancora meglio delle password, in cui darebbero al phisher l'accesso permanente al proprio account (e qualsiasi altro account che hanno altrove che condividono la stessa password) fino a quando non cambiano la password, ma non è buono come altre soluzioni che si integrano con il browser dell'utente come chiavi U2F, WebAuthn, certificati client e (a determinate condizioni) gestori password.

Tuttavia, quando si utilizza un client SQRL sullo stesso dispositivo con cui si accede, 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 . C'è anche la possibilità di integrare SQRL con i browser (possibilmente tramite plugin) per fornire una protezione molto più forte contro gli attacchi di phishing; alla pari con soluzioni come WebAuthn e certificati client.

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

Confronto con alternative

Ora confrontiamo SQRL con le soluzioni di autenticazione ampiamente utilizzate esistenti.

Le password

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

Gli svantaggi che SQRL ha rispetto alle password sono che è più difficile da implementare per gli operatori di siti Web, non così ampiamente utilizzati, richiede più tempo per la configurazione iniziale, richiede un certo sforzo per trasferire su un nuovo dispositivo e fornisce un unico punto di errore per tutti gli account dell'utente se viene rubata la chiave principale (anche se quest'ultimo punto vale anche per le password se un utente utilizza la stessa password su ogni sito).

Gestori di password

In molti modi, SQRL è molto simile ai gestori di password. Entrambi forniscono un unico ancoraggio di fiducia centralizzato che funge da sorta di proxy di autenticazione tra utenti e singoli servizi. Ci sono un paio di modi in cui SQRL è superiore ai gestori di password.

Il vantaggio principale che penso SQRL rispetto ai gestori di password è che è più facile e più sicuro da usare su computer non attendibili o solo parzialmente attendibili. Ad esempio, supponiamo che un utente desideri accedere a un sito Web utilizzando un computer in una biblioteca pubblica. Con un gestore di password, dovrebbe accedere alla password per quel sito sul suo telefono e immetterla nuovamente nel computer manualmente, oppure scaricare il suo gestore di password e il database delle password sul computer della biblioteca, sbloccare il database utilizzando la sua password principale, quindi accedere Il primo scenario è scomodo per l'utente ed espone la password in chiaro dell'utente per quel sito al computer non attendibile (e a qualsiasi malware sul computer non fidato, compresi i keylogger). Il secondo scenario è anche peggiore, poiché è sia scomodo, che espone l'intero database di password decodificato dell'utente e la password principale al computer non attendibile. Con SQRL, l'utente dovrebbe solo scansionare un codice QR sullo schermo del computer non attendibile, il che è molto più conveniente per l'utente e espone solo una singola sessione di accesso (senza credenziali riutilizzabili come una password) al computer non fidato.

Un altro vantaggio di SQRL rispetto ai gestori di password è che è più facile recuperare dallo scenario peggiore: il database delle password dell'utente/la chiave master vengono rubati. Con un gestore di password non dovresti solo cambiare la password su ogni sito, ma dovresti anche preoccuparti che l'attaccante cambi le tue password (possibilmente bloccandoti fuori dal tuo account). L'attaccante ha anche il vantaggio di possedere un elenco di tutti i siti su cui hai un account, rendendo molto più facile lo sfruttamento del furto di un database di password. Con SQRL, avere la chiave principale rubata è ancora una situazione terribile in cui trovarsi, ma l'attaccante non ha un elenco di siti su cui hai un account (devi invece indovinare) e non può cambiare la password per bloccare fuori dal tuo account. Una volta caricata la chiave di sblocco identità è anche un po 'più conveniente cambiare le credenziali di accesso su ciascun sito, poiché il client SQRL ha la possibilità di farlo automaticamente per te per ogni sito che visiti al momento dell'accesso. (Non è necessario passare attraverso alcun modulo "cambia password".)

Infine, penso che SQRL abbia un piccolo ma importante vantaggio rispetto ai gestori di password per quanto riguarda l'obiettivo di sostituire completamente le password, e cioè che i siti hanno la possibilità di imporre l'uso di SQRL rispetto alle password tradizionali. Fintanto che gli utenti avranno ancora l'opzione di scarsa sicurezza, riutilizzando la stessa password su ogni sito, ciò avverrà comunque. Se SQRL inizia ad ottenere un'adozione diffusa, i siti possono effettivamente iniziare a eliminare gradualmente l'uso delle password. Questo non può essere fatto con i gestori di password, poiché si basano sull'uso delle password per funzionare.

In termini di svantaggi, in realtà non riesco a pensare a una situazione in cui SQRL sarebbe necessariamente peggiore dei gestori di password in termini di sicurezza. Il principale svantaggio di SQRL è che richiede supporto da parte degli operatori del sito Web, mentre i gestori di password non richiedono alcun supporto speciale da parte dei servizi esistenti. Ciò significa che puoi iniziare subito a utilizzare i gestori password, ma SQRL dovrà attendere fino a quando i siti non lo implementeranno prima che possano essere utilizzati. Questa è una barriera significativa all'adozione.

Certificati del cliente

Il vantaggio principale che SQRL ha rispetto ai certificati client è uno dei vantaggi. I certificati client sono attualmente complicati da configurare, difficili da trasferire tra computer e presentano problemi di privacy quando lo stesso certificato viene utilizzato su siti diversi. Mentre teoricamente potremmo costruire un sistema usando certificati client che risolvano questi problemi, ci sarebbe anche il problema della scarsa integrazione con le UI del sito Web e i server Web, che sono problemi più difficili da risolvere. Non entrerò in troppi dettagli qui, poiché c'è già un eccellente articolo sulle questioni di usabilità dei certificati client su browserauth.net.

In termini di sicurezza, i certificati client presentano lo svantaggio di richiedere il coinvolgimento di un'autorità di certificazione. Questo è (potenzialmente) costoso e richiede fiducia nell'autorità di certificazione di terze parti. Inoltre, se si sceglie di ignorare le autorità di certificazione e invece di autofirmare i propri certificati, è necessario affrontare il problema della revoca dei certificati. I certificati client presentano inoltre gli stessi problemi di sicurezza e convenienza dei gestori password quando gli utenti desiderano accedere a un computer non attendibile; devono trasferire il loro certificato sul computer non attendibile, il che è al contempo scomodo e potenzialmente espone la loro identità principale al malware su quel computer.

In breve, fino a quando qualcuno non troverà una soluzione migliore e user-friendly utilizzando i certificati client che risolvono (almeno la maggior parte di) questi problemi, non credo che i certificati dei clienti siano un serio concorrente di SQRL (o, del resto, di Le password).

Autenticazione a 2 fattori

Ho solo pensato di menzionarlo: SQRL e l'autenticazione a 2 fattori sono no si escludono a vicenda. SQRL è un sostituto del primo fattore in 2FA: le password. Altre misure aggiuntive come codici OTP o chiavi FIDO U2F possono ancora essere utilizzate con SQRL.

WebAuthn

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

È qui che SQRL finalmente incontra la sua corrispondenza, almeno dal punto di vista della sicurezza. WebAuthn non offre solo 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 pari quando si autorizza un accesso sessione per un PC su cui l'utente non ha precedentemente impostato il software client dell'autenticatore. Ciò è possibile perché in tale situazione WebAuthn comunica direttamente con il browser dell'utente utilizzando protocolli di comunicazione bidirezionali come Blutooth o NFC invece di comunicare con il sito Web che l'utente utilizza tramite un codice QR unidirezionale.

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

Altre considerazioni minori includono il fatto che SQRL ha un metodo incorporato per ruotare le chiavi degli account in caso di una chiave master rubata, mentre WebAuthn si affida ai siti Web per implementare il proprio sistema per revocare le chiavi e il fatto che WebAuthn richiede determinate hardware opzionale (come Bluetooth o NFC) per l'autenticazione su una macchina remota, mentre SQRL può funzionare su qualsiasi macchina con un display funzionante.

Nel complesso, penso sia molto probabile che WebAuthn alla fine renderà obsoleto SQRL. SQRL potrebbe avere un po 'di respiro per ora, ma WebAuthn ha un supporto molto più forte da fornitori di browser, operatori del sito e altre organizzazioni di terze parti (come il W3C). Una volta che WebAuthn avrà un paio di implementazioni che ne consentiranno l'utilizzo come fattore di autenticazione principale, mi aspetto che inizierà a prendere il controllo del Web molto rapidamente.

Avvertenze

SQRL è ancora in fase di sviluppo attivo, quindi il materiale presentato in questa risposta è soggetto a modifiche. Mentre lo sviluppo continua, mi aspetto che verranno affrontate alcune delle vulnerabilità e delle incertezze in questa risposta. La maggior parte della discussione è attualmente in corso sul newsgroup SQRL su grc.com.

16
Ajedi32

SQRL è una soluzione conveniente al problema del paradosso nome utente/password. (ovvero il compromesso convenienza/sicurezza) senza utilizzare una terza parte . Fornisce una semplice alternativa al modello di autenticazione più popolare (nome utente e password), con virtualmente nessun compromesso per la sicurezza. È praticamente altrettanto sicuro di tutti i comuni modelli di autenticazione usati oggi, fintanto che sei ancora consapevole della sicurezza . Se stai usando SQRL, ciò non significa che non puoi seguire le migliori pratiche di sicurezza come combinando questo con l'autenticazione a più fattori per account importanti.

È importante non perdere il punto di SQRL. Lo stesso SQRL non fornisce necessariamente una sicurezza migliore o peggiore. Se il computer/telefono stesso viene compromesso o l'utente viene ingannato per essere phishing, allora questo è un attacco del canale laterale invece di un errore diretto dello stesso SQRL. Ogni metodo di autenticazione convenzionale presenta questo problema di attacchi del canale laterale Il pad one-time infrangibile è anche vulnerabile agli attacchi del canale laterale come il compromesso del pad stesso, o cattiva sicurezza o implementazioni circostanti.

Se hai ascoltato la proposta originale dell'idea sul podcast di Steve Gibson, seguita dalle Domande e risposte, molte delle preoccupazioni sollevate su questo thread dello stack hanno ricevuto risposta. Inoltre, Steve ha affermato così che questa idea molto "semplice" e "geniale" (le sue parole) avrebbe bisogno di essere "controllata" e "martellata" dagli esperti di sicurezza, come solo il tempo dirà se questa è una soluzione sicura.

In conclusione, la maggior parte degli argomenti contro SQRL non rientra nel dominio dello stesso SQRL, e invece sono problemi con gli umani che praticano scarsa sicurezza. SQRL non introduce una nuova classificazione dei problemi che i nostri metodi di autenticazione tradizionali già non hanno.

SQRL è eccellente se utilizzato in modo appropriato da persone sensibili alla sicurezza. Devi capire che c'è sempre un compromesso tra convenienza e sicurezza e questa soluzione è probabilmente la migliore equilibrio dei due che ho visto.

12
ansichart

Concordo con gli altri commenti in una certa misura, ma penso che ci siano alcuni meriti:

Per abilitare SQRL per te, devi creare la tua chiave principale e memorizzarla sul tuo telefono. FATTO. Da quel momento, sarai in grado di accedere a QUALUNQUE sito Web che utilizza "SQRL". E quello sarebbe un accesso anonimo - purché tu decida di non fornire ulteriori informazioni.

Questo è MOLTO più semplice che lavorare con il proprio certificato; o creando account utente espliciti (probabilmente chiedendoti di fornire un indirizzo email valido). Forse non userei la stessa chiave principale per i miei conti bancari, Amazon, ... - ma soprattutto per queste situazioni "mi piacerebbe pubblicare qualcosa qui" ... perfetto. Non più "per favore, lascia che google o facebook o qualunque sito sappiano che vuoi pubblicare qui".

9
Elton

SQRL non offre miglioramenti rivoluzionari. I codici QR sono un formato di codice a barre ottico utile per una breve distribuzione dei contenuti - niente di più.

Qualsiasi situazione di "accesso automatico" che SQRL sta cercando di risolvere potrebbe semplicemente utilizzare un certificato client archiviato sul dispositivo mobile.

Ipoteticamente un codice a barre QR su una pagina HTTPS could restituisce una versione firmata o crittografata del certificato client (o credenziali simili) come precedentemente noto dal server, ma perché? Per scadenza credenziali? Il sito potrebbe semplicemente rifiutare direttamente una credenziale scaduta.

Quindi il più grande problema di sicurezza che ho con questo protocollo è: Reinventing the Square Wheel .


Update

Leggendo nuove risposte e commenti, vorrei sottolineare quanto sia facile fare qualcosa di simile a SQRL attraverso una semplice automazione di tecnologia esistente esistente:

  1. Il sito Web chiede eventuali CAPTCHA o simili "Sono un essere umano" di verifica. Una volta che l'utente ha rispettato (POSTATO), il sito Web restituisce un HTTP 403.7 - Client Certificate Required o un errore Vanilla 403.
  2. Le 403 pagine personalizzate sono abbastanza facili da configurare e possono essere piuttosto carine e facili da usare. Potrebbe anche bootstrap la funzionalità richiesta di seguito in un modo simile alle istruzioni "Adobe Reader richiesto" su molti siti Web.
  3. La pagina 403 personalizzata include alcuni markup a cui reagisce un plug-in del browser personalizzato. Chiamiamo questo plug-in personalizzato "conforme S403L" nello spirito della "conformità SQRL".
  4. Il plug-in S403L genera un certificato client standard, che è protetto nella solita cache cert crittografata del browser (o una cache di terze parti se la crittografia del keystore del browser fa schifo). Il plug-in crea un CSR standard per il certificato client e invia il CSR all'URL specificato nel markup 403. (per esempio. <s403l ref="https://www.example.com/S403L" />)
  5. Il server conforme S403L utilizza session_id dell'utente (recuperato da cookie o stringa di query) per creare continuità con il passaggio 1 e quindi restituisce il CSR come firmato dal server. L'autenticazione generale del server accetterà qualsiasi certificato client che è stato firmato dal server (e quindi soddisfatto i criteri di registrazione richiesti nel passaggio 1).
  6. Il plug-in S403L memorizza il certificato client firmato nella cache del browser. Da quel momento in poi, il browser standard senza assistenza plug-in può "accedere automaticamente" al server secondo lo standard SSL/TLS fino alla scadenza del certificato.

La natura "mobile" e "visiva" di SQRL è una sorta di indirizzo errato in quanto non fornisce un'autenticazione a due fattori distaccata e ora sono necessari due computer per navigare in Internet anziché uno. A meno che non si punti la webcam USB del desktop sul proprio monitor.

I compromessi tra password e certificati sono ben definiti nella comunità della sicurezza: le password si adattano a un cervello umano; i certificati non rientrano in un cervello umano ( di solito ) ma possono avere entropia pazza e buone funzionalità di gestione della PKI (scadenza, revoca, estensioni delle politiche, ecc.). SQRL si adatta perfettamente a nessuno dei due campi; e se si sta spostando verso il campo più umano meno umano come sembra - ha anni di sviluppo e analisi di sicurezza per ripetere le funzionalità X.509 esistenti.

6
LateralFractal

Vorrei porre la prima domanda: "uno dei problemi a cui riesco a pensare è se il lettore QR è compromesso, per visualizzare www.google.com anziché www.nsa-super-secret-place.gov/123" :

La chiave master viene utilizzata come seed in HMAC insieme all'indirizzo del sito Web (FQDN). Pertanto, sebbene il codice QR possa codificare un URL completamente diverso, il protocollo NON rivelerà il codice di autenticazione che verrebbe normalmente inviato a www.google.com (nell'esempio).

In secondo luogo, molti dei partecipanti dimenticano gli obiettivi chiave quando elaborano questa idea:

  1. anonimato non utilizzando terze parti
  2. facilità d'uso
  3. non è necessario digitare credenziali segrete su computer non attendibili

Credo che i protocolli li affrontino per intero!

Tuttavia, ci sono compromessi che in realtà provengono dal primo obiettivo. Se nell'autenticazione non sono coinvolte terze parti, come si possono revocare i dettagli dell'autenticazione? Inoltre, la sicurezza della chiave principale è una preoccupazione ovvia. Immagino che questo sarà ben protetto dai futuri dispositivi mobili in un chip HSM come. Fino ad allora, la chiave è solo un dispositivo mobile pin file, protetto da una password, sebbene PBDKF2 assicuri che è molto lento forzarlo effettivamente.

4
Vladimir Jirasek