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

Diamo uno sguardo alla descrizione di Gibson del suo protocollo.

• Il codice QR presentato vicino al login prompt contiene lURL del servizio di autenticazione per il sito. LURL 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”.

• Lapp di autenticazione SQRL dello smartphone esegue lhashing crittografico del nome di dominio del sito con la chiave dellutente “s master key per produrre una coppia di chiavi pubbliche specifiche del sito.

• Lapplicazione firma crittograficamente lintero URL contenuto nel codice QR utilizzando la chiave privata specifica del sito. Poiché lURL include un numero casuale lungo protetto (il nonce), la firma è univoca per quel sito e per il codice QR.

• Lapp invia una query POST HTTPS sicura al QR URL del codice, che è il servizio di autenticazione per il sito. Il POST fornisce la chiave pubblica specifica del sito e la firma crittografica corrispondente dellURL del codice QR.

• Il sito Web di autenticazione riceve e riconosce la query POST restituendo un HTTP standard “200 OK” senza altri contenuti. Lapp SQRL riconosce lavvenuto invio del codice QR firmato dallutente.

• Il sito di autenticazione ha lURL contenente il nonce che è tornato dalla pagina di accesso tramite lutente “s ha anche una firma crittografica di quellURL e la chiave pubblica specifica del sito dellutente. Utilizza la chiave pubblica per verificare che la firma sia valida per lURL. Ciò conferma che lutente che ha prodotto la firma ha utilizzato la chiave privata corrispondente alla chiave pubblica. Dopo aver verificato la firma, il sito di autenticazione riconosce lutente ora autenticato tramite la chiave pubblica specifica del sito.

Il La cosa più importante che mi viene in mente è luso di una ” chiave principale ” da parte dellutente. Se leggo correttamente il protocollo, quella singola chiave master controlla lintera identità online dellutente …

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

Quindi confrontiamo la differenza tra ciò che accade quando una password viene compromessa e ciò che accade quando la chiave principale viene compromesso. 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 tua chiave principale viene compromessa? dovrà in qualche modo ottenere tutti i siti con cui ti sei autenticato per riconoscere che la tua chiave principale è stata compromessa. Lunico problema è che non hai altri mezzi per autenticarti con il sito come nomi utente o indirizzi email, come farà il sito a sapere che in effetti sei tu che stai tentando di revocare la chiave principale?

Come tutto ciò che esce da Gibson, questo schema SRQL è altamente viziato e non offre vantaggi rispetto ai tradizionali metodi.

Comme nts

• ” Se ‘ segui buone pratiche per la password ” è un enorme avvertimento e la maggior parte dei Netizen ‘ non lo fa.Parte della promessa di SQRL ‘ è di ridurre la ‘ necessità degli utenti di rimanere al passo con le best practice. Inoltre, la specifica SQRL richiederà che la chiave principale venga archiviata crittografata con una password principale e sarà impossibile eseguire la forza bruta (ottimizzata per richiedere ~ 60 secondi per un tentativo). Ottenere la password sarà spesso non banale poiché SQRL promuove lautenticazione fuori banda (cioè, il keylogging di una macchina hackerata non ‘ ti aiuterà sempre). Pertanto, sebbene le conseguenze di una compromissione completa siano elevate, la probabilità di una compromissione è piuttosto bassa.
• SQRL potrebbe ancora presentare difetti che devono essere risolti, ma afferma di risolvere una serie di problemi riscontrati negli approcci esistenti allautenticazione e qualsiasi critica allSQRL che lo afferma ” non offre vantaggi ” dovrebbe includere confutazioni di queste affermazioni invece di aspettarsi che laffermazione venga accettata ciecamente.
• > Come tutto ciò che viene da Gibson , questo schema SRQL è altamente difettoso e non offre vantaggi rispetto ai metodi convenzionali. — Questo ‘ non sembra aiutare a rispondere alla domanda, e in realtà penso che tu abbia problemi con la tecnologia a causa di chi lha inventata. Alcuni dei punti che hai menzionato come difetti vengono effettivamente risolti dalle ” spec “. Ad esempio, lo stesso SQRL non ‘ menziona come viene memorizzata la chiave principale, ma i commenti di Steve Gibson ‘ sono che un cellulare client, ad esempio, la crittograferebbe con una password principale utilizzando uno scrypt che richiede in media 60 secondi per lesecuzione.
• Gibson risolve esplicitamente la protezione della chiave principale.
• secondo. Identifichi il furto della tua chiave principale SQRL con il furto di una delle tue chiavi LastPass. ‘ non sarebbe unanalogia migliore equipararlo al furto di tutto il tuo database di password LastPass decrittografato ?

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 non . Ma esaminiamo i pro e i contro:

Vantaggi

È impossibile ” condividere ” una password nel senso stretto che un sito web dannoso non può” utilizzare lautenticazione 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 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. Tuttavia, non sei protetto da alcun tipo di dirottamento di sessione o attacchi di controllo 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 allingegneria sociale. Probabilmente più di qualsiasi altro schema di autenticazione in uso, comprese le password. La fase di autenticazione e la fase di avvio dellaccesso sono intrinsecamente disconnesse, nel senso che il telefono si autenticherà correttamente rispetto a qualsiasi codice QR presentato, indipendentemente da come o dove viene presentato allutente.

Quindi, ad esempio, un sito di phishing può visualizzare un codice QR di accesso autentico che accede allautore dellattacco invece che allutente. Gibson è certo che gli utenti vedranno il nome della banca, del negozio o del sito sullapp del telefono durante lautenticazione e quindi eserciteranno una vigilanza sufficiente per contrastare gli attacchi. La storia suggerisce che ciò sia improbabile e laspettativa più ragionevole è che vedere il nome corretto sullapp rassicurerà falsamente lutente facendogli pensare che il sito sia legittimo perché è stato in grado di attivare la familiare richiesta di accesso sul telefono. La cautela già espressa nella testa degli utenti riguardo alla sicurezza delle password non si traduce necessariamente in nuove tecniche di autenticazione come questa, che è ciò che rende questa app probabilmente meno resistente allingegneria sociale.

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

Questa tecnica combina tutti i tuoi token di autenticazione in ununica chiave a meno che tu non ne crei altri manualmente. Questo rende la tua chiave un bersaglio extra succoso per gli attaccanti. Inoltre, la chiave è memorizzata sul tuo 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

Laspetto più problematico di questo schema è la scarsa comparazione con le alternative disponibili.

Lopzione oggi universalmente accettata più sicura è lastpass, keepass e altri sistemi di password integrati nel browser. In particolare, la crittografia lato client riduce la necessità di fidarsi di terze parti. E, cosa più importante, lintegrazione del browser rende il phishing praticamente impossibile . LastPass o KeePass riempiranno la password solo se serviti dal dominio corretto, il che significa che se presentato con un sito dannoso, lutente non avrà accesso alla sua password.

Inoltre, LastPass ha recentemente aggiunto una funzione che sollecita gli utenti a cambiare password che non sono univoche a livello globale. Ciò 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 su siti esistenti, senza linsicurezza aggiuntiva che il suo schema implica.

Gli schemi di autenticazione a secondo fattore esistenti che utilizzano telefoni o dispositivi simili aiutano a proteggere gli accessi degli utenti oggi lo fanno già in modo tale da non renderti immediatamente vulnerabile al furto di identità se il tuo dispositivo viene rubato. la sicurezza dellautenticazione a due fattori sta nel fatto che né il dispositivo né la password possono essere utilizzati se rubati senza laltro. La tecnica di Gibson è ampiamente resistente allinclusione in uno schema a due fattori, il che rende questo livello di protezione zione 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 dello schema stesso e probabilmente non possono essere risolti senza scartare lintero progetto.

Si potrebbe sostenere che è meglio di niente, ma non si può 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 delle principali critiche. La loro protezione è questa: se NON stai utilizzando i codici QR, il telefono cellulare, ecc. E invece hai un agente di autenticazione sul tuo sistema (nel browser, ad esempio), il server può verificare che lautenticazione la risposta proviene dallo stesso IP della richiesta di autenticazione. Questo va bene, ma lo scopo di questo protocollo è trasferire la tua identità sul tuo telefono cellulare. Se lunico modo sicuro per utilizzare il protocollo è non usarlo core caratteristica, allora forse dovremmo ripensare a ciò che stiamo cercando di realizzare.

Teoricamente potresti continuare a utilizzare 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 lindirizzo IP del tuo computer.

Una soluzione migliore

Come affermato in precedenza, se la misura di autenticazione è nel browser, , lintero problema di phishing viene immediatamente risolto senza alcuno sforzo o verifica da parte di lutente. Anche lutente meno capace non può “essere indotto con linganno ad autenticarsi sul sito sbagliato perché” il token di autenticazione del sito è associato al nome di dominio e il browser ha vinto ” t consentire lautenticazione al dominio sbagliato. Questa è una tecnica già in uso oggi, è completamente automatica, e non richiede la collaborazione del sito né alcuna intelligenza da parte dellutente.

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

Per quanto riguarda le preoccupazioni relative al fatto che lautenticazione lato browser sia vulnerabile agli attacchi client-workstation: sebbene sia vero, è anche vero che se il tuo browser è compromesso, allora no lutilizzo di quel browser è sicuro , indipendentemente dal meccanismo di autenticazione utilizzato.Gli autori di malware possono (e lo fanno già) attendere che tu ti autentichi da solo utilizzando la tua tecnica super sicura, quindi inviare silenziosamente il traffico necessario a ” proprietario ” il tuo account, il tutto senza che tu veda nulla di sbagliato. Né SQRL né alcun altro sistema di autenticazione possono proteggere lutente di un browser compromesso, così come le serrature possono proteggerti da un incendio domestico. Lacquisto di serrature ignifughe non è una soluzione.

Where Next

Se “stai cercando una garanzia assoluta di protezione dal furto didentità , quindi guarda il token Fido U2F. Questo standard brilla dove SQRL non è allaltezza e ti dà limmunità garantita agli attacchi MITM (ad esempio phishing). Lo fa autenticando non solo lutente, ma anche il canale, quindi tu “È garantito che (a) il tuo account non può essere autenticato senza il token, e anche (b) il tuo token può essere utilizzato solo per autenticare una connessione alla macchina a cui è collegato. Vedi questa risposta per ulteriori informazioni.

Commenti

• Informazioni sul primo punto : per quanto ho capito, questo è stato pensato e unopzione è lasciare che il sito Web su cui ti stai autenticando sia responsabile del reindirizzamento. Quindi, dopo il login, verrai reindirizzato alla pagina ‘ della banca reale, non allaggressore. Riguardo al secondo punto, lo stesso accade oggi con gli utenti di strumenti come LastPass. A meno che non imposti un meccanismo di protezione (PIN, ad esempio), anche tutte le tue password vengono rubate. Perché ‘ non può valere lo stesso per SQRL? Inoltre, per quanto ho capito dalle specifiche, lutente può eseguire il backup della propria identità anche su carta (come codice QR).
• E circa il terzo punto: lo stesso accade con la maggior parte degli utenti che non ‘ t utilizzare un gestore di password, semplicemente utilizzando un unico nome utente / password in diversi siti web. Oppure, con gli utenti di gestori di password, la cui ” identità ” è distribuita su diversi siti web, ma memorizzata in ununica posizione (LastPass ‘ server, database 1Password e così via). Quindi, ‘ non è proprio un difetto SQRL. Tutto sommato, più leggo di SQRL, più ne vedo i vantaggi rispetto alle alternative attuali. Diciamo che parli di Steve Gibson, ma SQRL mi sembra davvero una buona alternativa.
• ” La cautela già battuta in testa a gli utenti per quanto riguarda la sicurezza delle password non si traducono necessariamente in nuove tecniche di autenticazione come questa. . . ” Questo è un punto eccellente e la battaglia è già stata persa per il marketing. I codici QR sono visti come un modo semplice per fare le cose, non come un potenziale vettore di attacco. Le coppie nome utente / password almeno sono state utilizzate PRIMA come meccanismo di autenticazione, non come strumento di marketing.
• @jpkrohling: per quanto riguarda i gestori di password, immagino che la maggior parte degli utenti di tale software NON memorizzi la propria password principale sul loro dispositivo mobile, proprio perché sono consapevoli di quanto sia pericoloso. Ho una copia fisica della mia password principale in un luogo sicuro, ma nessuna copia elettronica. Gli attacchi che concederebbero laccesso alla mia password principale sono diversi da quelli che comprometterebbero la password di un sito e sono molto meno probabili. (Principalmente perché attaccare il mio database di password implicherebbe attaccare me personalmente, piuttosto che un grande sito compromesso.)
• @jpkrohling Né LastPass né KeePass memorizzano una password principale da nessuna parte. ‘ è utilizzato per sbloccare il database delle password, ma ‘ non viene memorizzato. Questo è fondamentalmente diverso dallavere ununica chiave che è essa stessa utilizzata ovunque.

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

Idee sbagliate

Per prima cosa, lasciatemi chiarire alcune delle idee sbagliate presenti in alcune delle altre risposte su questa domanda. Molte di queste risposte sono obsolete e sono state scritte prima delle modifiche alla documentazione SQRL che risolvono i problemi presentati in essi, mentre altri sembrano porre unenfasi eccessiva sui difetti nellSQRL che sono presenti anche in molte altre soluzioni di autenticazione esistenti ampiamente utilizzate, ignorandone i vantaggi. Quindi chiariamo qui alcuni malintesi. noi?

Mito: SQRL richiede la scansione dei codici QR per funzionare

Questo semplicemente non è vero. I codici QR sono una comodità il che rende SQRL più facile da usare sui computer sui quali lutente non ha configurato il software client SQRL. Il sito web di SQRL “afferma quanto segue:

Tre modi per andare…smartphone opzionale:

Sebbene lispirazione originale per lo sviluppo di questo sistema fosse uno smartphone che scansiona un codice QR sulla pagina di accesso di un sito web, una piccola aggiunta a quel modello consente due modalità di funzionamento più significative: Semplicemente rendere l immagine del codice QR anche un collegamento cliccabile allo stesso URL codificato nel codice QR. Ciò offre tre modi per accedere:

• Scansiona il codice con uno smartphone: Utilizzando il modello descritto sopra, lo smartphone di un utente esegue la scansione del codice QR che appare sulla pagina di accesso di un sito web e lutente ha effettuato laccesso a 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 (utilizzando sqrl: // come schema) il Lapp SQRL installata nello smartphone riceverà il collegamento e accederà in modo sicuro lutente al sito sul telefono.
• Fare clic sul codice sullo schermo di un desktop o laptop : Per utilizzare il sistema SQRL su qualsiasi sistema desktop o laptop, verrà installata unapplicazione SQRL desktop che si registrerà per ricevere i collegamenti sqrl: //. (Questo è simile al modo in cui un programma di posta elettronica si registra per ricevere mailto: links.) Ciò consente agli utenti sul desktop di utilizzare la stessa soluzione che utilizzano sui loro smartphone. Quando un sito Web offre un codice SQRL, lutente fa clic sul codice con il cursore del mouse e verrà visualizzata lapp SQRL installata localmente, che richiede la password SQRL, conferma il dominio e quindi effettua il login.

Mito: la chiave principale SQRL è archiviata completamente non crittografata e non protetta sul tuo telefono

Non sono sicuro del motivo per cui alcune persone lo hanno fatto presupposto, poiché mi sembra ovvio che non sarebbe così. La chiave principale SQRL è protetta più o meno nello stesso modo in cui si protegge un database di password: con una password principale complessa. Il furto del 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 su SQRL Client- Side Key Management sul sito web di SQRL.

Mito: se la tua chiave principale viene rubata, non puoi modificare le tue credenziali di accesso

Anche questo è falso. SQRL fornisce un modo integrato per consentire al titolare dellaccount autentico di aggiornare le proprie credenziali di accesso in caso di chiave compromessa. Questa funzione è nota come Identity Lock:

“Identity Lock” impedisce la modifica dellidentità & consente il ripristino: Questo è anche abbastanza significativo da meritare la sua pagina di descrizione dettagliata: “ Il protocollo di blocco dellidentità ” (pagina 4 nel blocco di link in fondo a questa pagina). lidentità dellutente è stata stabilita con un server web, lSQRL c lient non è in grado di modificare tale identità. Ciò significa che se è accaduto il peggio ed è stata utilizzata una password molto debole e facilmente indovinata, o il telefono o il desktop di un utente è stato violato per ottenere la chiave principale e la password dellidentità, nessun terzo malintenzionato può modificare lidentità online dellutente per bloccarlo dai propri account online. Inoltre, caricando una “chiave di sblocco dellidentità” normalmente offline, il vero proprietario della propria identità può ritirarsi e sostituire la propria identità online persa o rubata essenzialmente riprenderla da qualsiasi utente malintenzionato, rendendo inutile la loro identità precedente.

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

Ok, quindi in realtà è parzialmente vero. Quando si utilizza SQRL mediante la scansione di un codice QR, la protezione contro il phishing è davvero minima. A meno che lutente non stia attento a garantire che il sito web mostrato nella barra degli indirizzi del browser sia uguale a quello visualizzato dallapp SQRL Client, potrebbe autorizzare una sessione di accesso per laggressore. Questo è comunque meglio delle password, dove darebbero al phisher un accesso permanente al proprio account (e a qualsiasi altro account che hanno altrove che condividono la stessa password) fino a quando non cambiano la password, ma non sono altrettanto buone di altre soluzioni che si integrano con il browser dellutente come le chiavi U2F , WebAuthn, certificati client e (in determinate condizioni) gestori di password.

Tuttavia, quando si “utilizza un client SQRL sullo stesso dispositivo con cui si sta effettuando laccesso, SQRL dispone di alcune protezioni contro phishing in atto. 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 plug-in) per fornire una protezione molto più forte contro gli attacchi di phishing; alla pari con soluzioni come WebAuthn e certificati client.

Nel complesso ho classificato SQRL su più o meno 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 lutente sta accedendo, 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.

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 ridigitare più password diverse per ogni sito, ma protegge anche dal riutilizzo delle password, da password deboli, dal keylogging e, in una certa misura, dal phishing.

Svantaggi SQRL rispetto alle password è che è più difficile da implementare per gli operatori di siti web, non così ampiamente utilizzato, richiede più tempo per la configurazione iniziale, richiede un certo sforzo per il trasferimento su un nuovo dispositivo e fornisce un unico punto di errore per tutti gli account degli utenti se la chiave principale viene rubata (anche se questultimo 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 unico trust anchor 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 abbia SQRL sui gestori di password è che è più facile e più sicuro da usare su computer non affidabili o solo parzialmente affidabili. 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 digitarla manualmente nel computer oppure scaricare la sua password manager e database delle password sul computer della biblioteca, sbloccare il database utilizzando la sua password principale, quindi accedere. Il primo scenario è scomodo per lutente ed espone la password in chiaro dellutente per quel sito al computer non attendibile (ea qualsiasi malware sul computer non attendibile, inclusi i keylogger). Il secondo scenario è anche peggiore, in quanto è scomodo ed espone lintero database delle password decrittografato e la password principale dellutente al computer non attendibile. Con SQRL, lutente dovrebbe solo scansionare un codice QR sullo schermo del computer non attendibile, il che è molto più conveniente per lutente ed espone solo una singola sessione di accesso (senza credenziali riutilizzabili come una password) al computer non attendibile .

Un altro vantaggio di SQRL rispetto ai gestori di password è che è più facile recuperare dallo scenario peggiore: il database delle password dellutente / la chiave principale vengono rubati. Con un gestore di password non lo faresti devi solo cambiare la tua password su ogni sito, dovresti anche preoccuparti che lattaccante cambi le tue password (possibilmente bloccandoti fuori dal tuo account). Laggressore ha anche il vantaggio di possedere un elenco di tutti i siti che hai un account, rendendo molto più semplice lo sfruttamento del furto di un database di password. Con SQRL, il furto della chiave principale è ancora una situazione terribile, ma laggressore non ha un elenco di siti su cui si dispone di un account (dovendo invece indovinare ) e non è possibile modificare la password per bloccarti del tuo account. Una volta caricata la chiave di sblocco dellidentità, è anche un po più comodo modificare le credenziali di accesso su ciascun sito, poiché il client SQRL ha la capacità di farlo automaticamente per ogni sito che visiti al momento dellaccesso (non è necessario andare attraverso qualsiasi modulo di “modifica della password”.)

Infine, penso che SQRL abbia un piccolo ma importante vantaggio rispetto ai gestori di password per quanto riguarda lobiettivo di sostituire completamente le password, e cioè che i siti hanno la possibilità di applicare uso di SQRL rispetto alle password tradizionali. Finché gli utenti hanno ancora la possibilità di una scarsa sicurezza, riutilizzando la stessa password su ogni sito, questo è qualcosa che accadrà ancora. Se SQRL inizia a ottenere unadozione diffusa, i siti possono effettivamente iniziare a eliminare gradualmente luso di password. Questo non può essere fatto con i gestori di password, poiché si basano sulluso di password per funzionare.

In termini di svantaggi, in realtà non riesco a pensare a una situazione in cui SQRL sarebbe necessariamente peggio dei gestori di password in termini di sicurezza. Lo svantaggio principale di SQRL è che richiede il supporto degli operatori di siti Web, mentre i gestori di password non richiedono alcun supporto speciale dai servizi esistenti. Ciò significa che puoi iniziare a utilizzare i gestori di password in questo momento, ma SQRL dovrà attendere che i siti lo implementino prima di poterlo utilizzare. Questa è una barriera significativa alladozione.

Certificati client

Il vantaggio principale di SQRL rispetto ai certificati client è di convenienza. 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. Sebbene teoricamente potremmo costruire un sistema utilizzando i certificati client che risolverebbero questi problemi, ci sarebbe anche il problema di una scarsa integrazione con le interfacce utente e i server web, che sono problemi più difficili da risolvere. Non entrerò troppo nei dettagli qui, poiché esiste già un eccellente articolo sui problemi di usabilità dei certificati client su browserauth.net.

In termini di sicurezza, i certificati client hanno lo svantaggio di richiedere il coinvolgimento di una CA. Questo è (potenzialmente) costoso e richiede la fiducia della CA di terze parti. Inoltre, se scegli di ignorare le CA e invece di firmare autonomamente i certificati, devi affrontare il problema della revoca del certificato. I certificati client presentano inoltre gli stessi problemi di sicurezza e comodità dei gestori di password quando gli utenti desiderano accedere a un computer non attendibile; devono trasferire il certificato al computer non attendibile, il che è sia scomodo che potenzialmente espone la loro identità principale al malware su quel computer.

In breve, finché qualcuno non troverà una soluzione migliore e user-friendly utilizzando certificati client che risolvono (almeno la maggior parte di) questi problemi, non credo che i certificati client siano un serio concorrente di SQRL (o, se è per questo, di password).

Autenticazione a 2 fattori

Ho solo pensato di menzionare questo: SQRL e lautenticazione a 2 fattori non si escludono a vicenda. SQRL è un sostituto per il primo fattore in 2FA: le password. Altre misure aggiuntive come i codici OTP o le chiavi FIDO U2F possono ancora essere utilizzate con SQRL.

WebAuthn

Ora qui “s dove le cose si fanno interessanti. WebAuthn è un nuovo standard W3C (beh, più recente di SQRL) progettato per fornire unAPI standard che i siti Web possono utilizzare per autenticare gli utenti con chiavi pubbliche sul Web. Proprio come SQRL, supporta utilizzando il telefono dellutente per autenticare una sessione di accesso su un dispositivo esterno , oltre ad alcuni altri metodi di autenticazione (come le chiavi di sicurezza del secondo fattore) .

È qui che SQRL incontra finalmente la sua corrispondenza, almeno dal punto di vista della sicurezza. WebAuthn non solo fornisce le stesse protezioni contro il riutilizzo delle password, password deboli e keylogging di SQRL, ma fornisce anche una protezione ancora più forte contro il phishing integrandosi con il browser dellutente anche quando si autorizza un accesso sessione per un PC su cui lutente non ha precedentemente configurato il software client dellautenticatore. Ciò è possibile perché in quella situazione WebAuthn comunica direttamente con il browser dellutente utilizzando protocolli di comunicazione a due vie come Blutooth o NFC invece comunicando con il sito web che lutente sta utilizzando tramite un codice QR unidirezionale.

Dal punto di vista dellusabilità, le cose sono un po più complicate. Almeno in superficie, WebAuthn vince ancora. Perché è uno standard W3C che ha già implementazioni in più browser , in teoria gli utenti possono iniziare immediatamente a utilizzare WebAuthn senza la necessità di installare alcun 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 ri-autenticare un utente che ha eseguito laccesso in precedenza sullo stesso dispositivo tramite un metodo di accesso diverso (di solito una password). Come fattore di autenticazione principale, WebAuthn è ancora piuttosto carente di implementazioni praticabili.

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

Nel complesso, penso che sia molto probabile che WebAuthn alla fine renderà SQRL obsoleto. SQRL può avere un po di respiro per ora, ma WebAuthn ha un sostegno molto più forte da parte di fornitori di browser, operatori di siti e altre organizzazioni di terze parti (come il W3C). Una volta che WebAuthn avrà un paio di implementazioni che ne consentiranno luso 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 alcune delle vulnerabilità e delle incertezze in questa risposta verranno affrontate. La maggior parte della discussione è attualmente in corso nel newsgroup SQRL su grc.com.

SQRL è una comoda soluzione al problema del nome utente / password paradox. (ovvero il compromesso tra convenienza e sicurezza) senza utilizzare . Fornisce una semplice alternativa al modello di autenticazione più diffuso (Username & Password), senza virtualmente alcun compromesso per la sicurezza. È praticamente altrettanto sicuro di qualsiasi modello di autenticazione comune utilizzato oggi, fintanto che sei ancora attento alla sicurezza . Se utilizzi SQRL, non significa che non puoi seguire le migliori pratiche di sicurezza come che combina questo con lautenticazione a più fattori per account importanti.

È importante non perdere il punto di SQRL. SQRL in sé non fornisce necessariamente una sicurezza migliore o peggiore. Se il computer / telefono stesso viene compromesso o lutente viene indotto con linganno essendo phishing, questo è un attacco di canale laterale invece di un errore diretto dello stesso SQRL. Ogni metodo di autenticazione convenzionale presenta questo problema di attacchi di canale laterale Il pad unico è vulnerabile anche agli attacchi di canale laterale come il compromesso del pad stesso, o cattiva sicurezza circostante o implementazioni.

Se hai ascoltato la proposta originale dellidea su Steve Gibson “s podcast , seguito dalla Q & A “s, molte delle preoccupazioni sollevate in questo thread dello stack hanno ricevuto risposta. Inoltre, Steve stesso ha detto che questa idea molto “semplice” e “geniale” (le sue parole) avrebbe bisogno di essere “vagliata” e “martellata” da esperti di sicurezza, poiché solo il tempo dirà se questa è una soluzione sicura.

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

SQRL è eccellente se utilizzato in modo appropriato da persone attente alla sicurezza. Devi capire che cè sempre un compromesso tra comodità e sicurezza e questa soluzione è probabilmente la miglior equilibrio dei due che ho visto.

Commenti

• Grazie Ansichart. Ma le soluzioni di autenticazione esistenti possono ‘ mantenere semplicemente caratteristiche di sicurezza uguali o superiori a SQRL e quindi utilizzare lautomazione per aumentare la comodità dellutente? Quale proprietà fondamentale della comodità per lutente di SQRL ‘ non è dovuta allautomazione? Chiedo perché se un utente ha due scatole nere che fanno la stessa cosa; uno con letichetta ” Maturo ” e laltro con letichetta ” SQRL ” e possono essere entrambi progettati / automatizzati hanno la stessa interfaccia / pulsanti allesterno della scatola: quale valore aggiunto offre SQRL?
• Risolve il problema del paradosso della password senza dover ricorrere a terze parti.
• Capisco. Quindi, se qualcuno non ‘ vuole il rischio di terze parti del Single Sign-On e non ‘ genera / archivia le proprie password con un gestore di password, SQRL può aumentare. Ma se SQRL è una scatola nera mobile che richiede una password per sbloccare la chiave principale utilizzata per rigenerare / memorizzare gli SQRLID e quindi eseguire il collegamento del canale posteriore del cookie / QR del client ‘ session_id con il server ‘ s registrato SQRLID per accedere – come è questa una scatola nera mobile diversa da un gestore di password mobile con accesso automatico tramite lo stesso canale di ritorno; o un plug-in di certificazione client mobile di due parti con & accesso tramite lo stesso canale di ritorno?
• Ho apportato alcune importanti modifiche al mio post originale dopo alcune seconde considerazioni e una lettura più attenta a ciò che altri hanno detto, poiché potrei averlo esagerato. Suppongo che avere il telefono cellulare come chiave centrale sposti il problema e renderebbe più importante avere una maggiore sicurezza sul tuo telefono. Steve Gibson ne parla anche nel Q & A podcast.

Sono daccordo 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 secondo, sarai in grado di accedere a QUALSIASI sito web che utilizza “SQRL”.E sarebbe un accesso anonimo, a condizione che tu decida di non fornire ulteriori informazioni.

È MOLTO più facile che lavorare con il proprio certificato; o creare 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 “vorrei postare qualcosa qui” … perfetto. Non più “per favore, fai sapere a Google, Facebook o qualsiasi altro sito che desideri pubblicare qui”.

Commenti

• I ‘ Non sono sicuro che questo sia un punto molto valido – se ‘ consentirai accessi anonimi, allora perché preoccuparti di un accesso in primo luogo? Un semplice captcha sarebbe sufficiente per prevenire un po di spam.
• Perché il login anonimo sei TU, che rifiuti di fornire qualsiasi informazione sulla tua identità; nessuno può falsificarlo.
• Suona quasi come un nuovo hash di Windows CardSpace.
• O un captcha, se stai accedendo a un utente che non ha mai effettuato laccesso prima.
• ” Per abilitare SQRL per te, devi creare la tua chiave principale e memorizzarla sul tuo telefono. ” In realtà, ‘ non è necessario, hai solo bisogno di un software sul tuo PC in grado di aprire sqrl: // URL.

SQRL non fornisce miglioramenti rivoluzionari. I codici QR sono un formato di codice a barre ottico utile per la distribuzione di contenuti brevi, niente di più.

Qualsiasi situazione di “accesso automatico” che SQRL sta cercando di risolvere potrebbe semplicemente utilizzare un certificato client memorizzato sul cellulare.

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

Quindi il più grande problema di sicurezza che ho con questo protocollo è: Reinventare la ruota quadrata .

Update

Leggendo nuove risposte e commenti, “vorrei sottolineare quanto sia facile fare qualcosa di simile a SQRL tramite semplice automazione della tecnologia esistente matura :

1. Il sito web richiede qualsiasi CAPTCHA o una verifica simile “io” sono umano “. Una volta che lutente ha rispettato (POSTed), il sito web restituisce un HTTP 403.7 - Client Certificate Required o un errore 403 vanilla.
2. Le pagine 403 personalizzate sono abbastanza facili da configurare e possono essere piuttosto belle e facili da usare. Potrebbe persino eseguire il bootstrap della funzionalità richiesta di seguito in modo simile ai prompt “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 a S403L” nello spirito di “conformità SQRL”.
4. Il plug-in S403L genera un certificato client standard, che è protetto nella solita cache cert del browser crittografata (o un terzo cache di terze parti se la crittografia del keystore del browser fa schifo). Il plug-in crea un CSR standard per il certificato del client e invia il CSR allURL specificato nel markup 403. (ad esempio <s403l ref="https://www.example.com/S403L" />)
5. Il server conforme a S403L utilizza il session_id dellutente (recuperato dai cookie o dalla stringa di query) per creare continuità con il passaggio 1, quindi restituisce il CSR come firmato dal server. Lautenticazione generale del server accetterà qualsiasi certificato client 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 poi, il browser standard senza lassistenza del plug-in può “auto-accedere” al server in modalità SSL / TLS standard fino alla scadenza del certificato.

La natura “mobile” e “visiva” di SQRL è una sorta di deviazione in quanto non fornisce unautenticazione a due fattori distaccata e ora sono necessari due computer per navigare in Internet invece di uno. A meno che tu non punti la webcam USB del tuo desktop verso il proprio monitor.

Il compromesso tra password e certificati è ben definito nella comunità della sicurezza: le password si adattano al cervello umano; i certificati non si adattano un cervello umano ( di solito ) ma può avere pazza entropia e buone funzioni di gestione PKI (scadenza , revoca, estensioni delle norme, ecc.). SQRL si adatta perfettamente a nessuno dei due campi; e se si sta spostando verso il campo meno umano più computer come sembra, ha anni di sviluppo e analisi di sicurezza per ripetere le funzionalità X.509 esistenti.

Commenti

• > potrebbe semplicemente utilizzare un certificato client memorizzato sul cellulare.— tranne che questa tecnologia esiste da anni sia su dispositivi mobili che desktop e ‘ non è così diffusa come si vorrebbe. E a differenza del certificato client, SQRL non ‘ richiede di dimostrare la tua vera identità per creare un ” SQRL Identity “. Se lo desideri, puoi creare tutte le identità che desideri. Ciò significa che il vantaggio rispetto ai certificati client è che hai lanonimato dal lato del protocollo di autenticazione ‘.
• @jpkrohling È un malinteso comune che i certificati client richiedere la divulgazione dellidentità da utilizzare. Questo è un requisito per le autorità di firma commerciale per utilizzare le loro catene di fiducia intercambiabili a livello globale. In pratica un certificato client può essere semplicemente un CSR anonimo creato dal client e firmato da un server specifico, dopo aver soddisfatto i criteri desiderati (CAPTCHA, account precedente, eccetera). I certificati possono anche avere una scadenza incorporata. Type 40-L I codici a barre QR potrebbero inviare / memorizzare il certificato client X.509 da 1KB, se lo si desidera.
• Ok, vero, colpa mia. Da questo punto di vista, il client (app mobile, ad esempio), potrebbe generare un certificato client per ogni sito Web che lutente sta registrando. Sembra più costoso dellhashing di alcune informazioni, ma potrebbe essere una soluzione interessante. In ogni caso, continuo a non ‘ daccordo con le tue affermazioni secondo cui SQRL è peggio che inutile.
• Forse sono stato duro con quella formulazione e la rimuoverò. Ma non ‘ vedo SQRL come qualcosa di diverso da un modo più sexy per distribuire le credenziali del cliente negoziato; e uno che non ha ‘ risolto alcuni dei problemi sottili risolti da schemi di autenticazione maturi. Un gestore di password è noioso (non ‘ mi preoccupo dellintegrazione del browser perché ‘ sono paranoico) ma so che solo io e uno sito web condivido ogni password one-shot nel mio keystore crittografato. Non ‘ non devo preoccuparmi dei nuovi schemi di hash / autenticazione fantasiosi, ma solo della qualità del PRNG / TRNG che il mio gestore di password utilizza per generare le password.
• @LateralFractal chi se ne frega se ‘ è nuovo o no? SQRL consente lautenticazione user friendly in cui la prima parte non espone il proprio segreto con la seconda parte o terze parti che potrebbero aver compromesso la sicurezza della seconda parte ‘. ‘ è un tentativo di risolvere un problema del mondo reale che, finora, nessun altro è stato in grado di risolvere.

Vorrei rispondere alla prima domanda: “uno dei problemi a cui riesco a pensare è se il lettore QR è compromesso, visualizzare www.google.com invece di www.nsa-super-secret-place.gov/123 “:

La chiave principale viene utilizzata come seme in HMAC insieme allindirizzo del sito web (FQDN). Quindi, sebbene il codice QR possa codificare un URL completamente diverso, il protocollo NON rivelerà il codice di autenticazione che normalmente verrebbe inviato a www.google.com (nellesempio).

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

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

Credo che i protocolli risolvano questi problemi in modo completo!

Tuttavia, ci sono compromessi che in realtà provengono dal primo obiettivo. Se nessuna terza parte è coinvolta nellautenticazione, come si possono revocare i propri dettagli di autenticazione? Inoltre, la sicurezza della chiave master è unovvia preoccupazione. Immagino che questo sia ben protetto dai futuri dispositivi mobili in un chip simile a HSM. Fino ad allora, la chiave è solo un dispositivo mobile con pin di file, protetto da una password, sebbene PBDKF2 assicuri che sia molto lento forzarlo effettivamente.

Commenti

• Ancora una volta, cosa cè di nuovo ‘ su questa idea? Mi sembra che sia una variante primitiva dellormai defunto Windows CardSpace.
• Sì, hai ragione su CardSpace. Poi cè U-Prove anche di proprietà di Microsoft. La domanda è come useresti CardSpace o U-Prove su un computer di cui non ti fidi (internet cafè o computer di amici). Questo è ciò che ha aggiunto Steve.
• Ah, ok, questo ‘ è quello che mi mancava. Sono ancora daccordo con @TerryChia che questo è un non-starter senza un meccanismo di revoca per le chiavi utente.
• @Xander esiste un meccanismo di revoca per le chiavi utente. grc.com/sqrl/idlock.htm