Nehmen Sie wie üblich alles, was mit Steve Gibson zu tun hat, mit einer Lastwagenladung Salz. Obligatorisch attrition.org Link .

Schauen wir uns Gibsons Beschreibung seines Protokolls an.

• Der QR-Code, der neben dem Login angezeigt wird Die Eingabeaufforderung enthält die URL des Authentifizierungsdienstes für die Site. Die URL enthält eine sicher generierte lange Zufallszahl, sodass auf jeder Präsentation der Anmeldeseite ein anderer QR-Code angezeigt wird. (In Kryptokreisen wird diese lange Zufallszahl als „Nonce“ bezeichnet.)

• Die SQRL-Authentifizierungs-App des Smartphones hasht den Domänennamen der vom Benutzer eingegebenen Site kryptografisch „s Hauptschlüssel zum Erstellen eines ortsspezifischen öffentlichen Schlüsselpaars.

• Die App signiert die gesamte im QR-Code enthaltene URL kryptografisch mit dem ortsspezifischen privaten Schlüssel. Da die URL eine sichere lange Zufallszahl (Nonce) enthält, ist die Signatur für diese Site und den QR-Code eindeutig.

• Die App gibt eine sichere HTTPS-POST-Abfrage an den QR aus Die URL des Codes ist der Authentifizierungsdienst für die Site. Der POST stellt den standortspezifischen öffentlichen Schlüssel und die übereinstimmende kryptografische Signatur der URL des QR-Codes bereit.

• Die authentifizierende Website empfängt und bestätigt die POST-Abfrage, indem sie ein Standard-HTTP „200 OK“ ohne anderen Inhalt zurückgibt. Die SQRL-App bestätigt die erfolgreiche Übermittlung des vom Benutzer signierten QR-Codes.

• Die authentifizierende Site verfügt über die URL, die die Nonce enthält, die über die Benutzer von der Anmeldeseite zurückgekommen ist Smartphone. Es hat auch eine kryptografische Signatur dieser URL und den ortsspezifischen öffentlichen Schlüssel des Benutzers. Mit dem öffentlichen Schlüssel wird überprüft, ob die Signatur für die URL gültig ist. Dies bestätigt, dass der Benutzer, der die Signatur erstellt hat, den privaten Schlüssel verwendet hat, der dem öffentlichen Schlüssel entspricht. Nach Überprüfung der Signatur erkennt die authentifizierende Site den jetzt authentifizierten Benutzer anhand ihres standortspezifischen öffentlichen Schlüssels.

Die Das größte Problem, das mir auffällt, ist die Verwendung eines “ Hauptschlüssels “ durch den Benutzer. Wenn ich das Protokoll richtig lese, steuert dieser einzelne Hauptschlüssel die gesamte Online-Identität des Benutzers …

Vermutlich wird dieser Hauptschlüssel im Telefon des Benutzers in einer Anwendungsdatenbank gespeichert. Dies eröffnet einen riesigen klaffenden Angriffsvektor in Form von Malware, die speziell zum Stehlen des Hauptschlüssels entwickelt wurde.

Vergleichen wir also den Unterschied zwischen dem, was passiert, wenn ein Passwort kompromittiert wird, und dem, was passiert, wenn der Hauptschlüssel passiert wird kompromittiert. Angenommen, Sie befolgen die guten Kennwortpraktiken für lange, eindeutige und sehr zufällige Kennwörter, die in einem Kennwortmanager gespeichert sind. Sie müssen lediglich ein einzelnes Kennwort ändern, wenn es kompromittiert wird. Was passiert, wenn Ihr Hauptschlüssel kompromittiert wird? Sie müssen irgendwie alle Websites abrufen, bei denen Sie sich authentifiziert haben, um zu erkennen, dass Ihr Hauptschlüssel kompromittiert wurde. Das einzige Problem besteht darin, dass Sie keine anderen Mittel zur Authentifizierung bei der Site haben, z. B. Benutzernamen oder E-Mail-Adressen, woher weiß die Site, dass Sie tatsächlich versuchen, den Hauptschlüssel zu widerrufen?

Wie alles, was aus Gibson stammt, ist dieses SRQL-Schema sehr fehlerhaft und bietet keine Vorteile gegenüber herkömmlichen Methoden.

Comme nts

• “ Wenn Sie ‚ gute Kennwortpraktiken befolgen “ ist eine große Einschränkung, und die meisten Internetnutzer tun dies nicht ‚.Ein Teil des Versprechens von SQRL ‚ besteht darin, die Benutzer zu reduzieren, die ‚ auf dem neuesten Stand der Best Practices bleiben müssen. Darüber hinaus fordert die SQRL-Spezifikation, dass der Hauptschlüssel verschlüsselt mit einem Hauptkennwort gespeichert wird, und es ist unmöglich, ihn brutal zu erzwingen (so eingestellt, dass er für einen Versuch ~ 60 Sekunden dauert). Das Abrufen des Kennworts ist häufig nicht trivial, da SQRL die Out-of-Band-Authentifizierung fördert (dh das Keyloggen eines gehackten Computers hilft Ihnen nicht immer ‚). Während die Konsequenzen eines vollständigen Kompromisses hoch sind, ist die Wahrscheinlichkeit eines Kompromisses etwas gering.
• SQRL weist möglicherweise noch Fehler auf, die behoben werden müssen, aber behauptet , eine Reihe von Problemen zu lösen, die bei bestehenden Authentifizierungsansätzen auftreten, und jede Kritik an SQRL, die dies behauptet, “ bietet keine Vorteile “ sollte Widerlegungen dieser Behauptungen enthalten, anstatt zu erwarten, dass die Behauptung blind akzeptiert wird.
• > Wie alles, was von Gibson kommt Dieses SRQL-Schema ist sehr fehlerhaft und bietet keine Vorteile gegenüber herkömmlichen Methoden. — Dies scheint ‚ nicht bei der Beantwortung der Frage zu helfen, und ich habe tatsächlich das Gefühl, dass Sie Probleme mit der Technologie haben, weil Sie darauf gekommen sind. Einige der Punkte, die Sie als Fehler erwähnt haben, werden tatsächlich von der “ -Spezifikation “ behoben. Zum Beispiel erwähnt SQRL selbst ‚ nicht, wie der Hauptschlüssel gespeichert ist, aber Steve Gibsons ‚ kommentiert, dass es sich um ein Mobiltelefon handelt Der Client verschlüsselt es beispielsweise mit einem Hauptkennwort unter Verwendung einer Verschlüsselung, deren Ausführung durchschnittlich 60 Sekunden dauert.
• Gibson Explicity befasst sich mit dem Schutz des Hauptschlüssels.
• Halten Sie a gedrückt zweite. Sie setzen Ihren gestohlenen SQRL-Hauptschlüssel mit einem gestohlenen LastPass-Schlüssel gleich. Wäre es nicht ‚ eine bessere Analogie, es mit Ihrer gesamten entschlüsselten LastPass-Passwortdatenbank gleichzusetzen, die gestohlen wird?

Insgesamt scheint das Protokoll die Sicherheit gegenüber vorhandener Technologie nicht zu erhöhen. Wenn Sie nach dem besten Weg suchen, Ihre Identität online zu schützen, ist dies ohne Frage nicht . Aber lassen Sie uns die Vor- und Nachteile durchgehen:

Vorteile

Es ist unmöglich, “ ein Kennwort in dem engeren Sinne, dass eine böswillige Website die für eine Site bereitgestellte Authentifizierung nicht verwenden kann, um sich bei einer anderen Site anzumelden.

Ein Brute-Force-Angriff gegen das Authentifizierungstoken ist nicht möglich.

Anmeldeinformationen werden nicht auf Ihrem Computer gespeichert. Dies schützt Sie vor einer kleinen Teilmenge von Workstation-gesteuerte Angriffe. Insbesondere sind Sie vor Angriffen geschützt, die Ihr Kennwort von Ihrem Computer stehlen. Sie sind jedoch nicht gegen jede Art von Sitzungsentführung oder Browserübernahmeangriffen geschützt, und Sie sind jetzt auch anfällig für telefonbezogene Angriffe. Dazu später mehr.

Nachteile

Diese Technik ist gefährlich anfällig für MITM-Angriffe und Social Engineering. Wahrscheinlich mehr als jedes andere verwendete Authentifizierungsschema, einschließlich Kennwörtern. Der Authentifizierungsschritt und der Anmeldungsinitiierungsschritt sind von Natur aus in dem Sinne getrennt, dass sich das Telefon bei jedem präsentierten QR-Code korrekt authentifiziert, unabhängig davon, wie oder wo er dem Benutzer präsentiert wird.

So zum Beispiel Eine Phishing-Site kann einen authentischen QR-Code für die Anmeldung anzeigen, der den Angreifer anstelle des Benutzers anmeldet. Gibson ist zuversichtlich, dass Benutzer während der Authentifizierung den Namen der Bank, des Geschäfts oder der Website in der Telefon-App sehen und daher ausreichend wachsam sind, um Angriffe zu verhindern. Der Verlauf legt nahe, dass dies unwahrscheinlich ist, und die vernünftigere Erwartung ist, dass das Anzeigen des richtigen Namens in der App den Benutzer fälschlicherweise zu der Annahme verleitet, dass die Website legitim ist, da sie die vertraute Anmeldeanforderung auf dem Telefon auslösen konnte. Die Vorsicht, die den Köpfen der Benutzer in Bezug auf die Kennwortsicherheit bereits zuteil wurde, führt nicht unbedingt zu neuen Authentifizierungstechniken wie dieser, was diese App wahrscheinlich von Natur aus weniger widerstandsfähig gegen Social Engineering macht.

Diese Technik kombiniert sowohl Authentifizierung als auch Identität zu einem physischen Objekt, das häufig verloren geht oder gestohlen wird. In diesem Sinne ist es “ Es ist eher wie ein Reisepass als ein Passwort. Jeder, der Ihr Telefon besitzt, ist plötzlich ausschließlich im Besitz Ihrer Identität: Der Angreifer kann sich nicht nur als Sie ausgeben, sondern auch ohne eine zweite Kopie auf einem zweiten Telefon ( unwahrscheinlich), jetzt haben Sie die Fähigkeit verloren, sich zu identifizieren.Authentifizierungsschlüssel können nicht widerrufen werden. Ohne Out-of-Band-Wiederherstellung von jedem Standort können Sie Ihre Identität nicht wiederherstellen. Und selbst wenn eine Out-of-Band-Wiederherstellung vorliegt, kann es schwierig sein, zu erkennen, warum der Site-Betreiber Ihnen vertrauen sollte, wenn er mit zwei Benutzern konfrontiert wird, einem mit und ohne Identität.

Diese Technik kombiniert alle Ihre Authentifizierungstoken in einem einzigen Schlüssel , sofern Sie keine anderen manuell erstellen. Dies macht Ihren einen Schlüssel zu einem besonders saftigen Ziel für Angreifer. Darüber hinaus ist der Schlüssel auf Ihrem Telefon gespeichert, dessen Geräte normalerweise eine lächerlich durchlässige interne Sicherheit hatten. Das Kombinieren ungewöhnlich saftiger Ziele mit minderwertiger Sicherheit macht Sie nicht sicher.

Alternativen

Der problematischste Aspekt dieses Schemas ist, wie schlecht es im Vergleich zu den verfügbaren Alternativen ist.

Die sicherste allgemein akzeptierte Option ist heute Lastpass, Keepass und andere solche browserintegrierten Passwortsysteme. Insbesondere die clientseitige Verschlüsselung verringert die Notwendigkeit, Dritten zu vertrauen. Und was noch wichtiger ist: Die Browserintegration macht Phishing praktisch unmöglich . LastPass oder KeePass füllen das Kennwort nur aus, wenn es von der richtigen Domain bereitgestellt wird. Dies bedeutet, dass der Benutzer bei Anzeige einer schädlichen Website keinen Zugriff auf sein Kennwort hat.

Außerdem hat LastPass kürzlich eine Funktion hinzugefügt Dies hilft Benutzern, Kennwörter zu ändern, die nicht global eindeutig sind. Dies verhindert die Wiederverwendung von Kennwörtern. Dies bedeutet, dass der Hauptvorteil von Gibsons Technik heute mit diesem Tool auf vorhandenen Websites leicht erzielt werden kann, ohne die zusätzliche Unsicherheit, die sein Schema impliziert.

Bestehende Zweitfaktor-Authentifizierungsschemata, die Telefone oder ähnliche Geräte verwenden, schützen Benutzeranmeldungen bereits heute so, dass Sie nicht sofort für Identitätsdiebstahl anfällig werden, wenn Ihr Gerät gestohlen wird Die Sicherheit der Zwei-Faktor-Authentifizierung liegt in der Tatsache, dass weder das Gerät noch das Passwort verwendet werden können, wenn es ohne das andere gestohlen wird. Gibsons Technik ist weitgehend resistent gegen die Aufnahme in ein Zwei-Faktor-Schema, wodurch diese Schutzstufe erreicht wird nicht verfügbar.

TL; DR:

Gibsons Authentifizierungstechnik bietet keinen ausreichenden Nutzen, um die zusätzlichen Sicherheitskosten zu überwinden, die sie ebenfalls verursacht. Diese Kosten sind ein wesentlicher Bestandteil des Schemas selbst und können wahrscheinlich nicht berechnet werden, ohne das gesamte Design zu verschrotten.

Sie könnten argumentieren, dass es besser als nichts ist, aber Sie können nicht argumentieren, dass es besser ist besser als alles, was wir bereits haben.

Gibsons Updates

Gibson hat kürzlich einen zusätzlichen Schutz gegen Phishing angekündigt, da dies eine Hauptkritik war. Ihr Schutz ist folgender: Wenn Sie die QR-Codes, das Mobiltelefon usw. NICHT verwenden und stattdessen einen Authentifizierungsagenten auf Ihrem System haben (z. B. im Browser), kann der Server überprüfen, ob die Authentifizierung erfolgt Die Antwort kommt von derselben IP-Adresse wie die Authentifizierungsanforderung. Dies ist gut und gut, aber der gesamte Zweck dieses Protokolls besteht darin, Ihre Identität auf Ihr Mobiltelefon zu übertragen. Wenn die einzige sichere Möglichkeit zur Verwendung des Protokolls darin besteht, den Kern nicht zu verwenden Dann sollten wir uns vielleicht überlegen, was wir erreichen wollen.

Theoretisch könnten Sie Ihr Handy weiterhin verwenden, wenn (und nur wenn) Ihr Handy es wüsste dass es dieselbe IP wie Ihr Computer verwendet hat. Was es natürlich nicht wissen kann, weil es die IP-Adresse Ihres Computers nicht kennt.

Eine bessere Lösung

Wie bereits erwähnt, ist das gesamte Phishing-Problem sofort gelöst, wenn sich die Authentifizierungsmaßnahme in Ihrem Browser befindet, der Benutzer. Selbst der am wenigsten fähige Benutzer kann nicht dazu verleitet werden, sich bei der falschen Site zu authentifizieren, da das Authentifizierungstoken der Site dem Domainnamen zugeordnet ist und der Browser gewonnen hat. t Authentifizierung bei der falschen Domain zulassen. Diese Technik wird bereits heute verwendet, ist vollautomatisch und erfordert weder die Zusammenarbeit der Site noch Informationen des Benutzers.

Diese Methode kann durch die Anforderung eines zweiten Authentifizierungsfaktors verstärkt werden (z. B. ein zeitlich variierender Schlüssel auf einem Mobiltelefon), der wiederum bereits verfügbar ist und heute verwendet wird und Sie (vor allem) vor Fehlern seitens des Zielstandorts oder des Unternehmens schützt.

Bedenken hinsichtlich der Anfälligkeit der Browserseitenauthentifizierung für Client-Workstation-Angriffe: Während dies zutrifft, gilt auch , wenn Ihr Browser kompromittiert ist, nein Die Verwendung dieses Browsers ist sicher , unabhängig davon, welchen Authentifizierungsmechanismus Sie verwenden.Malware-Autoren können (und tun dies bereits) darauf warten, dass Sie sich mithilfe Ihrer supersicheren Technik selbst authentifizieren, und dann den erforderlichen Datenverkehr stillschweigend an “ own Ihr Konto, ohne dass Sie etwas falsch sehen. Weder SQRL noch ein anderes Authentifizierungssystem können den Benutzer eines kompromittierten Browsers schützen, ebenso wenig wie Türschlösser Sie vor einem Hausbrand schützen können. Der Kauf feuerfester Schlösser ist keine Lösung.

Wohin

Wenn Sie nach einer absoluten Garantie für den Schutz vor Identitätswechsel suchen , dann schauen Sie sich das Fido U2F-Token an. Dieser Standard leuchtet dort, wo SQRL zu kurz kommt, und bietet Ihnen garantierte Immunität gegen MITM-Angriffe (z. B. Phishing). Er authentifiziert nicht nur den Benutzer, sondern auch den Kanal, also Sie „Es wird garantiert, dass (a) Ihr Konto ohne das Token nicht authentifiziert werden kann und (b) Ihr Token nur zur Authentifizierung einer Verbindung mit dem Computer verwendet werden kann, an den es angeschlossen ist. Weitere Informationen finden Sie unter dieser Antwort .

Kommentare

• Zum ersten Punkt : Soweit ich weiß, wurde darüber nachgedacht, und eine Möglichkeit besteht darin, die Website, auf der Sie sich authentifizieren, für die Weiterleitung verantwortlich zu machen. Beim Anmelden werden Sie also zur Seite der realen Bank ‚ weitergeleitet, nicht zum Angreifer. Was den zweiten Punkt betrifft, so passiert dies heute auch bei Benutzern von Tools wie LastPass. Sofern Sie keinen Schutzmechanismus einrichten (z. B. PIN), werden auch alle Ihre Passwörter gestohlen. Warum kann ‚ nicht dasselbe für SQRL gelten? Soweit ich aus der Spezifikation weiß, kann der Benutzer seine Identität sogar auf Papier (als QR-Code) sichern.
• Und zum dritten Punkt: Das gleiche passiert mit den meisten Benutzern, die nicht ‚ Verwenden Sie keinen Passwort-Manager, indem Sie einfach einen einzelnen Benutzernamen / ein Passwort auf mehreren Websites verwenden. Oder mit Benutzern von Passwort-Managern, deren “ Identität “ auf mehreren Websites verteilt, aber an einem einzigen Ort gespeichert ist (LastPass ‚ Server, 1Password-Datenbank usw.). ‚ ist also kein wirklicher SQRL-Fehler. Alles in allem, je mehr ich über SQRL lese, desto mehr sehe ich die Vorteile im Vergleich zu den aktuellen Alternativen. Sagen Sie, dass Sie über Steve Gibson sagen, aber SQRL scheint mir wirklich eine gute Alternative zu sein.
• “ Die Vorsicht, die bereits in die Köpfe von geschlagen wurde Benutzer in Bezug auf die Kennwortsicherheit müssen nicht unbedingt auf neue Authentifizierungstechniken wie diese umstellen. . “ Dies ist ein ausgezeichneter Punkt, und der Kampf ist bereits für das Marketing verloren gegangen. QR-Codes werden als einfache Möglichkeit angesehen, Dinge zu erledigen, und nicht als potenzieller Angriffsvektor. Zumindest Benutzernamen / Passwort-Paare wurden ZUERST als Authentifizierungsmechanismus und nicht als Marketing-Tool verwendet.
• @jpkrohling: In Bezug auf Passwort-Manager würde ich vermuten, dass die meisten Benutzer solcher Software ihr Hauptkennwort NICHT speichern auf ihrem mobilen Gerät, gerade weil sie wissen, wie gefährlich das ist. Ich habe eine physische Kopie meines Hauptkennworts an einem sicheren Ort, aber keine elektronischen Kopien. Die Angriffe, die den Zugriff auf mein Hauptkennwort gewähren würden, unterscheiden sich von denen, die ein Site-Kennwort gefährden würden, und sind weitaus weniger wahrscheinlich. (In erster Linie, weil ein Angriff auf meine Passwortdatenbank einen persönlichen Angriff auf mich und nicht auf eine große gefährdete Site bedeuten würde.)
• @jpkrohling Weder LastPass noch KeePass speichern irgendwo ein Hauptkennwort. Es wird ‚ verwendet, um Ihre Kennwortdatenbank zu entsperren, aber es wird nicht ‚ gespeichert. Dies unterscheidet sich grundlegend von einem einzelnen Schlüssel, der selbst überall verwendet wird.

SQRL sicherlich ist nicht ohne Mängel, aber es ist den meisten primären Authentifizierungslösungen, die heutzutage im Web weit verbreitet sind, in Bezug auf Sicherheit und (und das ist wichtig) Benutzerfreundlichkeit sicherlich überlegen. Lassen Sie mich das erklären.

Missverständnisse

Lassen Sie mich zunächst einige der Missverständnisse klären, die in einigen anderen Antworten auf diese Frage enthalten sind. Viele dieser Antworten sind veraltet und wurden vor Änderungen an der SQRL-Dokumentation geschrieben die sich mit den in ihnen dargestellten Problemen befassen, während andere die Fehler in SQRL, die auch in vielen anderen weit verbreiteten vorhandenen Authentifizierungslösungen vorhanden sind, übermäßig zu betonen scheinen, während ihre Vorteile ignoriert werden. Lassen Sie uns hier einige Missverständnisse klären wir?

Mythos: SQRL erfordert das Scannen von QR-Codes

Dies ist einfach nicht wahr. QR-Codes sind eine Annehmlichkeit Dies erleichtert die Verwendung von SQRL auf Computern, auf denen der Benutzer keine SQRL-Client-Software eingerichtet hat. Auf der Website von SQRL heißt es:

Drei Möglichkeiten.Smartphone optional:

Obwohl die ursprüngliche Inspiration für die Entwicklung dieses Systems ein Smartphone war, das einen QR-Code auf der Anmeldeseite einer Website scannt, ermöglicht eine kleine Ergänzung dieses Modells zwei weitere wichtige Betriebsmodi: Einfach Machen Sie das QR-Code-Bild auch zu einem anklickbaren Link zu derselben URL, die im QR-Code codiert ist. Dies bietet drei Möglichkeiten zum Anmelden:

• Scannen Sie den Code mit einem Smartphone: Verwenden von In dem oben beschriebenen Modell scannt das Smartphone eines Benutzers den QR-Code, der auf der Anmeldeseite einer Website angezeigt wird, und der Benutzer wird auf dieser Website angemeldet.
• TAP DER CODE auf einem Smartphone: Um sich auf dem Smartphone bei einer Website anzumelden, wenn der visuelle SQRL-Code auch ein Link im URL-Stil ist (unter Verwendung von sqrl: // als Schema) Die auf dem Smartphone installierte SQRL-App empfängt diesen Link und meldet den Benutzer sicher auf der Website des Telefons an.
• Klicken Sie auf den Code auf einem Desktop- oder Laptop-Bildschirm : Um das SQRL-System auf einem beliebigen Desktop- oder Laptop-System zu verwenden, wird eine Desktop-SQRL-Anwendung installiert und registriert, um sqrl: // -Links zu erhalten. (Dies ähnelt der Art und Weise, wie sich ein E-Mail-Programm registriert, um mailto: links zu empfangen.) Auf diese Weise können Benutzer auf ihrem Desktop dieselbe Lösung verwenden, die sie auf ihren Smartphones verwenden. Wenn eine Website einen SQRL-Code anbietet, klickt der Benutzer einfach mit dem Mauszeiger auf den Code. Die lokal installierte SQRL-App wird angezeigt, fordert zur Eingabe des SQRL-Kennworts auf, bestätigt die Domain und meldet sich dann an.

Mythos: Der SQRL-Hauptschlüssel wird vollständig unverschlüsselt und ungeschützt auf Ihrem Telefon gespeichert.

Ich bin nicht sicher, warum einige Leute dies gemacht haben Annahme, da es mir offensichtlich erscheint, dass dies nicht der Fall wäre. Der SQRL-Hauptschlüssel ist ungefähr so geschützt, wie Sie eine Kennwortdatenbank schützen würden: mit einem starken Hauptkennwort. Wenn Sie das Telefon eines Benutzers stehlen, erhalten Sie nicht automatisch Zugriff auf seine Online-Identität, es sei denn, Sie hatten auch sein Hauptkennwort. Weitere Informationen zur Schlüsselverwaltung finden Sie auf der Seite SQRL Client-. Side Key Management auf der SQRL-Website.

Mythos: Wenn Ihr Hauptschlüssel gestohlen wird, können Sie Ihre Anmeldeinformationen nicht ändern.

Dies ist ebenfalls falsch. SQRL bietet eine integrierte Möglichkeit, mit der der echte Kontoinhaber seine Anmeldeinformationen im Falle eines kompromittierten Schlüssels aktualisieren kann. Diese Funktion wird als Identitätssperre bezeichnet:

„Identitätssperre“ verhindert Identitätsänderung & ermöglicht die Wiederherstellung: Dies ist auch wichtig genug, um eine eigene detaillierte Beschreibungsseite zu verdienen: „ Das Identitätssperrprotokoll “ (Seite 4 im Linkblock am Ende dieser Seite.) Einmal a Die Identität des Benutzers wurde mit einem Webserver, der SQRL, hergestellt. c lient ist nicht in der Lage , diese Identität zu ändern. Dies bedeutet, dass im schlimmsten Fall ein sehr schwaches und leicht zu erratendes Kennwort verwendet wurde oder das Telefon oder der Desktop eines Benutzers gehackt wurde, um seinen Identitätshauptschlüssel und sein Kennwort zu erhalten, Kein böswilliger Dritter kann die Online-Identität des Benutzers ändern, um ihn von seinen eigenen Online-Konten auszuschließen. Darüber hinaus kann der wahre Eigentümer seiner Identität durch Laden eines normalerweise offline gesetzten „Identity Unlock Key“ in den Ruhestand treten und seine verlorene oder gestohlene Online-Identität ersetzen, um sie im Wesentlichen zurückzunehmen von jedem Angreifer, wodurch seine vorherige Identität unbrauchbar wird.

Plausibel: SQRL ist anfälliger für Phishing als vorhandene Authentifizierungslösungen

Okay, das ist also tatsächlich teilweise wahr. Wenn Sie SQRL durch Scannen eines QR-Codes verwenden, gibt es in der Tat nur einen sehr geringen Schutz gegen Phishing. Sofern der Benutzer nicht darauf achtet, dass die in der URL-Leiste seines Browsers angezeigte Website mit der von der SQRL-Client-App angezeigten Website übereinstimmt, kann er eine Anmeldesitzung für den Angreifer autorisieren. Dies ist immer noch besser als Kennwörter Sie würden dem Phisher permanenten Zugriff auf ihr Konto (und alle anderen Konten, die sie an anderer Stelle haben und dasselbe Passwort haben) gewähren, bis sie ihr Passwort ändern, aber nicht so gut wie andere Lösungen, die wie U2F-Schlüssel in den Browser des Benutzers integriert sind , WebAuthn, Clientzertifikate und (unter bestimmten Bedingungen) Kennwortmanager.

Wenn Sie jedoch einen SQRL-Client auf demselben Gerät verwenden, mit dem Sie sich anmelden, bietet SQRL einige Schutzfunktionen Phishing an Ort und Stelle. Diese Schutzmaßnahmen werden auf der Website von SQRL unter dem Abschnitt erläutert. Wie SQRL Phishing-Angriffe verhindern kann .Es gibt auch die Möglichkeit, SQRL in Browser zu integrieren (möglicherweise über Plugins), um einen viel stärkeren Schutz vor Phishing-Angriffen zu bieten. Dies entspricht Lösungen wie WebAuthn und Client-Zertifikaten.

Insgesamt würde ich SQRL auf Rang 1 setzen ungefähr auf dem gleichen Niveau wie Passwort-Manager für den Phishing-Schutz. Es bietet möglicherweise einen starken Schutz vor Phishing, wenn es auf demselben Gerät installiert ist, auf dem sich der Benutzer anmeldet, bietet jedoch nur minimalen Schutz, wenn es auf einem anderen Gerät installiert wird.

Vergleich mit Alternativen

Vergleichen wir nun SQRL mit vorhandenen, weit verbreiteten Authentifizierungslösungen.

Passwörter

SQRL ist Passwörtern in vielerlei Hinsicht weit überlegen. Es ist nicht nur bequemer, sie einmal zu verwenden Dies bedeutet, dass Benutzer sich nicht um das Speichern oder erneute Eingeben mehrerer unterschiedlicher Kennwörter für jede Site kümmern müssen, sondern auch vor der Wiederverwendung von Kennwörtern, schwachen Kennwörtern, Keylogging und in gewissem Maße vor Phishing.

Nachteile SQRL hat im Vergleich zu Passwörtern festgestellt, dass es für Website-Betreiber schwieriger zu implementieren ist, nicht so weit verbreitet ist, mehr Zeit für die Einrichtung benötigt, einige Anstrengungen für die Übertragung auf ein neues Gerät erfordert und eine einzige Fehlerquelle für alle Konten des Benutzers, wenn der Hauptschlüssel gestohlen wird (obwohl dieser letzte Poin Dies gilt auch für Kennwörter, wenn ein Benutzer auf jeder Site dasselbe Kennwort verwendet.

Kennwortmanager

In vielerlei Hinsicht ist SQRL Kennwortmanagern sehr ähnlich. Beide bieten einen einzigen zentralen Vertrauensanker, der als eine Art Authentifizierungs-Proxy zwischen Benutzern und einzelnen Diensten dient. Es gibt jedoch einige Möglichkeiten, wie SQRL Kennwortmanagern überlegen ist.

Der Hauptvorteil von SQRL gegenüber Kennwortmanagern besteht meiner Meinung nach darin, dass die Verwendung auf nicht vertrauenswürdigen oder nur teilweise vertrauenswürdigen Computern einfacher und sicherer ist. Angenommen, ein Benutzer möchte sich mit einem Computer in einer öffentlichen Bibliothek bei einer Website anmelden. Mit einem Kennwortmanager müsste er entweder auf das Kennwort für diese Website auf seinem Telefon zugreifen und es manuell in den Computer eingeben oder sein Kennwort herunterladen Kennwortmanager und Kennwortdatenbank auf dem Bibliothekscomputer, entsperren Sie die Datenbank mit seinem Hauptkennwort und melden Sie sich dann an. Das erste Szenario ist für den Benutzer unpraktisch und macht das Klartextkennwort des Benutzers für diese eine Site für den nicht vertrauenswürdigen Computer (und für) verfügbar Malware auf dem nicht vertrauenswürdigen Computer, einschließlich Keylogger). Das zweite Szenario ist noch schlimmer, da es sowohl unpraktisch ist als auch die gesamte entschlüsselte Kennwortdatenbank und das Hauptkennwort des Benutzers dem nicht vertrauenswürdigen Computer zugänglich macht. Mit SQRL müsste der Benutzer nur einen QR-Code auf dem Bildschirm des nicht vertrauenswürdigen Computers scannen, was für den Benutzer viel bequemer ist, und nur eine einzige Anmeldesitzung (ohne wiederverwendbare Anmeldeinformationen wie ein Kennwort) für den nicht vertrauenswürdigen Computer verfügbar machen

Ein weiterer Vorteil von SQRL gegenüber Kennwortmanagern besteht darin, dass es einfacher ist, sich vom schlimmsten Fall zu erholen: Die Kennwortdatenbank / der Hauptschlüssel des Benutzers werden gestohlen. Mit einem Kennwortmanager würden Sie dies nicht tun Sie müssen nur Ihr Passwort auf jeder Site ändern. Sie müssen sich auch Sorgen machen, dass der Angreifer Ihre Passwörter ändert (möglicherweise werden Sie von Ihrem Konto ausgeschlossen). Der Angreifer hat außerdem den Vorteil, eine Liste aller Sites zu besitzen, auf denen Sie sich befinden Mit SQRL ist es immer noch eine schreckliche Situation, den Diebstahl einer Hauptdatenbank auszunutzen. Mit SQRL ist es immer noch eine schreckliche Situation, Ihren Hauptschlüssel zu stehlen, aber der Angreifer hat keine Liste von Websites, auf denen Sie ein Konto haben (stattdessen raten müssen) ) und kann Ihr Passwort nicht ändern, um Sie auszusperren Ihres Kontos. Sobald Sie Ihren Identity Unlock-Schlüssel geladen haben, ist es auch etwas bequemer, Ihre Anmeldeinformationen auf jeder Site zu ändern, da der SQRL-Client dies automatisch für Sie für jede Site tun kann, die Sie bei der Anmeldung besuchen. (Keine Notwendigkeit zu gehen über alle „Passwort ändern“ -Formulare.)

Schließlich denke ich, dass SQRL einen kleinen, aber wichtigen Vorteil gegenüber Passwortmanagern in Bezug auf das Ziel hat, Passwörter vollständig zu ersetzen, und dass Websites die Möglichkeit haben, dies durchzusetzen Verwendung von SQRL gegenüber herkömmlichen Kennwörtern. Solange Benutzer weiterhin die Möglichkeit haben, die Sicherheit zu beeinträchtigen und auf jeder Site dasselbe Passwort wiederzuverwenden, wird dies immer noch passieren. Wenn SQRL eine breite Akzeptanz findet, können Sites die Verwendung tatsächlich auslaufen lassen Dies kann mit Passwort-Managern nicht gemacht werden, da sie auf die Verwendung von Passwörtern angewiesen sind, um zu arbeiten.

In Bezug auf die Nachteile kann ich mir tatsächlich keine Situation vorstellen, in der SQRL wäre zwangsläufig schlechter als Passwortmanager in Bezug auf Sicherheit. Der Hauptnachteil von SQRL besteht darin, dass die Unterstützung von Website-Betreibern erforderlich ist, während Kennwortmanager keine besondere Unterstützung von vorhandenen Diensten benötigen. Dies bedeutet, dass Sie sofort mit der Verwendung von Kennwortmanagern beginnen können. SQRL muss jedoch warten, bis die Sites es implementieren, bevor es verwendet werden kann. Dies ist ein erhebliches Hindernis für die Annahme.

Client-Zertifikate

Der Hauptvorteil von SQRL gegenüber Client-Zertifikaten liegt in der Benutzerfreundlichkeit. Client-Zertifikate sind derzeit kompliziert einzurichten, schwer zwischen Computern zu übertragen und haben Datenschutzprobleme, wenn dasselbe Zertifikat an verschiedenen Standorten verwendet wird. Während wir theoretisch ein System mit Client-Zertifikaten erstellen könnten, um diese Probleme zu lösen, würde es auch das Problem einer schlechten Integration mit Website-Benutzeroberflächen und Webservern geben, die schwieriger zu lösen sind. Ich werde hier nicht zu sehr ins Detail gehen, da es bereits einen ausgezeichneten Artikel zu Usability-Problemen von Client-Zertifikaten auf browserauth.net gibt. P. >

In Bezug auf die Sicherheit haben Client-Zertifikate den Nachteil, dass die Beteiligung einer Zertifizierungsstelle erforderlich ist. Dies ist (möglicherweise) teuer und erfordert das Vertrauen in die Zertifizierungsstelle eines Drittanbieters. Wenn Sie sich dafür entscheiden, Zertifizierungsstellen zu ignorieren und stattdessen Ihre Zertifikate selbst zu signieren, müssen Sie sich mit dem Problem der Zertifikatsperrung befassen. Client-Zertifikate haben dieselben Sicherheits- und Komfortprobleme wie Kennwortmanager, wenn Benutzer sich an einem nicht vertrauenswürdigen Computer anmelden möchten. Sie müssen ihr Zertifikat auf den nicht vertrauenswürdigen Computer übertragen, was sowohl unpraktisch ist als auch ihre Master-Identität möglicherweise Malware auf diesem Computer aussetzt.

Kurz gesagt, bis jemand eine bessere, benutzerfreundliche Lösung findet Client-Zertifikate, die (zumindest die meisten) dieser Probleme lösen. Ich glaube nicht, dass Client-Zertifikate ein ernstzunehmender Konkurrent von SQRL (oder auch von Passwörtern) sind.

2-Faktor-Authentifizierung

Ich dachte nur, ich würde das erwähnen: SQRL und 2-Faktor-Authentifizierung schließen sich nicht gegenseitig aus. SQRL ist ein Ersatz für den ersten Faktor in 2FA: Passwörter. Andere zusätzliche Maßnahmen wie OTP-Codes oder FIDO-U2F-Schlüssel können weiterhin mit SQRL verwendet werden.

WebAuthn

Jetzt hier , wo es interessant wird. WebAuthn ist ein neuer (nun ja, neuer als SQRL) W3C-Standard, der entwickelt wurde, um eine Standard-API bereitzustellen, mit der Websites Benutzer mit öffentlichen Schlüsseln im Web authentifizieren können. Genau wie SQRL, Es unterstützt mithilfe des Telefons des Benutzers zur Authentifizierung einer Anmeldesitzung auf einem externen Gerät sowie einige andere Authentifizierungsmethoden (z. B. Sicherheitsschlüssel für den zweiten Faktor). .

Hier trifft SQRL endlich seine Übereinstimmung, zumindest aus Sicherheitsgründen. WebAuthn bietet nicht nur den gleichen Schutz gegen die Wiederverwendung von Passwörtern, schwache Passwörter und Keylogging wie SQRL, sondern auch einen noch stärkeren Schutz gegen Phishing, indem es bei der Autorisierung eines Logins in den Browser des Benutzers integriert wird Sitzung für einen PC Der Benutzer hat die Client-Software des Authentifikators zuvor noch nicht eingerichtet. Dies ist möglich, da WebAuthn in dieser Situation direkt mit dem Browser des Benutzers über Zweiwege-Kommunikationsprotokolle wie Blutooth oder NFC kommuniziert und stattdessen über einen Einweg-QR-Code mit der vom Benutzer verwendeten Website kommuniziert.

Aus Sicht der Benutzerfreundlichkeit sind die Dinge etwas komplizierter. Zumindest oberflächlich gesehen gewinnt WebAuthn erneut. Da es sich um einen W3C-Standard handelt, der bereits in mehreren Browsern implementiert ist Theoretisch können Benutzer sofort mit der Verwendung von WebAuthn beginnen, ohne Software von Drittanbietern installieren zu müssen. In der Praxis konzentrieren sich die meisten vorhandenen WebAuthn-Implementierungen jedoch auf die Verwendung als Form der Zweitfaktorauthentifizierung oder als Möglichkeit zur erneuten Authentifizierung eines Benutzers Wer hat sich zuvor über eine andere Anmeldemethode (normalerweise ein Kennwort) auf demselben Gerät angemeldet? Als primärer Authentifizierungsfaktor fehlt WebAuthn immer noch eher an praktikablen Implementierungen.

Weitere geringfügige Überlegungen betreffen die Tatsache, dass SQRL vorhanden ist ein buil T-In-Methode zum Drehen der Schlüssel von Konten im Falle eines gestohlenen Hauptschlüssels, während WebAuthn auf Websites angewiesen ist, um ein eigenes System zum Widerrufen von Schlüsseln zu implementieren, und die Tatsache, dass WebAuthn bestimmte optionale Hardware (wie Bluetooth oder NFC) benötigt, um zur Authentifizierung bei einem Remotecomputer, während SQRL auf jedem Computer mit funktionierender Anzeige funktionieren kann.

Insgesamt halte ich es für sehr wahrscheinlich, dass WebAuthn SQRL irgendwann veraltet. SQRL hat vorerst vielleicht etwas Luft zum Atmen, aber WebAuthn wird von Browser-Anbietern, Website-Betreibern und anderen Drittanbietern (wie dem W3C) viel stärker unterstützt. Sobald WebAuthn einige Implementierungen erhalten hat, die seine Verwendung als primärer Authentifizierungsfaktor ermöglichen, wird es voraussichtlich sehr schnell das Web übernehmen.

Vorsichtsmaßnahmen

SQRL befindet sich noch in der aktiven Entwicklung. Das in dieser Antwort dargestellte Material kann sich daher ändern. Im weiteren Verlauf der Entwicklung erwarte ich, dass einige der Schwachstellen und Unsicherheiten in dieser Antwort behoben werden. Der größte Teil der Diskussion findet derzeit in der SQRL-Newsgroup bei grc.com statt.

SQRL ist eine bequeme Lösung für das Problem des Benutzernamens / password paradox. (dh der Kompromiss zwischen Komfort und Sicherheit) ohne Verwendung eines Drittanbieters . Es bietet eine einfache Alternative zum beliebtesten Authentifizierungsmodell (Benutzername & Passwort), wobei praktisch keine Kompromisse bei der Sicherheit eingeht. Es ist praktisch genauso sicher wie jedes der heute verwendeten Authentifizierungsmodelle , solange Sie noch sicherheitsbewusst sind . Wenn Sie SQRL verwenden, bedeutet dies nicht, dass Sie die besten Sicherheitspraktiken wie nicht befolgen können, wenn Sie dies mit der Multi-Faktor-Authentifizierung kombinieren. für wichtige Konten.

Es ist wichtig, den Punkt von SQRL nicht zu verpassen. SQRL selbst bietet keine bessere oder schlechtere Sicherheit. Wenn der Computer / das Telefon selbst kompromittiert wird oder der Benutzer betrogen wird Wenn Phishing durchgeführt wird, handelt es sich um einen Seitenkanalangriff anstelle eines direkten Fehlers von SQRL. Bei jeder herkömmlichen Authentifizierungsmethode tritt das Problem von Seitenkanalangriffen auf. Das unzerbrechliche einmalige Pad ist auch anfällig für Seitenkanalangriffe B. der Kompromiss des Pads selbst oder schlechte Sicherheit oder Implementierungen in der Umgebung.

Wenn Sie den ursprünglichen Vorschlag der Idee zu Steve Gibsons angehört haben Podcast , gefolgt von den Q & A „s, viele der in diesem Stack-Thread aufgeworfenen Bedenken wurden beantwortet. Außerdem sagte Steve selbst, dass diese sehr „einfache“ und „geniale“ Idee (seine Worte) von Sicherheitsexperten „überprüft“ und „eingeschlagen“ werden müsste, da nur die Zeit zeigen wird, ob dies eine sichere Lösung ist.

Zusammenfassend lässt sich sagen, dass die meisten Argumente gegen SQRL außerhalb des Bereichs von SQRL selbst liegen und stattdessen Probleme mit Menschen sind, die schlechte Sicherheit praktizieren. SQRL führt keine neue Klassifizierung von Problemen ein, die unsere traditionellen Authentifizierungsmethoden bereits nicht haben.

SQRL ist hervorragend, wenn es von sicherheitsbewussten Personen angemessen verwendet wird. Sie müssen verstehen, dass es immer einen Kompromiss zwischen Komfort und Sicherheit gibt , und diese Lösung ist wahrscheinlich die bestes Gleichgewicht der beiden, die ich gesehen habe.

Kommentare

• Danke Ansichart. Aber können ‚ vorhandene Authentifizierungslösungen nicht einfach gleiche oder überlegene Sicherheitsfunktionen wie SQRL beibehalten und dann mithilfe der Automatisierung den Benutzerkomfort erhöhen? Welche grundlegende Eigenschaft von SQRL ‚ ist nicht auf Automatisierung zurückzuführen? Ich frage, weil ein Benutzer zwei Blackboxen hat, die dasselbe tun. eine mit “ Mature “ und die andere mit “ SQRL “ und beide können entwickelt / automatisiert werden. Sie haben dieselbe Schnittstelle / dieselben Schaltflächen an der Außenseite der Box – welchen Mehrwert bietet SQRL?
• Es löst das Problem des Passwortparadoxons ohne einen Dritten benutzen zu müssen.
• Ich verstehe. Wenn also jemand ‚ das Risiko eines Single Sign-Ons von Drittanbietern nicht möchte und ‚ seine Passwörter nicht generiert / speichert Als Passwort-Manager kann SQRL aufsteigen. Wenn es sich bei SQRL jedoch um eine mobile Blackbox handelt, die nach einem Kennwort zum Entsperren des Hauptschlüssels fragt, der zum Wiederherstellen / Speichern von SQRLIDs verwendet wird, und dann eine Rückkanalverknüpfung des Cookies / QR des Clients ‚ durchführen session_id mit Server ‚ hat die SQRLID für die Anmeldung aufgezeichnet – wie unterscheidet sich diese mobile Blackbox von einem mobilen Passwort-Manager mit automatischer Anmeldung über denselben Rückkanal? oder ein Zwei-Parteien-Plug-In für mobile Clients mit automatischer Generierung & über denselben Rückkanal?
• Ich habe einige wichtige Änderungen an meinem ursprünglichen Beitrag vorgenommen Nach einigen zweiten Überlegungen und einer genaueren Lektüre dessen, was andere gesagt haben, habe ich es vielleicht übertrieben. Ich nehme an, dass das Mobiltelefon der zentrale Schlüssel ist, was das Problem verschiebt und es wichtiger machen würde, eine stärkere Sicherheit auf Ihrem Telefon zu haben. Steve Gibson spricht dies auch in der Q & A-Podcast an.

SQRL bietet keine bahnbrechenden Verbesserungen. QR-Codes sind ein optisches Barcode-Format, das für die Verteilung kurzer Inhalte nützlich ist – nichts weiter.

Jede „Auto-Login“ -Situation, die SQRL zu lösen versucht, könnte stattdessen einfach ein auf dem Mobiltelefon gespeichertes Client-Zertifikat verwenden.

Hypothetisch könnte ein QR-Barcode auf einer HTTPS-Seite eine vom Server signierte oder verschlüsselte Version des Client-Zertifikats (oder einen ähnlichen Berechtigungsnachweis) zurückgeben, wie sie dem Server zuvor bekannt war. Aber warum? Für den Ablauf der Anmeldeinformationen? Die Site könnte einen abgelaufenen Berechtigungsnachweis einfach direkt ablehnen.

Das größte Sicherheitsproblem habe ich damit Das Protokoll lautet: Das Vierkantrad neu erfinden .

Update

Beim Lesen neuer Antworten und Kommentare möchte ich darauf hinweisen, wie einfach es ist, etwas Ähnliches wie SQRL durch zu tun Einfache Automatisierung der ausgereiften vorhandenen Technologie :

1. Die Website fragt nach CAPTCHAs oder ähnlichen „I“ ma human „-Verifizierungen. Sobald der Benutzer die Anforderungen erfüllt hat (POSTed), gibt die Website einen HTTP 403.7 - Client Certificate Required – oder einen Vanilla 403-Fehler zurück.
2. Benutzerdefinierte 403-Seiten sind einfach genug einzurichten und können sehr hübsch und benutzerfreundlich sein. Könnte sogar die unten erforderliche Funktionalität auf ähnliche Weise wie die Eingabeaufforderungen „Adobe Reader erforderlich“ auf vielen Websites booten.
3. Die Seite „Benutzerdefiniert 403“ enthält einige Markups, auf die ein benutzerdefiniertes Browser-Plugin reagiert. Nennen wir dieses benutzerdefinierte Plugin „S403L-konform“ im Sinne von „SQRL-Konformität“.
4. Das S403L-Plugin generiert ein Standard-Client-Zertifikat, das im üblichen verschlüsselten Browser-Zertifikat-Cache (oder einem dritten) gesichert ist. Party-Cache, wenn die Keystore-Verschlüsselung Ihres Browsers nicht funktioniert. Das Plugin erstellt eine Standard-CSR für das Client-Zertifikat und sendet die CSR an die im 403-Markup angegebene URL (z. B. <s403l ref="https://www.example.com/S403L" />).
5. Der S403L-kompatible Server verwendet die Sitzungs-ID des Benutzers (aus Cookies oder Abfragezeichenfolge abgerufen), um Kontinuität mit Schritt 1 herzustellen, und gibt dann die vom Server signierte CSR zurück. Die allgemeine Serverauthentifizierung akzeptiert alle Client-Zertifikate, die vom Server signiert wurden (und somit die in Schritt 1 geforderten Registrierungskriterien erfüllen).
6. Das S403L-Plugin speichert das signierte Client-Zertifikat im Cache des Browsers. Von Anschließend kann sich der Standardbrowser ohne Plugin-Unterstützung auf standardmäßige SSL / TLS-Weise automatisch beim Server anmelden, bis das Zertifikat abläuft.

Die „mobile“ und „visuelle“ Natur von SQRL ist eine Art Fehlleitung, da es keine getrennte Zwei-Faktor-Authentifizierung bietet und Sie jetzt zwei Computer benötigen, um im Internet zu navigieren, anstatt nur einen. Es sei denn, Sie richten die USB-Webcam Ihres Desktops auf einen eigenen Monitor.

Die Kompromisse zwischen Kennwörtern und Zertifikaten sind in der Sicherheitsgemeinschaft genau definiert: Kennwörter passen in ein menschliches Gehirn, Zertifikate passen nicht hinein ein menschliches Gehirn ( normalerweise ), kann aber verrückte Entropie und gute PKI-Verwaltungsfunktionen aufweisen (Ablaufdatum) , Widerruf, Richtlinienerweiterungen usw.). SQRL passt sauber in kein Lager; und wenn es in Richtung des weniger menschlichen Lagers mit mehr Computern driftet, wie es scheint – es verfügt über jahrelange Entwicklungs- und Sicherheitsanalysen, um vorhandene X.509-Funktionen zu wiederholen.

Kommentare

• > könnte stattdessen einfach ein auf dem Handy gespeichertes Client-Zertifikat verwenden.— außer dass diese Technologie seit Jahren sowohl auf Mobilgeräten als auch auf Desktops existiert und ‚ nicht so weit verbreitet ist, wie man es sich wünscht. Im Gegensatz zum Client-Zertifikat müssen Sie bei SQRL ‚ nicht Ihre tatsächliche Identität nachweisen, um eine “ SQRL-Identität „. Wenn Sie möchten, können Sie so viele Identitäten erstellen, wie Sie möchten. Dies bedeutet, dass der Vorteil im Vergleich zu Client-Zertifikaten darin besteht, dass Sie von der Seite des Authentifizierungsprotokolls ‚ anonym sind.
• @jpkrohling Es kommt häufig vor, dass Client-Zertifikate falsch sind erfordern die Offenlegung der Identität zur Verwendung. Dies ist eine Anforderung der kommerziellen Unterzeichnungsbehörden, ihre global austauschbaren Vertrauensketten zu verwenden. In der Praxis kann ein Client-Zertifikat einfach eine anonyme CSR sein, die vom Client erstellt und von einem bestimmten Server signiert wird, nachdem alle gewünschten Kriterien erfüllt wurden (CAPTCHAs, vorheriges Konto, usw). Zertifikate können auch einen integrierten Ablauf haben. Type 40-L QR-Barcodes könnten auf Wunsch das 1 KB X.509-Clientzertifikat versenden / speichern.
• Ok, stimmt, mein schlechtes. Aus dieser Perspektive könnte der Client (z. B. mobile App) ein Client-Zertifikat für jede Website generieren, die der Benutzer registriert. Dies klingt teurer als das Hashing einiger Informationen, könnte aber eine interessante Lösung sein. Auf jeden Fall stimme ich ‚ Ihren Behauptungen, dass SQRL schlimmer als nutzlos ist, immer noch nicht zu.
• Ich habe diesen Wortlaut vielleicht hart genommen und werde ihn entfernen. Aber ‚ sehe SQRL nicht als etwas anderes als eine sexy Art, ausgehandelte Kundenanmeldeinformationen zu verteilen. und eine, die ‚ einige der subtilen Probleme, die durch ausgereifte Authentifizierungsschemata behoben werden, nicht gelöst hat. Ein Passwort-Manager ist langwierig (ich ‚ kümmere mich nicht um die Browser-Integration, weil ich ‚ ein Paranoiker bin), aber ich weiß, dass nur ich und einer Website teilen Sie jedes One-Shot-Passwort in meinem verschlüsselten Schlüsselspeicher. Ich muss mich nicht um ‚ kümmern, sondern nur um die Qualität des PRNG / TRNG, mit dem mein Passwort-Manager Passwörter generiert.
• @LateralFractal wen interessiert es, ob es ‚ neu ist oder nicht? SQRL ermöglicht eine benutzerfreundliche Authentifizierung, bei der die erste Partei ihr Geheimnis nicht gegenüber der zweiten Partei oder einer dritten Partei preisgibt, die möglicherweise die Sicherheit der zweiten Partei ‚ gefährdet hat. ‚ ist ein Versuch, ein Problem der realen Welt zu lösen, das bisher niemand sonst lösen konnte.

Ich möchte die erste Frage beantworten: „Eines der Probleme, an die ich denken kann, ist, wenn der QR-Reader kompromittiert ist, www.google.com anzuzeigen anstelle von www.nsa-super-secret-place.gov/123 „:

Der Hauptschlüssel wird zusammen mit der Website-Adresse (FQDN) als Startwert für HMAC verwendet. Obwohl der QR-Code möglicherweise eine völlig andere URL codiert, zeigt das Protokoll NICHT den Authentifizierungscode an, der normalerweise an www.google.com gesendet wird (im Beispiel).

Zweitens vergessen viele der Mitwirkenden die Hauptziele, wenn sie diese Idee ausarbeiten:

1. Anonymität durch Nichtverwendung der Benutzerfreundlichkeit von Drittanbietern
3. Auf nicht vertrauenswürdigen Computern müssen keine geheimen Anmeldeinformationen eingegeben werden.

Ich glaube, die Protokolle adressieren diese vollständig!

Es gibt jedoch tatsächlich Kompromisse kommen aus dem ersten Ziel. Wenn kein Dritter an der Authentifizierung beteiligt ist, wie kann man seine Authentifizierungsdetails widerrufen? Darüber hinaus ist die Sicherheit des Hauptschlüssels ein offensichtliches Problem. Ich gehe davon aus, dass dies durch zukünftige mobile Geräte in einem HSM-ähnlichen Chip gut geschützt ist. Bis dahin ist der Schlüssel nur ein Dateipin-Mobilgerät, das durch ein Kennwort geschützt ist, obwohl PBDKF2 sicherstellt, dass es sehr langsam ist, ihn tatsächlich brutal zu erzwingen.

Kommentare

• Was ‚ ist neu an dieser Idee? Es scheint mir eine primitive Variante des inzwischen nicht mehr existierenden Windows CardSpace zu sein.
• Ja, Sie haben Recht mit CardSpace. Dann gibt es U-Prove, das ebenfalls Microsoft gehört. Die Frage ist, wie Sie CardSpace oder U-Prove auf einem Computer verwenden würden, dem Sie nicht vertrauen (Internetcafé oder Computer eines Freundes). Das hat Steve hinzugefügt.
• Ah, ok, das ‚ hat mir gefehlt. Ich stimme @TerryChia weiterhin zu, dass dies ein Nichtstarter ohne Sperrmechanismus für die Benutzerschlüssel ist.
• @Xander Es gibt einen Sperrmechanismus für die Benutzerschlüssel. grc.com/sqrl/idlock.htm