Lieber Habrozhitel! Sehr geehrte Experten! Ich präsentiere für Ihre Einschätzung ein neues Konzept der Benutzeridentifikation auf Websites, das mit Ihrer Hilfe hoffentlich zu einem offenen Internetstandard wird und diese Internetwelt ein wenig besser macht. Dies ist eine Entwurfsversion des kennwortlosen Authentifizierungsprotokolls, die als kostenloser Artikel konzipiert wurde. Und wenn die zugrunde liegende Idee von Ihnen, lieber Leser, positiv bewertet wird, werde ich sie weiterhin auf reddit.com und rfc-editor.org veröffentlichen. Und ich hoffe, dass ich Entwickler führender Browser für deren Implementierung interessieren kann. Deshalb erwarte ich von Ihnen konstruktive Kritik.

Achtung: viel Text.


Die Frage ist also. Ist es möglich, Website-Besucher eindeutig zu identifizieren, ohne ihre persönlichen Daten preiszugeben und zwischen verschiedenen Websites zu verfolgen? Ist es möglich, bei der Lösung eines solchen Problems die primitivste Form der Autorisierung durch Login / Passwort vollständig aufzugeben und Cookie / localStorage zu verwenden?

Einerseits müssen Websites einen Kunden erkennen, um beispielsweise seine Einstellungen, den Warenkorb, Anzeigen, Artikel usw. „wiederherzustellen“. Auf der anderen Seite möchten Besucher so anonym wie möglich bleiben, ohne ihre persönlichen Daten preiszugeben und zu verhindern, dass Websites von Drittanbietern sie verfolgen. Und letztere können dies tun, indem sie die gesammelten Daten untereinander austauschen.

Es klingt nach einer Aufgabe, dafür zu sorgen, dass die Wölfe voll und die Schafe in Sicherheit sind. Ist das echt?

Ich denke bis zu einem gewissen Grad - wirklich.

Inhaltsverzeichnis

1 Passwortloses Authentifizierungskonzept
1.1 Schlüssel und Token anstelle von Anmeldungen und Passwörtern
1.2 Token-Struktur
1.3 HTTP-Protokoll-Header
1.4 Wie identifizieren Kunden Websites?
1.4.2 Woher weiß ich, ob eine Site dieses Protokoll unterstützt?
1.5 Wie autorisieren Kunden Websites?
1.6 Wie implementiere ich eine zuverlässige Kundenidentifikation?
1.7 Autorisierung auf der Website durch die Augen des Benutzers
1.8 Wie ändert sich ein Site-Schlüssel?
1.9 Wie wird die domänenübergreifende Autorisierung implementiert?
1.10 Wie implementiere ich eine domänenübergreifende Authentifizierung?
1.11 Kontomobilität

2 Technische Beschreibung des Protokolls
2.0 Algorithmus zur Generierung von Domänenschlüsseln
2.1 der Algorithmus zur Berechnung des Quell-Tokens
2.2 Token-Schutzalgorithmus während der Übertragung
2.3 Salzaustauschverfahren zwischen Browser und Server
2.4 Regeln für die Bildung des Kontextfeldes
2.5 Regeln zum Definieren von Absender- und Empfängerfeldern
2.6 Details zu Kontextdefinitionstabellen
2.7 Protokollszenarien
2.8 Token auf dem Server verarbeiten
2.9 Domänenübergreifende Authentifizierung

3 Sicherheitsempfehlungen
3.1 Schutz der Schlüsselinformationen vor unbefugtem Zugriff
3.2 Informationen zu Passwörtern als Domänenschlüssel
3.3 Risiken des Verlusts / der Gefährdung von Schlüsseln und ihrer Minimierung

4 Angriffe auf das Autorisierungsschema
4.1 Benutzerverfolgung
4.2 XSS-Angriff
4.3 CSRF-Angriff
4.4 Tracking mit SSO
4.5 Schlüsselkompromiss für SSO
4.6 Token-Kompromiss während der Übertragung
4.7 Eine Website hacken und Token kompromittieren

Fazit

1 Passwortloses Authentifizierungskonzept

1.1 Schlüssel und Token anstelle von Anmeldungen und Passwörtern

Für jede Domäne, einschließlich untergeordneter Domänen, generiert der Client-Browser zufällig einen eindeutigen 256-Bit-Schlüssel $$ . Dieser Schlüssel wird niemals übertragen. Bleibt innerhalb der Benutzersitzung konstant. Jede neue Sitzung erstellt einen neuen Schlüssel.
Schlüsselbasiert $$ Der Browser generiert mithilfe eines speziellen Algorithmus ein 256-Bit ^* -Token $$ um den Benutzer mit einer bestimmten Domain zu identifizieren. Identifikations-Token $$ Der Benutzer (im Folgenden einfach als Token bezeichnet) dient als Ersatz für Sitzungscookies wie PHPSESSIONID und JSESSIONID.
Schlüssel $$ kann vom Benutzer " repariert " werden. Durch das Fixieren des Schlüssels kann der Benutzer unbegrenzt in verschiedenen Browsersitzungen auf der Site autorisiert bleiben und die zuvor vorhandene Autorisierung zurückgeben. Dies ist ein Analogon zur Funktion „Erinnere dich an mich“ .
Wenn das Festschreiben abgebrochen wird, "vergisst" der Browser diesen Schlüssel und beginnt erneut, für jede neue Sitzung (ab der aktuellen Sitzung) einen zufälligen Schlüssel für diese Domäne zu generieren , der dem "Beenden" des Benutzers von der Site entspricht. Die Ausgabe erfolgt sofort und erfordert kein erneutes Laden der Seite.
Der Benutzer kann einen permanenten Schlüssel für die Domäne erstellen . Mit dem permanenten und dem festen Schlüssel kann der Benutzer die vorherige Autorisierung zurückgeben. Tatsächlich wird dieser Schlüssel ein Ersatz für die Login-Passwort-Verbindung.
Der Benutzer hat die Möglichkeit zu steuern, wann und wann der Browser für die Domain einen konstanten Schlüssel verwendet. Dies ist ein Analogon zur Login / Logout-Funktion . Das Konzept ist in den folgenden Screenshots dargestellt .
Methoden zum Generieren persistenter Domänenschlüssel ermöglichen die Mobilität von Benutzerkonten zwischen verschiedenen Geräten. Das Protokoll definiert Folgendes:

• Generierung eines Domänenschlüssels basierend auf einem Benutzerhauptschlüssel
• Individuelles Bilden eines Domänenschlüssels basierend auf einem biologischen Zufallszahlensensor
• Importieren vorhandener Schlüssel aus einer Schlüsseldatei von einem anderen Gerät

1.2 Token-Struktur

Das Token ist eine 256-Bit-Struktur, die als hexadezimale Zeichenfolge dargestellt wird:

Der Identifikationsteil des Tokens (die höchsten 128 Bits) ähnelt dem Login. Durch diese Folge von Bits kann der Server den Benutzer eindeutig identifizieren.
Der Authentifizierungsteil des Tokens (die unteren 128 Bit) ähnelt dem Kennwort. Diese Folge von Bits hilft dem Server, das Token zu validieren.
Token-Validierungsregeln werden unten beschrieben .

1.3 HTTP-Protokoll-Header

Vom Client verwendete Header:

CSI-Token : <Token> wird verwendet, um ein Token an den Server zu senden
CSI-Token : <Token1>; Geändert zu <Token2> wird verwendet, um das aktuelle Token zu ändern:

• Wenn Sie einen permanenten Schlüssel autorisieren,
• bei der Registrierung eines permanenten Schlüssels,
• beim Ändern des permanenten Schlüssels.

CSI-Token : <Token> Permanent wird verwendet, wenn der Benutzer den aktuellen Zufallsschlüssel festlegt.
CSI-Token : <Token> Abmelden wird verwendet, um die aktuelle Sitzung vorzeitig zu beenden.

Vom Server verwendete Header:
CSI-Unterstützung: yes teilt dem Client mit, dass der Server das CSI-Autorisierungsprotokoll unterstützt.
CSI-Token-Aktion: Erfolg wird verwendet, um den Browser über die Akzeptanz eines neuen Benutzertokens (Change-To-Schlüssel) zu benachrichtigen.
CSI-Token-Aktion: Abbruch bricht die Prozedur zum Ändern von Token ab (Rollback auf das vorherige Token).
CSI-Token-Aktion: Die Registrierung teilt dem Browser mit, dass sich das neue Benutzertoken noch in der Registrierung befindet.
CSI-Token-Aktion: Ungültiger Fehler bei der Überprüfung des serverseitigen Tokens.

Endlich
CSI-Salt wird sowohl vom Browser als auch vom Server gesendet, wenn das zum Schutz des Tokens verwendete „Salt“ (Authentifizierungsteil) ausgetauscht wird. Siehe unten für weitere Details.

1.4 Wie identifizieren Kunden Websites?

Eine Site kann ein Token verwenden, um einen Site-Besucher zu identifizieren. Gleichzeitig garantieren das Token-Generierungsschema und ihre 256-Bit-Kapazität eindeutige Token für jedes Paar: Benutzerdomäne. Eine andere Domain sieht ein anderes Benutzertoken. Auch wenn im Kontext der Zielsite ausgeführt (über IFRAME, IMG, LINK, SCRIPT). Darüber hinaus schützt ein spezieller Algorithmus zur Token-Generierung Benutzer vor XSS- und SRF-Angriffen und macht es unmöglich, einen Benutzer ohne sein Wissen zu verfolgen. Gleichzeitig bleibt die SSO- Technologie mit ihrer Erlaubnis und domänenübergreifenden Identifizierung möglich.
Das Token wird im CSI-Token-HTTP-Header bei jeder Anforderung an eine beliebige Domänenressource (Seite, Dokument, Bild, Skript, Stil, Schriftart, Datei, Ajax-Anforderung, ...) übertragen:

Das Token wird bei jeder HTTP (S) -Anforderung neu berechnet : Seite, Bild, Ajax-Anforderung.
Um die Berechnungen zu optimieren, ist das Zwischenspeichern von Token durch den Browser zulässig, jedoch nur für die Dauer der Sitzung und nur, wenn die Bedingungen für die Erfüllung der Anforderung unverändert bleiben.
Wie oben erwähnt, kann das Token als Ersatz für Sitzungscookies wie PHPSESSIONID und JSESSIONID dienen. Der einzige Unterschied besteht darin, dass der Client diese Funktion jetzt selbst ausführt, wenn die Site zuvor eine Kennung für den Besucher generiert hat, um einen bestimmten Benutzer zwischen seinen verschiedenen Anforderungen zu verfolgen (schließlich kommen Tausende von Anfragen von verschiedenen Benutzern gleichzeitig auf die Site).
Eine solche Identifizierung reicht völlig aus, um Einkäufe im Online-Shop zu tätigen, auf geeigneten Websites zu werben, in Foren, in sozialen Netzwerken, Wikipedia- oder Habré-Artikeln zu schreiben.
Ja, der Benutzer bleibt für die Site anonym. Es kann sich jedoch um einen anonymen „Vertrauten“ der Website handeln. Und der Server kann das Token eines solchen Benutzers zusammen mit seinen Daten (persönliches Konto mit Einkäufen, Vorlieben, Karma, Brötchen, Likes und anderen Boni) auf seiner Seite speichern. Aber nur, um unter der Bedingung des Abschlusses eines Geschäftsprozesses zu bleiben: Kauf, Einreichung der Ankündigung usw. Die Bedingungen werden von der Site selbst bestimmt.
Wie Sie sehen, ist das Protokoll für Websites, die Sie nicht registrieren müssen, so einfach wie möglich, bevor Sie die Möglichkeit haben, Maßnahmen zu ergreifen. Aber diejenigen, die es brauchen, werden es etwas schwieriger haben. Aber mehr dazu weiter unten.

1.4.2 Woher weiß ich, ob eine Site dieses Protokoll unterstützt?

Die Site sollte den CSI-Support: yes http-Header im Abschnitt Antwortheader ihrer Antwort bestehen:

Sobald der Browser einen solchen Titel sieht, informiert er den Benutzer unauffällig darüber, dass er sich auf der Website speichern kann. Zum Beispiel das Schlüsselsymbol in der Adressleiste:

Wenn Sie beispielsweise auf einen Schlüssel klicken, wird ein Schlüssel für die Domain www.youtube.com erstellt :

Die Bildung eines neuen Schlüssels führt nicht zu seiner automatischen Verwendung.

Der permanente Schlüssel wird erst verwendet, wenn er vom Benutzer aktiviert wird.

1.5 Wie autorisieren Kunden Websites?

, , – . , , – «».
, , , . .

: . . - .

« » . . « »:

Sie müssen natürlich zuerst einen permanenten Schlüssel für die Site erstellen. Dies ist jedoch nur eine Frage von ein paar Mausklicks.
Und natürlich werden Sie aufgefordert, Ihr Telefon oder Ihre Postanschrift zu bestätigen. Aber es kommt schon auf die Seite an.
Nach erfolgreicher Autorisierung informiert der Server über einen speziellen HTTP-Header CSI-Token-Action den Browser darüber, dass er den neuen Schlüssel akzeptiert hat. Weitere Details in Kapitel II .

1.6 Wie implementiere ich eine zuverlässige Kundenidentifikation?

( , , ) , : , , . (, . , ).

1.7

, CSI, . , . :


, . :


, :


, -. . . , - / :


- «» :


. «» :

( ) HEAD, CSI-Token <>; Logout.

, , Logout. , ( ). , .
: , ajax-, .. – , .

: , , . «» . .

1.8 ?

, . II .
, , CSI-Token Changed-To :

. , , . . (Response Headers) : CSI-Token-Action: success , .
(, ) CSI-Token-Action: aborted.
, CSI-Token-Action, CSI-Token Changed-To.
« » .

1.9 - ?

Die klassische domänenübergreifende Autorisierung mithilfe der SSO- Technologie bietet dem Benutzer viele Vorteile. Sie müssen sich nicht eine Reihe von Passwörtern von einer Reihe von Websites merken. Es ist nicht erforderlich, sich zu registrieren und die trostlosen Formulare auszufüllen. Einige Autorisierungsserver fragen, welche Rechte die Site gewähren sollen, die das SSO angefordert hat.
Es gibt aber auch Nachteile. Sie sind abhängig vom SSO-Anbieter. Wenn der SSO-Server nicht funktioniert, gelangen Sie nicht zum Zielstandort. Wenn Sie Ihr Passwort verlieren oder Ihr Konto gestohlen wird, verlieren Sie den Zugriff von allen Websites gleichzeitig.
Für Webentwickler sind die Dinge etwas komplizierter. Von Anfang an müssen Sie Ihre Site auf dem Autorisierungsserver registrieren, die Schlüssel abrufen, lernen, wie Sie mit dem Protokoll ( SAML , OAuth usw.) und den entsprechenden Bibliotheken arbeiten, sicherstellen, dass der Schlüssel nicht abläuft, dass der Autorisierungsserver Ihre Site aus Ihren Gründen nicht blockiert und usw. Dies ist eine Gebühr für die Tatsache, dass Sie keine Benutzerkonten führen, keine Registrierungsformulare erstellen, sich nicht anmelden usw. müssen. Die Wahrheit erhöht die Wartungskosten (in Form der Reparatur plötzlicher Ausfälle). Wenn der Server für die Site plötzlich nicht mehr verfügbar ist, dann leider.
Dieses Autorisierungsschema macht SSO etwas sicherer und die Autorisierung für alle Teilnehmer ist einfacher. Informationen zur Sicherheit finden Sie weiter unten im Abschnitt "Key Compromise for SSO".

Schauen Sie sich Website S an, die das SSO von Google unterstützt. Angenommen, Sie haben ein Google-Konto. Um sich anzumelden, klicken Sie auf den Link "Mit Google anmelden", um die Registerkarte "Google-Autorisierung" zu öffnen. Der Browser teilt Ihnen mit, dass Sie einen Schlüssel für Google haben. Und Google wird Ihnen mitteilen, welche Rechte S. anfordert.
Wenn Sie damit einverstanden sind, klicken Sie im Schlüsselmanager auf "Anmelden". Die Seite wird neu geladen. Google erhält bereits seinen gültigen Token, erkennt und autorisiert Sie. Bei einer Anfrage zwischen Servern wird Site S gemäß den angeforderten Feldern über Ihre Kontoinformationen informiert.
Die neu geladene Seite enthält eine Schaltfläche "Weiter", mit der Sie zur Zielwebsite zurückkehren.


Site S kann entscheiden, ob Daten über Sie in seiner Datenbank gespeichert werden sollen oder nicht. Dieses Problem geht über den Rahmen des vorgeschlagenen Genehmigungsschemas hinaus. Wenn wir jedoch das Risiko des Verlusts des Schlüssels für SSO berücksichtigen, wird der Site empfohlen, das Benutzertoken und die Kennung von SSO auf seiner Seite zu halten, und dem Benutzer wird empfohlen, einen permanenten Schlüssel für S zu erstellen.

Sicherheitslücke: Nach einer solchen Autorisierung können die Websites S1, S2, S3, ... (auf denen Sie sich über Google angemeldet haben) Sie erkennen (anhand der Ihnen von Google zugewiesenen Kennung) und als Ergebnis Ihre Aktivitäten verfolgen.

Schutzoption: Arbeiten Sie nicht gleichzeitig auf Websites, wenn Sie sich über das SSO desselben Anbieters registriert haben. Melden Sie sich nach Möglichkeit sofort nach Abschluss der Autorisierung vom Autorisierungsserver ab ("Auto-Exit" für die Domain).

1.10 Wie implementiere ich eine domänenübergreifende Authentifizierung?

Das alles ist natürlich gut. Während die Arbeit in einem Browser ausgeführt wird, ist alles in Ordnung. Aber was ist mit der modernen Realität, wenn eine Person zwei Mobiltelefone, einen funktionierenden Computer und mehrere Browser, einen Heimcomputer und einen anderen Laptop hat? Plus eine gemeinsame Tablette für die Frau / Kinder.
Wir müssen das Problem der Übertragung von Domänenschlüsseln zwischen Browsern und Geräten irgendwie lösen. Und lösen Sie auch das Problem ihrer korrekten Synchronisation.
Einer der Mechanismen zur Lösung dieses Problems besteht darin, verschiedene Domänenschlüssel basierend auf einem gemeinsamen Hauptschlüssel zu berechnen, ohne die Möglichkeit einer umgekehrten Wiederherstellung des Hauptschlüssels von einem bekannten Domänenschlüssel.
Nachdem ein Benutzer einen persönlichen Schlüssel K für Domäne D unter Verwendung eines Hauptschlüssels M auf einem Gerät erstellt hat, kann er denselben Schlüssel K für Domäne D und auf jedem anderen Schlüssel unter Verwendung desselben Hauptschlüssels M und eines einzelnen Algorithmus erstellen. Genauer gesagt wird dies nicht vom Benutzer, sondern von seinem Browser durchgeführt. Bei diesem Ansatz reicht es für den Benutzer aus, seinen Hauptschlüssel auf alle von ihm verwendeten Browser zu verteilen, und er "überträgt alle seine Schlüssel" von Domänen gleichzeitig. Gleichzeitig werden auf diese Weise Backups erstellt.
Maximaler Benutzerkomfort. Aber auch das maximale Risiko bei Kompromittierung des Hauptschlüssels. Letztere müssen daher entsprechend geschützt werden. Die Risiken des Verlusts oder der Beeinträchtigung des Hauptschlüssels und Möglichkeiten zur Minimierung solcher Risiken werden im Kapitel „3 Sicherheitsempfehlungen“ beschrieben .
Die Verwendung nur eines Hauptschlüssels zum Generieren aller Schlüssel für alle Domänen ist nicht immer eine bequeme Option. Was tun, wenn plötzlich der Domänenschlüssel kompromittiert wird und geändert werden muss? Was ist zweitens, wenn Sie einen Domain-Schlüssel mit einer anderen Person teilen müssen? Zum Beispiel zwischen Familienmitgliedern. Oder handelt es sich um ein öffentliches E-Mail-Zugriffskonto für Unternehmen? Wie kann man dann seinen Schlüssel "abholen" (weil er tatsächlich kompromittiert wurde)?
Daher muss die Generierung einzelner Domänenschlüssel mithilfe eines biologischen Zufallszahlensensors von Browsern unterstützt werden. Aber dann kehren wir noch einmal zu der Frage unserer Mobilität und den Fragen der Synchronisation, den Funktionen zum Exportieren und Importieren von Schlüsseln im Browser und zum Erstellen von Sicherungskopien zurück.

Übertragung durch ein physisch veräußerbares Gerät

Smartcards und USB-Token eignen sich durchaus als sichere Speicherung von Schlüsselinformationen (da sie dafür erstellt wurden). Die Zwei-Faktor-Authentifizierung schützt Schlüssel vor unbefugtem Zugriff durch direkten Zugriff auf das Gerät.
Für Smartcards sind spezielle Lesegeräte erforderlich (ganz zu schweigen von Treibern), die ihre Verwendung nur auf Workstations beschränken, die mit solchen Lesegeräten ausgestattet sind.
Mit USB-Token etwas einfacher. Es werden nur Treiber benötigt. Sie können einen solchen Token jedoch nicht in das Telefon stecken. Und obwohl es für Mobiltelefone Token in Form von SD-Karten gibt, heißt das nicht, dass diese Lösung die Mobilität erhöht. Versuchen Sie, eine Karte von einem Mobiltelefon zu ziehen, aber legen Sie sie in eine andere ein. Und das ist nicht unmöglich. Die Sache ist, dass es nicht bequem ist.
Und wenn der Token kaputt geht? Dann gehen alle deine Schlüssel zum Großen Cthulhu.
Bei einem solchen Schema besteht also die Versuchung, mehrere doppelte Geräte zu verwenden. Wenn Sie mehrere Smartcards haben, müssen Sie das Problem mit der Schlüsselsynchronisierung noch lösen.
Und ehrlich gesagt sind solche Geräte nicht vor Keyloggern geschützt. Nun, wenn der PIN-Code von der Karte / dem Token selbst eingegeben werden würde. Dann noch etwas. Aber ich habe solche in der Natur nicht gesehen.

Vorteile: Es können zufällige 256-Bit-Schlüssel verwendet werden. hohe Sicherheit durch Zwei-Faktor-Authentifizierung; das höchste Schutzniveau gegen direkte Manipulation.
Nachteile: Geräteabhängigkeit; erfordert finanzielle Kosten; geringe Mobilität; die Notwendigkeit, Karten zu reservieren und infolgedessen Daten zwischen ihnen zu synchronisieren; Die Anfälligkeit für Keylogger bleibt bestehen.

Synchronisierung über Online-Service

"Cloud-Technologie" wird jetzt wo immer möglich verschoben. Es scheint, dass sie zusammen mit der Blockchain ein Ersatz für die "Bananentechnologie" geworden sind. Natürlich besteht der Wunsch, eine bestimmte Internetplattform für den Austausch von Schlüsselinformationen zu nutzen. Eine Art Smartcard "online".
Und was? Sie melden sich anonym mit unserem Schema auf einer solchen Website an. Senden Sie Ihre Schlüssel dort verschlüsselt mit einem Passwort. Sie wechseln mit demselben Schlüssel / Passwort von einem anderen Gerät zur selben Site. Sie bekommen die Schlüssel von dort; Sie synchronisieren Änderungen nach dem Datum der Bearbeitung. Ähnlich wie beim Passwort-Manager ist nur dieser online.
Das heißt nur, niemand garantiert, dass der Onlinedienst nicht gehackt wird oder Ihre, wenn auch verschlüsselten "erforderlichen" Schlüssel nicht zusammengeführt werden. Wer wird einen solchen Dienst kostenlos implementieren. Das war's.
Obwohl das Passwort die Schlüssel natürlich vor direkter Verwendung schützt. Aber ist Ihr Passwort gegen Brute Force "offline" resistent? Das ist eine andere Frage.

Vorteile: hohe Mobilität der Berechtigungsnachweise; Geräte- und Browserunabhängigkeit; Sie benötigen nur ein einziges Passwort (obwohl das Passwort nicht hinterlassen wurde, ist es bereits besser).
Nachteile: Weniger sicher als das Speichern von Schlüsseln auf einem veräußerlichen Medium. Tatsächlich basiert die Sicherheit der Schlüssel auf der Stärke des Kennworts für die Auswahl.

Sie können natürlich einen Hauptschlüssel verwenden, um andere Schlüssel zu verschlüsseln. Derjenige, mit dem andere Domänenschlüssel berechnet werden. Als Option.

2 Technische Beschreibung des Protokolls

2.0 Algorithmus zur Generierung von Domänenschlüsseln

Dieses Protokoll definiert nur zwei Methoden zum Generieren von Domänenschlüsseln.

• basierend auf einem Zufallszahlengenerator (vorzugsweise biologisch)
• basierend auf einem 256-Bit-Hauptschlüssel

Im letzteren Fall wird der Domänenschlüssel wie folgt berechnet:

$$

wo $$ - 256-Bit-Hauptschlüssel, Domäne - Domänenname, für den der Schlüssel erstellt wurde.
Im Folgenden ist HMAC ein kryptografischer Hash-Algorithmus, der auf einer 256-Bit-Implementierung der SHA-2- Hash-Funktion basiert.

Eine Kompromittierung oder freiwillige Offenlegung eines Domänenschlüssels gefährdet nicht den ursprünglichen Hauptschlüssel.

Der Hauptschlüssel bietet einen Mechanismus für die Mobilität von Benutzeranmeldeinformationen.

Wenn der auf der Grundlage des „Masters“ erstellte Schlüssel kompromittiert wurde oder das aus einem solchen Schlüssel berechnete Token (als Ergebnis des Hackens der Site) kompromittiert wurde, muss der Schlüssel geändert werden. Sie können es in einen zufälligen 256-Bit-Schlüssel ändern oder es mit demselben „Assistenten“ generieren, indem Sie eine Version hinzufügen:

$$

Im Folgenden das Symbol $$ wird für die Verkettung von Zeichenfolgen (Byte-Arrays) verwendet.

2.1 der Algorithmus zur Berechnung des Quell-Tokens

Das Authentifizierungstoken des Benutzers wird bei jeder Anforderung einer Domänenressource berechnet. Zur Berechnung des Anforderungstokens werden die folgenden Daten verwendet:

• Absender - Der Domänenname des Initiators der Anforderung (es kann sich um eine Seite mit einem Iframe oder einem Skript aus der Domäne einer anderen Person handeln, die den Abruf ausführt).
• Empfänger - Domainname des Empfängers (an den die Anfrage gesendet wird),
• Kontext - Anforderungsausführungskontext,
• Schutz - eine zufällige Folge von 32 Bytes (256 Bit), wenn der Kontext leer ist; sonst leer

Diese Daten werden verkettet und mit 256-Bit-SHA-2 auf dem Schlüssel K der Domäne gehasht, die die Anforderung initiiert :

$$

Ein gültiges Token wird erhalten, wenn der Kontext nicht leer ist. Für eine ordnungsgemäße Identifizierung am Zielstandort muss die Bedingung Absender = Empfänger = Kontext erfüllt sein.

Das Feld Kontext wird zusammen mit Schutz zum Schutz vor XSS- und CSRF- Angriffen sowie vor Benutzerverfolgung verwendet.
Detailliertere Erläuterungen zu den Regeln zur Bestimmung von Absender / Empfänger / Kontext finden Sie weiter unten.

2.2 Token-Schutzalgorithmus während der Übertragung

Das ursprüngliche Client-Token wird äußerst selten übertragen. Nur beim Übertragen eines nicht registrierten Tokens zum Zeitpunkt der Erstellung der Sitzung.
Ein Token gilt als nicht registriert, wenn es: auf der Grundlage eines zufälligen (nicht festen) Schlüssels erstellt wird; wurde vom Server nach dem Senden des Wechsels zum oder des permanenten Schlüssels nicht akzeptiert. Weitere Informationen finden Sie unter „Verarbeiten von Token auf dem Server“ .
Der Browser und der Server erzeugen gemeinsam ein Paar von Zufallszahlen, die sogenannten Salz (Salz), mit dem die unteren 128 Bits des Tokens gehasht werden. Beide tauschen diese Nummern gemäß dem Protokoll aus. Weitere Informationen finden Sie unter „Salt-Swap-Prozedur-Browser-Server“ .
Daher sieht der Standortserver das folgende Token:

$$

wo $$ - hohe 128 Bit, $$ - die unteren 128 Bits des ursprünglichen Tokens, $$ - Verkettung von Zeichenfolgen. In diesem Fall das erste Token $$ sollte dem Server bereits bekannt sein.

Im Idealfall sollte sich CSI-Salt jedes Mal ändern, wenn ein Browser einen Server anfordert. Dies kann jedoch eine kostspielige Anforderung in Bezug auf Rechenressourcen sein. Darüber hinaus kann die Möglichkeit, parallele Anforderungen an den Server zu senden, "beendet" werden.
Um die Berechnungen zu optimieren, dürfen die CSI-Salt-Werte daher in verschiedenen Anforderungen unverändert bleiben, jedoch nicht länger als eine Sitzung . Dies kann ein Zeitlimit (Änderung von CSI-Salt alle 5 Minuten) oder eine Reaktion auf die Intensität von Anforderungen (Änderung von CSI-Salt alle 100 Anforderungen) oder nach jeder Reihe von Anforderungen (zum Zeitpunkt der Pause, Client-Server) oder eine gemischte Version sein. Hier bleibt die Entscheidung den Browserentwicklern überlassen.
Wenn CSI-Salt zu lange unverändert bleibt, wird der Schutz des übertragenen Tokens geschwächt, sodass der Angreifer das Token abfangen kann, während der legitime Benutzer die Abmeldung abgeschlossen hat, und eine nicht autorisierte Anforderung im Namen des Opfers ausführen kann.

2.3 Salzaustauschverfahren zwischen Browser und Server

2.3.1 Token basierend auf einem zufälligen oder nicht registrierten ^[1] Serverschlüssel.

2.3.2 Token basierend auf dem vom Server registrierten Schlüssel ^[1] .

---

^{[1] Ein Token gilt als nicht registriert, wenn es: auf der Grundlage eines zufälligen Schlüssels erstellt wird; wurde vom Server nach dem Senden des Wechsels zum oder des permanenten Schlüssels mit der Antwort CSI-Token-Aktion: Erfolg nicht akzeptiert.
[2] Die Zeit, in der die CSI-Salt-Änderung vorgenommen wird, wird von den Browsern selbst festgelegt. Dies kann nach einer Reihe von Anforderungen, nach einer Zeitüberschreitung und nach einer bestimmten Anzahl von Anforderungen geschehen. – CSI-Salt .
[3] 16- 128- . , : _salt || S _salt . – , . , , .}

2.4 Context

Wir nennen unsere Domain, deren Seite wir laden (angezeigt in der Adressleiste des Browsers). Die restlichen Domains werden als extern bezeichnet . Auch wenn dies untergeordnete Domänen einer bestimmten sind.

Wir nennen die Ressource extern, wenn sie von einer externen Domain heruntergeladen wurde. Wir nennen die Ressource intern, wenn sie von unserer Domain heruntergeladen wurde. Die Ressource kann ein Skript, ein Bild, eine Ajax-Anfrage und eine beliebige andere Datei sein.

, . , <script>, , . , <script>, , , . <script> .

LINK, SCRIPT, IMG, IFAME , - , DOM – .

FORM, A, META , (submit, click, timeout) – .

, . , .

FORM , , INPUT, .

, , , , , , . .

. , , click ( ), submit ( ) onclick/onsubmit.

. – META http-equiv=«refresh» content=«0».

^{P. Context}


( SRC IMG), , , / , — , «».

^{R. Context /}

---

^{[1]
[2]
[3] Inherit , Empty
[4] Inherit , Empty (. )}


P1..PF, R1..RC .

Referrer Domain . , , , .

2.5 Sender Recipient

Der Absender ist die Domäne der Seite / des Skripts / des Stils, von der die Anforderung stammt. Die Seite fordert Stile, Bilder und Skripte an. Skripte fordern Inhalte über Ajax an. Stile können andere Stile laden. Dies sind die Initiatoren der Anfrage.

Empfänger ist die Domain, an die die Anfrage wirklich geht.

Damit keine Fragen mehr offen sind, betrachten wir konkrete Beispiele.

Lass es eine site.net Seite geben. Auf der Hauptseite der Website befindet sich:

• style site.net/css/common.css
• common.css-Stile importieren fonts.google.com/fonts/Roboto.css-Stile
• Der Roboto.css-Stil importiert die Schriftart fonts.google.com/fonts/Roboto.ttf
• Bild führt zu img.site.net/picture1.jpg
• Frame von adriver.ru/frame geladen
• Skript von adm.site.net/admin.js

Lassen Sie den Rahmen (mit adriver.ru) verbinden:

• Stil von adriver.ru/style.css
• Bild von img.adriver.ru/img/01.png
• Skript von adriver.ru/libs.js
• Skript von api.adriver.ru/v1/ad.js

Absender- / Empfängerwerte beim Laden von Ressourcen mit dem DOM-Parser

Betrachten wir nun die Werte von Absender / Empfänger beim Laden von Inhalten mit Skripten während der Ausführung von Ajax-Anforderungen.

Absender- / Empfängerwerte beim Laden von Inhalten mit Skripten

2.6 Context

, ( ) , Context .

P1 – submit . / . . .

site.net google.com, Context (google.com). site.net ( , ).

( ) P1 , Context site.net, .. Context = Referrer.

CSRF -.

P5 – , / , ; submit , / ( FORM, INPUT). / .

P9 – , P5 , , ( ).

PD – . .

URL . .

Wenn Sie einen Link über eine Desktop-Verknüpfung eines anderen Programms öffnen, sollte jede andere Situation, in der das Betriebssystem einen Befehl zum Öffnen des Links an den Browser sendet, als PG- Fall betrachtet werden (Öffnen des Links auf Initiative des Browsers). Selbst wenn der Benutzer F5 drückt, um die Seite neu zu laden, sollte dies als PG- Fall betrachtet werden . Nur wenn der Benutzer in die Adressleiste gelangt und die Eingabetaste drückt, wird er vom Browser als PD betrachtet .

Dies geschieht, um CSRF-Angriffe vor anderen Programmen zu schützen.

Context, , F5 ( ). , - ( P1 ).

, site.net, , . , , … , , , site.net.

P2 – , , click/submit. , . .

, Context . , Context .

P6 – , P2 , / / .

PA – , P2 , / / .

PE – window.location.href window.open(…).

site.net , Context . Context = site.net.

ya.ru, maps.ya.ru, Context . Context , .

, – . CSRF-.

P3 – P2 , click/submit . Context ( ), ( ).

P7 – P6 , / / .

PB – PA , / / .

PF – PE , .

P4 - Der Browser hat die Seite als Ergebnis der Verarbeitung des <META> -Tags neu geladen. Das Tag befand sich ursprünglich auf der Seite. Rechtliche Weiterleitung. Der Kontext bleibt auf der Originalseite erhalten. Wie bei PE .

P8 - Der Browser hat die Seite als Ergebnis der Verarbeitung des <META> -Tags neu geladen. Das Tag wurde jedoch durch ein eigenes Skript erstellt / geändert. Dies ist gültig, aber der Kontext bleibt auf der Originalseite erhalten. Wie bei PE . Es ist nicht möglich, das legale Token des Benutzers auf diese Weise zu locken.

PC - ähnlich wie P8 , nur externes Skript. Die geöffnete Site erhält eine Zufallszahl als Kontext.

PG – . , , . , , . , Context .

CSRF- .

, Context .

, , ( ) HTTP- Header. , Context . – .

- -.

, - . SSO- – .

« » , - . :

1. ;
2. SSO- , ;
3. SSO-;
4. SSO-, Changed-To, - ;
5. - «», ;
6. P1 , -, (, ).
7. -, , .

, , , . UI- :

SSO-. .

, , Context .

R1 – ( ). Context Context .

, site.net adriver.ru, img.disk.com, HTTP- img.disk.com Context , site.net.

R4 – , R1 . / , DOM Parser . , site.net/index.html site.net/require.js ( <script src=…>) site.net/min.js, main.js. Context , site.net.

R7 – , R1 . / , Context 256- . evil.com/drop.js, site.net, site.net , .. .

RA – . , site.net/css/common.css, site.net/index.html, fonts.google.com/fonts/Roboto.css, fonts.google.com Referrer = site.net/css/common.css. Context Referrer. Roboto.css Roboto.ttf, fonts.google.com/fonts/Roboto.ttf Referrer = fonts.google.com/fonts/Roboto.css. Context Referrer, .

, , Roboto.css ( ) /, CSRF- :

@import "https://site.net/api/payment?victim_params" 

in der Hoffnung, die Anfrage auf site.net im Namen eines autorisierten Benutzers zu erfüllen. Das Problem für den Angreifer ist jedoch, dass site.net erwartet, ein Token vom Benutzer zu erhalten:

$$

Dann erstellt der Browser wie bei einer solchen CSRF-Anforderung ein Token:

$$

Eine Anfrage an die Site erfolgt im Namen einer anonymen Site, die keine Zugriffsrechte zum Ausführen dieser Vorgänge besitzt.

RB - Der Inhalt wird vom eigenen Skript der Site hochgeladen. In diesem Fall wird der Kontext verwendet, um das Anforderungstoken zu berechnen, das der Seite entspricht, die das Skript enthält. Für das Skript site.net/1.js auf der Kontext-Seite site.net entspricht es dem Kontext der Seite selbst.

Beachten Sie, dass der Kontext der Seite selbst nicht immer dem Domänennamen der Seite entspricht und davon abhängt, wie sie ursprünglich geöffnet wurde.

Angenommen, die Site des Angreifers evil.com öffnet die Seite der angegriffenen Site site.net, auf der das Skript site.net/util.js eine Anforderung mit den über die Seiten-URL übergebenen Parametern ausführt. Der Angreifer hofft, durch Verschieben von „seinen Parametern“ durch die URL sein eigenes site.net/util.js-Skript zu zwingen, eine Ajax-Anforderung auszuführen, um wichtige Aktionen im Namen des Opfers auszuführen.

Angenommen, der Benutzer selbst ist über einen direkten Link zu evil.com gegangen. Dann ist der Kontext für evil.com evil.com. Weiter öffnet evil.com site.net/api/payment?victim_params mit einem Skript , in der Hoffnung, einen Angriff durchzuführen, aber das Kontextfeld für site.net ist leer (PE / PF-Fall). Das Skript site.net/utils.js, das eine Ajax-Anforderung ausführt, zwingt den Browser, den Kontext von der Seite site.net zu übernehmen. Und es ist leer bei uns. Aber dann erhält site.net eine Ajax-Anfrage mit diesem Token:

$$

Für einen autorisierten Benutzer wird Folgendes erwartet:

$$

site.net sieht ein unbekanntes Token und kann den Benutzer nicht identifizieren. Der Schutz hat funktioniert.

Übrigens ist es aufgrund eines solchen Schemas unrealistisch, eine domänenübergreifende Autorisierung über Popups durchzuführen.

Um SSO unter dem Protokoll zu implementieren, müssen Sie eine neue Registerkarte für die Seite des Autorisierungsservers öffnen. Gleichzeitig muss der Benutzer eine solche Registerkarte öffnen. Am besten öffnen Sie dem Benutzer den entsprechenden Link von der Zielwebsite.

RC - Inhalte werden mit einem externen Website - Skript geladen. In diesem Fall wird Context verwendet, um das Anforderungstoken zu berechnen, das dem Feld Request Referrer entspricht.

Trotz der Tatsache, dass RA , RB und RC vor CSRF-Angriffen schützen, führen sie dennoch zur Erzeugung konstanter Token. Auf diese Weise können Sie die domänenübergreifende Authentifizierung und die domänenübergreifende Benutzerauthentifizierung implementieren (wenn Sie feststellen müssen, dass mehrere Anforderungen an verschiedene Server von diesem Benutzer stammen). Was kann implementiert werden, um ihm die gleiche Autorität in einer Gruppe verwandter Domänen zu verleihen?

Wenn die Site-Seite automatisch von einer anderen Site aus geöffnet wurde , können Sie sich dort nicht anmelden, selbst wenn Sie diese Site selbst neu laden. Weil Source von einem Nullwert erbt. Der Browser sollte dem Benutzer dies mitteilen (Quelle = Zufall):

Dies geschieht zum Schutz vor Sites, die das Öffnen anderer Popup-Fenster erzwingen (selbst oder deren externe Skripte). Auf den geöffneten Sites werden sie neu gestartet oder es werden gefälschte Schaltflächen zum Schließen auf dem gesamten Bildschirm erstellt, die zu denselben Sites führen. Das heißt, Dies verhindert einen Versuch, Sie zu verfolgen, in der Hoffnung, ein gültiges Token zu erhalten.

Jeder Versuch der Site, Ihre Aktionen mit einem externen Skript nachzuahmen , oder ein Versuch eines externen Skripts, direkt oder indirekt ein initiierendes Tag zu erstellen und an Sie zu senden, führt zum Zeitpunkt der Berechnung des Token-Hash zu einer leeren Quelle und dem Hinzufügen von zufälligen Bytes.

Der Trick beim Erstellen oder Ändern des <script> -Tags auf der angegriffenen Seite im DOM hilft nicht weiter. Das Feld Quelle bleibt leer.

Unter den gleichen Bedingungen führen interne Skripte jedoch zu Abfragen, bei denen Source dem vorherigen Wert entspricht. Und wenn die ursprüngliche Seite Source = Domain hätte, wäre alles in Ordnung. Der Benutzer bleibt für solche Anfragen autorisiert.

Bei Skripten, die von Drittanbieter-Ressourcen (CDN) heruntergeladen wurden, können in einigen Fällen Probleme auftreten. Und es ist richtig, weil Die Integrität des CDN-Codes kann nicht garantiert werden. Wenn Sie die Benutzerberechtigung nicht verlieren möchten, behalten Sie die Skripte auf Ihrer Website und laden Sie sie von Ihrer Domain herunter. Dies ist so etwas wie das Verbot der Verwendung von http-Links auf https-Seiten.

Wir beschreiben die Situation, in die ein Entwickler geraten könnte. Aufgrund von Benutzeraktionen leitet Ihr Skript einen autorisierten Benutzer auf eine der Seiten der Site weiter (dies erfolgt beispielsweise über ein Formular), sodass der Benutzer weiterhin autorisiert bleiben muss. Ihr Skript ruft beispielsweise $ (form) .submit () mit einem vom CDN geladenen jQuery-Skript auf. In diesem Fall sieht der Browser, dass im Aufrufstapel, der das Übermittlungsereignis des Formulars ausgelöst hat, eine Funktion aus einem externen Skript vorhanden ist. Um XSS / CSRF- Angriffe zu verhindern, macht der Browser das Feld Quelle leer und fügt der Generierung des Tokens zufällige Bytes hinzu (Fall P9 ). Infolgedessen wird der Benutzer auf der neuen Seite plötzlich nicht mehr autorisiert und kann den Vorgang nicht abschließen. Dies kann für Entwickler, die an die Verwendung von CDNs gewöhnt sind, verwirrend sein.

2.7 Protokollszenarien

Hier sind die wichtigsten wahrscheinlichen Szenarien für die Arbeit des Benutzers mit der Site aufgeführt, die sich auf alle möglichen Situationen und die Phasen ihrer Implementierung auswirken (anonyme Anmeldung, "Erinnere dich an mich", "Vergiss mich", Umstellung auf die Verwendung eines permanenten Schlüssels, Autorisierung und Beenden, Registrierung und Zwei-Faktor-Authentifizierung, Export / Schlüsselimport, Schlüsselersatz usw.)

.htaccess.

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory> 

 cat /etc/apache2/.csi_keys 

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user 

2.7.1

K , «» T , . , : , . , vsphere.local, :

 Sender = Recipient = Context = vsphere.local 

() , :

$$

, . 128 , CSI-Salt ^* . , :

$$

Wobei Hi die hohen 128 Bit sind, Lo die niedrigen 128 Bit des ursprünglichen Tokens.
Bei geschlossenen Verwaltungskonsolen in einem Unternehmensnetzwerk laden Webkonsolen normalerweise keine externen Skripts, Frames usw. Daher ist diese Bedingung in den meisten Fällen erfüllt.

---

^{* Informationen zur Salzbildung finden Sie im Abschnitt „Salzaustauschverfahren zwischen Browser und Server“.}

2.8 Token auf dem Server verarbeiten

Senden eines Tokens an den Server (ohne Schlüssel)

Permanent

. , , . – . CSI-Token-Action: success CSI-Token-Action: abort.

Logout

, . «» , ( ), (« »).

, , . .

Change-To

T, – '.

: T' ( , ), ( 128 ).

---

^{* , .}

2.9 -

, - -, . , site.ru img.site.ru, download.site.ru, .

site.ru -, . , site.ru, , - . .

, .
site.ru :

$$

, site.ru site.ru :

• ( )

T ₁ (. R1 , R4 , RB ). site.ru.

site.ru, download.site.ru. ( R1 , R4 ):

$$

download.site.ru , ajax- site.ru ( RB , RC ).

domain :

$$

, , , A, B, C . - . , .

site.ru ajax- . ID != T ₁ , site.ru. ID T _x . ID . ID .

. , , .. site.ru .

3

3.1

, , .

.

:

• ( )
• «» ( )

, - ( « » ), . , PIN-; .

- . : ?

, -, «», -, , , : « - ».

^* ( ). , . 100% , . , , , .

, (.. ). ( ) , – . - .

: + ( API ). « ». .

, , . , , , . : .

( ). , , .

---

^{*, 32- 64- . .}

3.2

. , .

. . :

1. , «» , , . , -, .
   
   (), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .
   
   , , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . Das heißt, ~10 . 5 . 10- 15 . 10 , 1-2 .
   
   , .
2. , .
3. , . Das heißt, ( SHA-2).
4. , , , . .

3.3 /

-?

, . ?

, . -, -, . .

, , ? , ( « »)? « » ?

, , , . , . , (email, mobile). , (, ). , , 100% , – .

-, -.

? , . , , bitcoin. , - . . . «», .

-?
. - ( ) , , , - . , . javascript. . …

-?

. . Ruhig und ruhig. . . .

. , , , – . : , . , -.

. ( ). . IP- , , .

4

4.1

, , . -, . -, - – .

, , :

1. ( , ).
2. ( ) .

2 : , . == .

, № 2. «» ( ), «», , . , .

№ 1. .

1 H ₁ , 2, 1 – H ₂ . , (H ₁ , H ₂ ) -.
3, 2, . 3 H ₃ , 2, 3 – H _2' != H ₂ (. ). , , .. .

, fingerprint . , .

: , . .

4.2 XSS

XSS – , victim.com . , CDN .

. - ( ), ( ), ( ).

– Source .

: XSS ( ), . «». -.

4.3 SRF

evil.com, . (GET/POST/HEAD/PUT/DELETE) , (, ). (, ). , Referer . , .

CSRF , . . , . GET- ( ) .

.

4.4 SSO

S ₁ S ₂ , , , SSO, . .. (- ), ( ), S ₁ .

A, . S ₂ , ( S ₁ ) H ₁ . . S ₁ , S ₂ .

S ₂ .

 <meta http-equiv="refresh" content="0"> 

.

S ₂ A «»:

, . S ₂ H ₂ (.. 2.4 P1: ).

S ₂ S ₁ , H ₁ H ₂ , H ₂ S ₁ . S ₁ S ₂ , .. .

, .. , .

: . S ₂ , . , S ₁ S ₂ . .

4.5 SSO

, SSO, . .

.

.

, SSO, SSO. , . Das heißt, SSO – .

. .

- : Id- SSO . Id SSO . , .
(. « » ).

. , , SSO, - , .

. , – . - Id- . , , , .

: ( ). . . , . , , , .

. SSO ( , ). SSO ( !).

SSO (, ), .

4.6

, 100% . ( ), . .

SSL . HTTPS . , HTTP. .

, . .

– . , . . - , .

, , , Javascript . Cookie HttpOnly. ajax- .

: , , ( ). cookie .

: , , ; ( , ).

4.7

. . : , «». - – .

, -, .

, . . , .

, -: - .

, , , , . .

, , , -, :

$$

Fazit

, , : « ?»


! Leider. , «/».

1. , , popup

« cookie! , ! «», ».

popup . GDPR ( ).

. , cookie ! «». , . , +1 .

2. . SSO : OAuth, SAML, Kerberos .., , , ; - SSO, : « , ». . . , … , . = .



3. . . , . -, - . -. ?

4. , . . .

5. . XSS, CSRF. - . — .

6. . .

7. , . , , , , , , , . SQL-.

, , . «» , - . . , «-» .

– ,
.

---

PS
. Habr . , () . sergey201991[]. , . / . . -.

, , :

1. , , ;
2. ; , SSO
3. «», - : - ( )
4. -

. 1 — , : , 1000. .

. 2 — . . , . 80- , .

, !