Ich mag die Idee, aber auch ich habe noch viele Fragen offen. Bitte sehen Sie dies nicht als irgendeine Form von Bashing an, da ich es geschrieben habe, um meine Authentifizierungserfahrung auf dieses neue Schema anzuwenden.

Ich mache mir Sorgen (in keiner bestimmten Reihenfolge):

1. Nicht autorisierte Verwendung des privaten Schlüssels
2. Rich-Client-Unterstützung (Outlook, Notizen usw.)
3. Verwendung von mehreren Computern
4. Schutz des privaten Schlüssels oder Verschlüsselung (auf dem Client)
5. Authentifizierung von Schlüsselgenerierungsanforderungen
6. Datenschutz
ol>

Details unten. Zuerst eine einzeilige Zusammenfassung (in fett kursiv ) und einige Erläuterungen.

1. Nicht autorisierte Verwendung des privaten Schlüssels

Der private Schlüssel wird vom Client mit unterschiedlichen Sicherheitsstufen geschützt.

Ich mache mir Sorgen, dass der private Schlüssel ohne meine Zustimmung verwendet wird. Bei der Authentifizierung wird ein Signaturvorgang ausgeführt. Ich muss aufgefordert werden, bevor es verwendet wird, sonst könnte ein unerwünschtes Skript meinen Browser dazu bringen, ein Anmeldeticket zu signieren und zu senden. Rogue-Skript kann von einem Widget, Add oder einem anderen XSS stammen. Die Implementierung dieses Mechanismus variiert in jedem Browser und sogar auf verschiedenen Plattformen für denselben Browser oder in verschiedenen Versionen usw. Bei einer etwas inkonsistenten Darstellung besteht für Benutzer ein höheres Risiko, gelockt zu werden, um eine Anmeldeanforderung zu genehmigen. P. >

2. Umfangreiche Clientunterstützung (Outlook, Notizen usw.)

Es war vorgesehen, mit Webmail-Konten zu arbeiten. Enterprise "fette" Mail-Clients bleiben etwas zurück.

Damit die Browser-ID funktioniert, benötigen Sie einen Browser, der dies unterstützt. In der Zwischenzeit haben einige browserid.org "JavaScript-Shim veröffentlicht, das die fehlende Funktionalität unter Verwendung von Standard-HTML5-Techniken und in JavaScript implementierten kryptografischen Routinen implementiert".

Benutzer in einer Unternehmensumgebung, die einen Fat Mail-Client (Outlook, Notes, Thunderbird) verwenden, werden spät übernommen, da das Protokoll auch in diesen Clients implementiert werden muss. Ganz zu schweigen davon, dass Outlook keinen Keystore mit Firefox oder Thunderbird mit IE teilt.

3. Verwendung von mehreren Computern

Dies führt zu einer Zunahme privater Schlüssel, da das Schema keine zentrale Berechtigung haben soll.

Und es gibt ein Mobilitätsproblem. Ich muss mich für jeden Computer, den ich benutze, registrieren (einen privaten Schlüssel generieren). Wie lösche ich meinen privaten Schlüssel in einem Internetkiosk oder einem geliehenen Computer? Wie kann ich selbst mit einem einzelnen Computer einen in einem gestohlenen Computer gespeicherten Schlüssel widerrufen? Da für einen einzelnen Benutzer mehrere Signaturschlüssel gültig sind (da jeder meiner Computer einen eigenen gültigen privaten Schlüssel hat), muss aus Sicht des Dienstanbieters jedes von einer bekannten Behörde signierte Zugriffstoken gültig sein.

4. Schutz oder Verschlüsselung des privaten Schlüssels (auf dem Client)

Der Zugriff auf den Schlüssel muss authentifiziert werden, damit Kennwörter wieder im Bild angezeigt werden.

Es kann durch ein Kennwort geschützt werden (wodurch die böswillige Wiederverwendung eingeschränkt wird). Wenn ich mein Kennwort jedoch irgendwo ändere, wird es nur synchronisiert, wenn ich ein browser- / cloudbasiertes Synchronisierungsnetzwerk verwende. Ein Passwort zu haben, an das man sich etwas erinnert, macht den Zweck dieses Schemas zunichte. Möglicherweise wird für die Sicherung jedes Schlüssels dasselbe Kennwort verwendet, ähnlich wie jetzt dasselbe Kennwort für die Authentifizierung bei mehreren Websites verwendet wird.

5. Authentifizierung von Schlüsselgenerierungsanforderungen

Zwischen der Zugriffsanforderung und der Schlüsselgenerierung besteht eine Lücke, die ein Angreifer für Phishing verwenden könnte.

Es ist mir unklar, wie der E-Mail-Anbieter / die Zertifizierungsstelle mit CSRF-Problemen umgehen wird. Woher wissen sie, dass eine Anfrage zur Schlüsselgenerierung legitim ist? Wird mein Spam-Ordner mit Zertifikatsgenerierungsanforderungen gefüllt? Oder wird der Schlüssel nur mit DKIM-E-Mail-Servern ausgegeben? Was könnte geändert werden, wenn die Anforderung auf ihrem SMTP-Weg zum Server abgefangen wurde?

6. Datenschutz

Durch die Verwendung eines Tags kann browserid.org gegen dieselbe Ursprungsrichtlinie verstoßen.

Und die Verwendung eines Skript-Tags zum Einschließen Mit der Datei browserid.js können sie dieselbe Ursprungsrichtlinie umgehen. BrowserID.org wird (kann) über jeden Anmeldeversuch, den Sie unternehmen, Bescheid wissen. Oder Sie müssen das Skript selbst hosten (vorausgesetzt, es ist in sich geschlossen) und es aktualisieren, wenn darin Sicherheitslücken festgestellt werden.

Der Stapelaustausch bietet auch einen detaillierten Vergleich von BrowserId und WebID. Wie dort argumentiert, liegt BrowserId sehr nahe an WebID (einer W3C-Inkubatorgruppe am W3C). Hier sind einige Punkte aufgeführt, die normalerweise zur Verteidigung beider Protokolle gemacht werden müssen, da sie sich stark von der üblichen Kryptografie mit öffentlichen Schlüsseln unterscheiden.

1. Nicht autorisierte Skriptverwendung von Schlüssel . Stimmen Sie zu, dass dies von den BrowserID-Leuten sehr sorgfältig umgesetzt werden muss. Da WebID auf Browser-Zertifikaten basiert, die es seit 13 Jahren gibt, denke ich, dass dieser Teil schon vor langer Zeit behandelt wurde :-)
2. Wenn Sie Rich Client-Unterstützung wünschen, Verwenden Sie die WebID. Es ist lediglich ein TLSlayer erforderlich, der auf der Serverseite etwas optimiert wurde. Alle Betriebssysteme und alle Programmiersprachen sind mit integriertem TLS ausgestattet.
3. Verwendung von mehreren Computern : Mit BrowserID und WebID können Sie eine beliebige Anzahl von Zertifikaten haben, eines für jeden Computer. Das ist kein Problem. Informationen zur WebID finden Sie in diesem Video. Erstellung und Verwendung der WebID in 4 Minuten
Verschlüsselung mit privatem Schlüssel auf dem Client : Alle modernen Computer verfügen über einen entsprechenden Schlüsselbund speichert Ihre Passwörter und Schlüssel, die durch ein Passwort geschützt sind.

Es gibt eine Menge, an denen Betriebssystemanbieter arbeiten können, um die Sicherheit hier zu verbessern. Unter OSX werde ich nach einem speziellen Passwort gefragt, und ich kann verschiedenen Tools mehr oder weniger einfach Zugriff auf den Schlüsselbund gewähren. Natürlich sollte die Schlüsselkette NIEMALS den privaten Schlüssel ausgeben. Das Ausgeben des öffentlichen Schlüssels ist natürlich überhaupt kein Problem :-)

Aber für Desktops kann man natürlich noch weiter gehen und Kryptoschlüssel verwenden, wie im Video Cryptokeys, WebID und Internet Cafes - obwohl es Browser-Anbieter erfordern würde, die Benutzeroberfläche etwas zu verbessern. Hier haben Sie ein Hardwaretoken, um sicherzustellen, dass der private Schlüssel nicht kopiert wurde. Für BrowserID müssten sie dies in den Schlüsselbund integrieren oder eine JavaScript-Methode zum Senden von x509-Zertifikaten finden, die in der gespeichert sind Schlüsselbund über das Kabel.

4. Authentifizierung von Schlüsselgenerierungsanforderungen : Die Verwendung von E-Mail ist praktisch, aber von Natur aus unsicher. Es wird immer noch von Benutzern verwendet, und der Vorteil von BrowserID besteht darin, dass es damit funktioniert, ohne dass Benutzer auf TLS aktualisieren müssen. WebID funktioniert überall in TLS, sodass Sie sofort eine kommerzielle Sicherheit erhalten.
5. Datenschutz : Ich bin selbst nicht sehr gut in JavaScript und habe es auf meiner Liste der zu lernenden Dinge - Ich habe gerade zu viel Spaß mit Scala. Trotzdem kann ich dieses JavaScript-Problem mit BrowserId nicht kommentieren - möchte es aber besser verstehen. Mit WebID ist derzeit kein JavaScript beteiligt, daher gibt es kein Problem mit Richtlinien gleichen Ursprungs. Die Auswahl der Identität erfolgt direkt im Browser, wie im oben genannten Video gezeigt.
ol>

Oh Gott! Ich sollte hier noch einmal ein Konto erstellen, um diesen Kommentar zu posten! Kein Wunder, dass Facebook die Blogosphäre zerstört hat. Dort benötigen Sie nur 1 Passwort und können alles kommentieren, was Sie möchten.

Ich sende eine Antwort auf die sechs Punkte in der akzeptierten Antwort als neue Antwort ...

1. Nicht autorisierte Verwendung des privaten Schlüssels

Bei der Implementierung der Javascript BrowserID wird der private Schlüssel im lokalen Speicher unter der Domäne login.persona.org gespeichert. Ein Rogue-Skript müsste also auf dieser Domain gehostet werden, um Zugriff darauf zu haben. An anderer Stelle gehostete Skripte können nur indirekt über eine eingeschränkte PostMessage -basierte API auf den Schlüssel zugreifen.

2. Umfangreiche Client-Unterstützung (Outlook, Notizen usw.)

BrowserID funktioniert mit jedem E-Mail-Konto oder E-Mail-Client. Das Javascript-Shim unterstützt Browser ohne native Implementierung. E-Mail-Clients muss nichts hinzugefügt werden.

3. Verwendung von mehreren Computern

Ein wichtiger Punkt ist, dass Schlüssel nur von kurzer Dauer sind. Wenn Sie sich an einem Internetkiosk befinden, sind die Schlüssel nur 1 Stunde lang gültig. Wenn Sie sich auf Ihrem eigenen Gerät befinden, sind sie 1 Tag lang gültig. Nach Ablauf wird nach Bedarf eine neue generiert, sofern Sie noch bei login.persona.org authentifiziert sind. Keine Sicherungen erforderlich.

Wenn Sie Ihren privaten Schlüssel löschen möchten, löschen Sie einfach Cookies (wodurch auch der lokale Speicher gelöscht wird - wo die Schlüssel gespeichert sind).

Wenn sich Ihr Computer befindet gestohlen, gibt es ein kleines Fenster, in dem ein Angreifer den Schlüssel verwenden könnte, aber solange Sie Ihr Passwort auf login.persona.org ändern, wird der login.persona.org wird ungültig und der Dieb kann keinen neuen Schlüssel erhalten.

4. Schutz oder Verschlüsselung privater Schlüssel (auf dem Client)

Um einen neuen Schlüssel von Ihrem Identitätsanbieter signieren zu lassen, müssen Sie sich damit authentifizieren. Wenn diese Authentifizierung abläuft, müssen Sie Ihr Kennwort erneut eingeben. Dies ähnelt Cookie-basierten Sitzungen, die im Web die Norm zu sein scheinen.

Der private Schlüssel ist nicht besonders wertvoll, da er nur von kurzer Dauer ist. In dieser Hinsicht hat es mehr mit Cookies zu tun als mit X.509-Client-Zertifikaten.

5. Authentifizierung von Schlüsselgenerierungsanforderungen

Der Identitätsanbieter weiß, dass eine Anforderung legitim ist, da der Benutzer bei ihnen authentifiziert ist. Der Fallback-Identitätsanbieter signiert Schlüssel erst, nachdem er den Besitz der E-Mail-Adresse bestätigt hat (in der Standardmethode "Senden Sie Benutzern einen Link mit einem zufälligen Token zum Klicken").

Die Zertifikaterstellung / -signierung erfolgt zwischen der Browser und der Identitätsanbieter über eine Javascript-API. Es basiert nicht auf dem Senden von E-Mails, sodass Benutzer keine E-Mails erhalten, die über die Nachricht "Bitte bestätigen Sie Ihre E-Mail-Adresse" hinausgehen, die der Fallback-Identitätsanbieter zum Zeitpunkt der Kontoerstellung sendet.

6. Datenschutz

Sobald die API stabil genug ist, können andere include.js selbst hosten. Im Moment empfehlen wir dagegen.

Ein weiterer Punkt, an dem persona.org die Websites sehen kann, bei denen Sie sich anmelden, ist das Online-Überprüfungstool unter https://verifier.login.persona.org / überprüfe . Sobald das Datenformat festgelegt ist, werden wir die Benutzer dazu ermutigen, Behauptungen selbst zu überprüfen (z. B. mithilfe einer Open Source-Bibliothek), und persona.org erhält diese Daten nicht mehr.

BrowserID ist als vollständig dezentrales Protokoll konzipiert, um echte Privatsphäre zu ermöglichen. Es bietet jedoch auch zentralisierte Fallbacks, um den aktuellen Mangel an nativer Unterstützung zu umgehen.

Ein Nachteil von BrowserID in seiner aktuellen Form im Vergleich zu einigen Alternativen besteht darin, dass alles, was über die Kernfunktionalität hinausgeht, schwierig ist: Für die weitere Ermittlung von Informationen sind andere Protokolle wie WebFinger erforderlich, während z. Eine OpenID-URL kann Links bereitstellen. Zum Beispiel ist es schwierig, einen Anzeigenamen oder ein Profilbild von BrowserID zu erhalten (obwohl BrowserID Ihnen eine E-Mail-Adresse gibt, können Sie diese von Gravatar erhalten).

Ein weiteres konkurrierendes Protokoll, das hinzugefügt werden muss die Liste: WebID: http://webid.info/

Für ausführlichere Informationen zu BrowserId / Persona habe ich schließlich herausgefunden, was Daniel zu der zugehörigen Q&A auf BrowserId / Persona und WebID beigetragen hat. (Ich habe versucht, ihn zu überzeugen, hier zu posten, aber er hat mir vorgeschlagen, dies zu tun.)

Sicherheits-, Datenschutz- und Benutzerfreundlichkeitsanforderungen für Federated Identity von Michael Hackett und Kirstie Hawkey bietet einen Vergleich zwischen WebID und Mozilla Persona, die zu diesem Zeitpunkt noch als BrowserID bezeichnet wurde.

Die wichtigsten Unterschiede, die (in Tabelle 1) festgestellt wurden, sind:

• Persona-Schlüssel sind von kurzer Dauer und sollten mit einem Passwort geschützt werden. WebID-Schlüssel sind langlebig, können jedoch in einem kennwortgeschützten Profil leicht deaktiviert werden.
• Die aktuelle Persona-Implementierung verwendet Standard-Browserfenster, sodass Spoofing nur schwer zu erkennen ist (dies kann sich ändern, sobald Browser native Persona-Unterstützung erhalten). WebID verwendet die Benutzeroberfläche für die native Zertifikatauswahl des Browsers, sodass keine Phishing-Gefahr besteht.
• Sowohl die Persona- als auch die WebID-Identität können gefährdet werden, wenn die Kontrolle über die E-Mail / URI des Besitzers verloren geht.
• Persona-IDPs haben Keine Kenntnis von SPs, die eine Identität verwenden. WebID-IDPs kennen jeden SP, der eine Identität verwendet.
• Wenn ein Persona-SP über einen Cache des öffentlichen Schlüssels des IdP verfügt und der Browser weiterhin über ein gültiges Zertifikat verfügt, sollte es weiterhin möglich sein, Identitäten zu überprüfen. WebID-Profile müssen erreichbar sein, sonst können Identitäten nicht verwendet werden.
• Persona hat ein gutes UX-Design, während WebID das Gegenteil ist.

Ich empfehle, das Papier für weitere Details zu lesen . Es ist online frei verfügbar, kein digitaler Bibliothekszugriff erforderlich.