Il problema relativo al MITM con SQRL deriva dal fatto che la richiesta di autenticazione e la risposta avvengono su due canali diversi, e un utente malintenzionato può condurre con successo una richiesta di autenticazione valida / risposta da un sito non valido. In altre parole, un sito di attacco potrebbe recuperare un codice SQRL dal sito corretto e presentarlo alla vittima. La vittima può autenticare contro la richiesta fornita, ma in tal caso si collegherà l'utente malintenzionato. La mancanza di coordinamento tra il browser e il telefono indica che non è possibile proteggere questo passaggio.
In questo senso, SQRL non è più suscettibile al phishing / MITM delle password, ed è in qualche modo migliore nel senso che l'autenticazione deve avvenire online. Ma è peggio delle alternative esistenti, e questo è il problema.
Quindi, ad esempio, se tua madre, il tuo capo, collega o amico ti dice: " Voglio essere più sicuro online, dovrei usare SQRL? " La tua risposta deve essere: " No, usa Lastpass e password casuali invece . "
La differenza fondamentale qui è che l'integrazione del browser ostacola tutti gli attacchi di phishing e dal momento che il phishing è di gran lunga la minaccia più grave per la tua sicurezza online, questa dovrebbe essere la tua priorità principale, trionfa su tutto il resto. Nessuna alternativa dovrebbe essere considerata se non protegge da questa minaccia, perché è quella che è più probabile che faccia. Se stai per passare, passa a qualcosa che ti terrà al sicuro, non qualcosa che non lo farà.
Cosa sono i contromisure di GRC?
Il primo punto di GRC su come i codici SQRL siano unici per un determinato sito è irrilevante, e non sono sicuro del motivo per cui si preoccupa di menzionarlo. Fondamentalmente sta dicendo che paypal.evil non può generare il proprio codice SQRL per paypal.com. L'utente malintenzionato dovrebbe recuperare un codice autentico da paypal.com e presentarlo all'utente. Che è esattamente quello che farebbero.
La contromisura di "Login reindirizzamento" è davvero fattibile solo se stai usando l'integrazione con il browser ... nel qual caso è completamente inutile, dal momento che il browser può già dire se si trova nel sito corretto o meno. Se stai utilizzando SQRL con un telefono come originariamente progettato, il link "reindirizzamento dell'accesso" dovrebbe essere digitato manualmente nell'URL da qualcuno che lo stacca dal telefono. Quindi ... questo non succederà.
La contromisura di "conferma azione" è un carico di stupidità. L'idea è di accedere alla banca con SQRL, quindi ogni attività (inclusa la visualizzazione dei dati sensibili) effettuata sul sito web della banca dovrebbe essere confermata manualmente sul telefono cellulare. Sarebbe come usare l'app del proprio cellulare, ma con un ulteriore inconveniente.
Il materiale di verifica dell'ip-source su cui GRC fa un gran dettaglio è un hack. La protezione è incoerente e incompleta e l'implementazione sarebbe disordinata e soggetta a errori a dir poco. Questo è importante perché, sebbene possa essere "meglio di niente", non è "migliore dell'alternativa"; puoi effettivamente avere una buona sicurezza, ma non è questo.
Tutto questo è un tentativo di adeguare le disposizioni di sicurezza critiche in un sistema in cui non è stato progettato per adattarsi. E questo è davvero il nocciolo del problema: il sistema è stato costruito per risolvere problemi non comuni o inesistenti, ignorando i problemi reali, seri e urgenti. Quindi stiamo prendendo un sistema che è stato progettato male per cominciare e sta tentando di applicarlo per renderlo "di livello professionale". È un po 'come prendere i progetti di grattacieli disegnati da un meccanico e tentare di risolverli per creare qualcosa che potrebbe essere effettivamente costruito. L'approccio più pratico ed efficace è quello di ricominciare da capo.
Potremmo costruire un'alternativa sicura?
Certo che potremmo. Ma la chiave per farlo è guardare prima il caso d'uso principale e il modello di minaccia, e costruire di conseguenza il sistema. Ad esempio, SQRL è stato progettato in modo tale che tutte le autenticazioni avvengano sul tuo telefono cellulare. È possibile aggiornare la soluzione per consentire l'integrazione del browser, ma tutte le funzionalità e le decisioni di progettazione sono basate sul presupposto che il proprio cellulare sia la propria identità, motivo per cui la protezione da phishing è così difficile.
Progettare un sistema per affrontare tutti gli scenari di attacco più probabili è davvero semplice. Esistono tutti i componenti necessari e tutti i problemi sono già stati risolti. Non entrerò nei dettagli qui perché questo non è il posto giusto, ma scommetterei che se avessi chiesto a una dozzina di veri esperti di sicurezza e identità, avessero presentato più o meno lo stesso design.