MIT-Kurs "Computer Systems Security". Vorlesung 17: Benutzerauthentifizierung, Teil 1

Massachusetts Institute of Technology. Vorlesung # 6.858. "Sicherheit von Computersystemen." Nikolai Zeldovich, James Mickens. 2014 Jahr

Computer Systems Security ist ein Kurs zur Entwicklung und Implementierung sicherer Computersysteme. Die Vorträge behandeln Bedrohungsmodelle, Angriffe, die die Sicherheit gefährden, und Sicherheitstechniken, die auf jüngsten wissenschaftlichen Arbeiten basieren. Zu den Themen gehören Betriebssystemsicherheit, Funktionen, Informationsflussmanagement, Sprachsicherheit, Netzwerkprotokolle, Hardwaresicherheit und Sicherheit von Webanwendungen.

Vorlesung 1: „Einführung: Bedrohungsmodelle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 2: „Kontrolle von Hackerangriffen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 3: „Pufferüberläufe: Exploits und Schutz“ Teil 1 / Teil 2 / Teil 3
Vorlesung 4: „Trennung von Privilegien“ Teil 1 / Teil 2 / Teil 3
Vorlesung 5: „Woher kommen Sicherheitssysteme?“ Teil 1 / Teil 2
Vorlesung 6: „Chancen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 7: „Native Client Sandbox“ Teil 1 / Teil 2 / Teil 3
Vorlesung 8: „Netzwerksicherheitsmodell“ Teil 1 / Teil 2 / Teil 3
Vorlesung 9: „Sicherheit von Webanwendungen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 10: „Symbolische Ausführung“ Teil 1 / Teil 2 / Teil 3
Vorlesung 11: „Ur / Web-Programmiersprache“ Teil 1 / Teil 2 / Teil 3
Vorlesung 12: Netzwerksicherheit Teil 1 / Teil 2 / Teil 3
Vorlesung 13: „Netzwerkprotokolle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 14: „SSL und HTTPS“ Teil 1 / Teil 2 / Teil 3
Vorlesung 15: „Medizinische Software“ Teil 1 / Teil 2 / Teil 3
Vorlesung 16: „Seitenkanalangriffe“ Teil 1 / Teil 2 / Teil 3
Vorlesung 17: „Benutzerauthentifizierung“ Teil 1 / Teil 2 / Teil 3

Also fangen wir an. Mit Ihrer Rückkehr hoffe ich, dass die Feiertage für alle ein Erfolg waren. Heute werden wir über die Benutzerauthentifizierung sprechen. Das Thema der Vorlesung ist es also herauszufinden, wie Benutzer ihre Identität gegenüber dem Programm nachweisen können. Insbesondere berührt der Artikel, der für die heutige Lektion gedacht ist, die Grundlagen einer Sicherheitsgemeinschaft. Gibt es etwas Besseres für die Authentifizierung als Passwörter?



Auf höchster Ebene scheinen Passwörter eine schreckliche Idee zu sein, da sie eine sehr geringe Entropie aufweisen und für Angreifer leicht zu lösen sind. Die geheimen Fragen, mit denen wir vergessene Passwörter wiederherstellen, haben noch weniger Entropie als die Passwörter selbst, und dies scheint auch ein Problem zu sein.

Und noch schlimmer, Benutzer verwenden normalerweise auf vielen verschiedenen Websites dasselbe Kennwort. Dies bedeutet, dass eine Sicherheitsanfälligkeit in einem leicht zu erratenden Kennwort die Arbeit des Benutzers mit vielen Websites gefährdet.

Ich mochte das folgende Zitat aus einem Artikel zum heutigen Vortrag: "Die anhaltende Dominanz von Passwörtern unter allen anderen Methoden der Benutzerauthentifizierung ist ein großes Hindernis für die Sicherheitsforschung." Daher möchte die Sicherheitsforschungsgemeinschaft eine bessere Alternative als Passwörter haben. Es ist jedoch unklar, ob es tatsächlich ein Authentifizierungsschema gibt, das Kennwörter vollständig ersetzen kann, während es bequemer, umfassender und sicherer ist.

Heute werden wir drei Themen betrachten. Zunächst werden wir uns ansehen, wie vorhandene Passwörter funktionieren. Danach werden wir über die global gewünschten Kennworteigenschaften für jedes Authentifizierungsschema sprechen. Abschließend werden wir uns ansehen, wie der Vorlesungsartikel zu Metriken oder Authentifizierungsfunktionen aussieht und wie einige andere Authentifizierungsschemata hinsichtlich ihrer Effizienz mit Kennwörtern verglichen werden.



Was ist ein Passwort? Das Passwort ist ein gemeinsames Geheimnis für Benutzer und Server. Daher sollte eine primitive Implementierung eines Kennwortschemas grundsätzlich nur eine serverseitige Tabelle enthalten, die Benutzernamen ihren Kennwörtern zuordnet.

Dies ist der einfachste Weg, sich die Implementierung eines der Authentifizierungsschemata vorzustellen: Der Benutzer gibt seinen Namen und sein Kennwort ein, der Server sucht in dieser Tabelle nach ihnen, vergleicht das Kennwort mit dem Namen und wenn alles übereinstimmt, wird der Benutzer authentifiziert. Das Problem ist natürlich, dass ein Angreifer, wenn er in den Server eindringt, einfach in diese Tabelle schauen und alle Passwörter übernehmen kann. Das ist also eindeutig eine schlechte Sache.

Möglicherweise besteht die Lösung für dieses Problem darin, die Tabelle auf dem Server zu speichern. Dies sieht folgendermaßen aus: Der Benutzername entspricht nicht dem Kennwort selbst, sondern seinem Hash. In diesem Fall gibt der Benutzer das Kennwort im Klartext ein, der Server überprüft seinen Hashcode und vergleicht ihn mit dem Wert in der Tabelle. Der Vorteil dieses Schemas besteht darin, dass diese Hash-Funktionen so gestaltet sind, dass es schwierig ist, den Hash in ein Kennwort umzukehren. Wenn diese Tabelle verloren geht, ein Datenleck vorliegt oder der Angreifer den Server gehackt und in Besitz genommen hat, werden anstelle von Textkennwörtern Zeichenfolgen mit zufälligen alphanumerischen Zeichen angezeigt, und es wird für ihn schwierig sein, das ursprüngliche Image wiederherzustellen.

Zumindest theoretisch ist die Verwendung von Hashes eine ziemlich gute Sache. In der Praxis müssen Angreifer jedoch keinen Brute-Force-Angriff verwenden, um das umgekehrte Bild des Hash-Werts zu bestimmen.



Angreifer können die Tatsache wirklich ausnutzen, dass Passwörter in der Praxis ungleichmäßig verteilt sind. Und mit der ungleichmäßigen Verteilung meine ich ... Nehmen wir an, wir wissen, dass alle Passwörter bis zu 20 Zeichen lang sind. In der Praxis verwenden Benutzer nicht den gesamten Bereich und bevorzugen Kennwörter wie 123, todd oder ähnliches. Empirische Studien haben jedoch gezeigt, wie solche Passwörter funktionieren, und es wurde festgestellt, dass etwa 20% der Benutzer die 5000 beliebtesten Passwörter verwenden. Mit anderen Worten bedeutet dies, dass ein Angreifer, der über eine Datenbank mit diesen 5000 Kennwörtern verfügt, diese problemlos hashen und beim Anzeigen der gestohlenen Kennworttabelle einfach die Hashes abgleichen kann. Empirisch kann ein Hacker also etwa 20% der in der Servertabelle enthaltenen Kennwörter wiederherstellen.

Yahoo-Experten fanden heraus, dass Passwörter 10 bis 20 Bit Entropie und 10 bis 20 Bit Zufälligkeit enthalten. In der Tat ist das nicht so sehr. Angesichts der Komplexität beim Erstellen einer Hash-Funktion berechnen moderne Maschinen jede Sekunde Millionen solcher Hashes. Daher muss eine Hash-Funktion im Design leicht berechenbar sein, damit Computer Passwörter leicht hashen können. Die Kombination dieser Tatsache mit einer unzureichenden Zufälligkeit von Passwörtern bedeutet jedoch, dass dieses Schema im Prinzip nicht so sicher ist, wie es scheint.

Es gibt eine Sache, mit der Sie versuchen können, das Leben eines Hackers zu verkomplizieren - dies ist eine komplexe Funktion zum Generieren eines Schlüssels. In diesem Fall meine ich, dass der Passwort-Hash als Quelldaten verwendet wird, auf deren Grundlage der Server einen Schlüssel generiert, der auf dem Server gespeichert ist.



Das Gute an diesen Funktionen zur Schlüsselgenerierung ist, dass sie eine anpassbare Komplexität aufweisen. Das heißt, Sie können einen bestimmten Knopf drehen und diese Funktion langsamer oder schneller arbeiten lassen, je nachdem, wie viel Sie an Prozessleistung sparen möchten.

Angenommen, Sie möchten einen Schlüssel generieren. Ein Beispiel ist der PBKDF2-Schlüsselgenerierungsstandard oder möglicherweise BCrypt. Weitere Informationen finden Sie im Internet. Stellen wir uns vor, dass eine dieser Funktionen zur Schlüsselgenerierung eine ganze Sekunde und nicht einige Millisekunden benötigt, um zu berechnen. Tatsächlich wird dies die Arbeit des Angreifers erheblich erschweren, da der Versuch, Werte für die 5000 "Top" -Kennwörter zu generieren, viel länger dauert.

Auf der internen Ebene funktionieren diese Funktionen zur Schlüsselgenerierung häufig, indem sie wiederholt einen Hash aufrufen und mehrmals darauf zugreifen, sodass alles ziemlich einfach ist. Aber löst die Verwendung des zeitaufwändigen Schlüsselgenerierungsprozesses das Sicherheitsproblem, mit dem wir konfrontiert sind? Die Antwort lautet Nein, da eines der Probleme darin besteht, dass der Gegner so genannte Regenbogentabellen oder „Regenbogentabellen“ erstellen kann. Eine Regenbogentabelle ist einfach eine Karte, wie ein Passwort mit einem Hashwert übereinstimmt. Selbst wenn das System eine dieser teuren Schlüsselgenerierungsfunktionen verwendet, kann ein Angreifer eine dieser Tabellen einmal berechnen. Dies kann etwas kompliziert sein, da die Verarbeitung jeder Schlüsselgenerierungsfunktion ziemlich langsam ist. Ein Angreifer kann diese Tabelle jedoch einmal erstellen und dann alle nachfolgenden Systeme auf der Grundlage derselben Algorithmen für Schlüsselgenerierungsfunktionen knacken. So funktionieren diese Regenbogentabellen.

Ich wiederhole noch einmal: Um den wirtschaftlichen Nutzen der Erstellung der Regenbogentabelle zu maximieren, kann ein Angreifer die ungleichmäßige Verteilung von Passwörtern nutzen, über die ich zuvor gesprochen habe. Daher kann ein Angreifer eine solche Tabelle nur für einen kleinen Satz aller möglichen Passwörter erstellen.

Student: Wahrscheinlich macht "Salzen" es viel schwieriger?

Professor: Ja, genau. Wir werden in ein paar Sekunden zum "Salzen" gehen. Wenn Sie kein Salting verwenden, ermöglichen Regenbogentabellen einem Angreifer im Offline-Modus mit einiger Anstrengung, diese Tabelle zu berechnen, und profitieren dann von der Möglichkeit, grundlegende Kennwörter basierend auf der geleisteten Arbeit zu berechnen.

Das nächste, woran Sie denken könnten, um die Situation zu verbessern, ist das Salzen. Wie funktioniert es Das Grundprinzip besteht darin, eine zusätzliche Zufälligkeit in die Kennwortgenerierungsmethode einzuführen. Sie nehmen diese Hash-Funktion, geben das "Salz" und dann das Passwort ein und alles wird in einer Tabelle auf dem Server gespeichert.



Was ist Salz? Dies ist nur eine lange Zeichenfolge, die den ersten Teil dieser Hash-Funktion darstellt. Warum ist es besser, dieses Schema zu verwenden? Beachten Sie, dass das „Salz“ auf der Serverseite tatsächlich im Klartext gespeichert wird. Sie könnten denken: Nun, wenn dieses „Salz“ auf der Serverseite im Klartext gespeichert ist und ein Angreifer eine Tabelle mit Benutzernamen für Passwörter stehlen kann, warum kann er dann nicht auch dieses „Salz“ stehlen? Was nützt eine solche Lösung?

Student: Wenn Sie das am häufigsten verwendete Passwort gewählt haben, können Sie es nicht nur einmal verwenden und einen neuen Benutzer finden.
Professor: absolut wahr. Grundsätzlich verhindert das Salz, dass der Angreifer einen einzigen Regenbogentisch erstellt, der gegen alle Hashes verwendet werden kann. Im Prinzip können Sie "Salz" als eine Möglichkeit betrachten, selbst dieselben Passwörter eindeutig zu machen. In der Praxis verwenden viele Systeme das Konzept des "Salzens".

Tatsächlich ermöglicht das „Salz“, diesem Pseudokennwort so viele Bits wie möglich hinzuzufügen, da je mehr Bits, desto besser. Was noch getan werden muss, ist zu berücksichtigen, dass, wenn der Benutzer sein Passwort ändert, auch das „Salz“ geändert werden muss. Denn einer der Gründe für diese Entscheidung ist die Faulheit der Benutzer, die dasselbe Passwort mehrmals verwenden möchten. Durch Ändern des "Salt" wird sichergestellt, dass sich das in der Kennwortdatenbank gespeicherte Objekt tatsächlich unterscheidet, selbst wenn ein Kennwort durch genau dasselbe Kennwort ersetzt wird.

Teilnehmerin: Warum heißt es "Salz"?

Professor: Das ist eine gute Frage, und ich kann sie nicht sicher beantworten. Ich bin mir jedoch sicher, dass es dafür eine Rechtfertigung gibt. Warum werden Cookies Cookies genannt? Das Internet weiß wahrscheinlich warum, aber ich weiß es nicht.

Student: Vielleicht, weil „Salz“ dem Hash einen kleinen „Geschmack“ verleiht?

Professor: Nun, ich bin froh, dass wir das filmen, weil wir eindeutig die Chance haben, einen Filmpreis zu bekommen. Ich bin mir sicher, dass es im Internet eine Antwort gibt, also werde ich später danach suchen.
Die obigen Ansätze sind also recht einfach. Ich nahm an, dass der Benutzer das Passwort irgendwie an den Server sendet, gab aber nicht an, wie dies geschieht. Wie geben wir diese Passwörter weiter?

Zunächst können Sie das Passwort einfach im Klartext über das Netzwerk senden. Dies ist schlecht, da sich möglicherweise ein Eindringling im Netzwerk befindet, der den von Ihnen gesendeten Datenverkehr überwacht. Er kann einfach ein Passwort vergeben und sich als Sie ausgeben.

Deshalb beginnen wir immer mit einem Strohmann, bevor ich Ihnen die anderen Strohmänner zeige, die natürlich auch tödlich fehlerhaft sind. Das erste, woran Sie denken könnten, ist das Senden des Passworts im Klartext. Aus Sicherheitsgründen ist es viel besser, ein Passwort über eine verschlüsselte Verbindung zu senden, daher verwenden wir Kryptografie. Es ist möglich, dass wir einen geheimen Schlüssel haben, mit dem das Passwort konvertiert wird, bevor es über das Netzwerk gesendet wird. Auf höchster Ebene scheint es also, dass Verschlüsselung immer besser funktioniert, wie eine Marke, die die Produktqualität garantiert.

Das Problem ist jedoch, dass Sie die Sicherheitsvorteile, auf die Sie zählen, nicht nutzen können, wenn Sie nicht sorgfältig überlegen, wie Verschlüsselung und Hashing verwendet werden sollen. Wenn sich zum Beispiel jemand zwischen Ihnen befindet - der Benutzer und der Server, dieser berüchtigte Angreifer, der „Mann in der Mitte“, der Ihren Datenverkehr tatsächlich überwacht und sich als Server ausgibt.

Wenn Sie verschlüsselte Daten senden, ohne die andere Seite zu authentifizieren, kann ein Problem auftreten. Weil der Client einfach einen zufälligen Schlüssel auswählt und ihn an ein Ziel auf der anderen Seite sendet, das möglicherweise der Server ist oder nicht.

Tatsächlich senden Sie etwas an eine Person, die danach die Möglichkeit erhält, alle Ihre Geheimnisse in Besitz zu nehmen.

Vor diesem Hintergrund denken die Leute vielleicht, dass es viel besser ist, nicht das Passwort selbst, sondern dessen Hash zu senden. Tatsächlich gibt Ihnen dies allein nichts, denn unabhängig davon, ob Sie ein Kennwort oder einen Kennwort-Hash senden, hat dieser Kennwort-Hash dieselbe semantische Stärke wie das ursprüngliche Kennwort und hilft nicht, wenn Sie den Server nicht authentifiziert haben.

Der wichtigste Punkt ist also, dass das Hinzufügen von Verschlüsselung oder Hashing nicht unbedingt zusätzliche Sicherheitsvorteile bietet. Wenn der Client sich nicht authentifizieren kann, an wen er das Passwort sendet, gibt der Client das Passwort möglicherweise fälschlicherweise an jemanden weiter, der nicht beabsichtigt, es weiterzugeben.

Daher ist es vielleicht eine bessere Idee als die beiden vorherigen, das sogenannte Challenge / Response-Protokoll oder das Challenge / Response-Protokoll zu verwenden. Hier ist ein Beispiel für ein sehr einfaches Anruf- / Antwortprotokoll. Hier haben wir einen Client und hier haben wir einen Server. Der Client teilt dem Server mit: „Hallo, ich bin Alice“. Danach beantwortet der Server den Anruf mit einem Anruf C. Anschließend antwortet der Client mit einem Hash dieses vom Server gesendeten Anrufs und kombiniert ihn mit dem Kennwort.



Der Server kennt die Antwort, sodass der Server diese Sequenz - die Antwort des Clients - im Moment akzeptieren kann. Der Server kennt auch die von ihm gesendete Herausforderung und kennt vermutlich das Kennwort, sodass der Server den Wert des empfangenen Hash berechnen und feststellen kann, dass er tatsächlich mit dem vom Benutzer gesendeten übereinstimmt.

Ein positives Merkmal dieses Protokolls ist, wenn wir für eine Sekunde die Existenz eines „Mannes in der Mitte“ ignorieren, dass der Server sicher ist, dass der Benutzer wirklich Alice ist, da nur Alice dieses Passwort kennt. Wenn Alice dieses Ding nicht an den Server, sondern an die Person sendet, die vorgab, der Server zu sein, kennt sie das Passwort nicht. Da ein Angreifer C verwenden kann, das Kennwort jedoch noch nicht kennt und das Kennwort herausfinden muss, muss er diese Hash-Funktion erneut umkehren. Haben Sie Fragen?

Student: Kann ein Client, anstatt ein Passwort an einen Server zu senden und einen Hash-Server-Anruf zu empfangen, einfach ein Hash-Passwort an den Server senden?

Professor: Das heißt, Sie fragen, warum der Client das Hash-Passwort einfach nicht an den Server sendet? Dafür gibt es zwei Gründe. Wir werden später darauf eingehen. Es heißt Antihammering-Schutz und wurde erstellt, um sich gegen "schlechte" Clients zu verteidigen. Dabei wird ständig gefragt: "Ist dies ein Passwort oder ist dies ein Passwort, vielleicht ist dies ein Passwort?" Dieser Authentifizierungsmechanismus vereinfacht den Prozess sowohl für den Server als auch für den Client. Sie können jedoch im Wesentlichen einen Hash auf der Clientseite mit JavaScript oder ähnlichem erstellen. Die Grundidee ist jedoch, dass Sie irgendwie die maximale Authentifizierungskomplexität sicherstellen müssen, um zu verhindern, dass der Angreifer das Kennwort schnell errät. Noch Fragen?



Student: Ich wollte nur beachten, dass selbst wenn der Client Hashing ausführt, jemand in das Netzwerk eintreten kann, wenn er die Kontrolle über die Servertabelle übernimmt und diese zum Hashing verwendet.

Professor: absolut wahr. Ja, es wird ein wenig gefährlich, je nachdem, wer diesen Anruf C in Besitz nehmen kann. Wenn der Client und der Server die Werte dieses C auswählen können, erschwert dies die Fähigkeit des Clients, solche Angriffe zu organisieren. Eines der Probleme bei der Verwendung dieses Protokolls besteht darin, dass der Client diesen HCC-Wert nicht randomisieren kann. Man kann sich vorstellen, dass Sie dieses Protokoll für die Serverinversion komplizierter machen können, wenn der Client einen C-Aufruf im HCC-Teil auswählen kann. In diesem Fall werden jedoch Client- und Serveraufrufe nebeneinander gestellt.
Wenn es keine weiteren Fragen gibt, gehen wir davon aus, dass wir die Diskussion der Kennwortübertragungsmechanismen vom Client zum Server abgeschlossen haben. , , brute-force, -, .

, , , HCC. , «». « ».

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

Antihammer – , , . , , brute-force , . , Antihammer – , , : « ».



-, . , 10 , : « 10 , ». . «» , TPN . ? – , , , .
, , , - . , , - , , . – . , , .

, — , , — . , , . , . , , .

, , , Dictionary attack, « ». , , Microsoft Telepathwords. . , , , Telepathwords , . , , , , .



«», , , , , «».



«» , . Telepathwords? , , . , .



, . , , . , .

, Telepathwords , , , , , . .
, — , , , .

: , , IP- , Antihammer .

: , . Antihammer IP-, , . , Antihammer , – . , Antihammer , , , , , , .

, . , . , .

: Antihammer? , , ? , , SRP Zero Knowledge Protocol, ZKP, …

: , ?

: ?

:ja, werden verwendet. Diese Protokolle bieten stärkere Verschlüsselungsgarantien. In den meisten Fällen sind sie nicht abwärtskompatibel mit aktuellen Systemen, sodass Sie in der Praxis nicht bemerken, wie oft sie verwendet werden. Es gibt jedoch einige Protokolle, mit denen der Server überhaupt nicht weiß, wie das Kennwort lautet, z. B. ZKP, die in der Praxis tatsächlich verwendet werden.

27:20 min

MIT-Kurs "Computer Systems Security". Vorlesung 17: Benutzerauthentifizierung, Teil 2


Die Vollversion des Kurses finden Sie hier .

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden empfehlen, einen Rabatt von 30% für Habr-Benutzer auf ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s von $ 20 oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s bis Dezember kostenlos, wenn Sie für einen Zeitraum von sechs Monaten bezahlen, können Sie hier bestellen.

Dell R730xd 2 mal günstiger? Nur wir haben 2 x Intel Dodeca-Core Xeon E5-2650v4 128 GB DDR4 6 x 480 GB SSD 1 Gbit / s 100 TV von 249 US-Dollar in den Niederlanden und den USA! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?