 Hi, ich bin Leo und ich möchte heute ein bisschen mit euch über Brutforce Protection sprechen und warum das gar nicht so einfach ist, wie man vielleicht denken mag. Das Problem Brutforce, also Angriffe durch stumpfes Ausprobieren sind im Endeffekt so alt wie Passwörter selber. Also wenn ich einen Zahlenschloss habe, kann ich mich damit hinsetzen und die alle Kombinationen durchprobieren, habe ich es irgendwann früher oder später offen. Das ist also ein inherentes Problem von Geheimnissen. Das ganze ist jetzt mit einem Zahlenschloss relativ aufwendig, weil ich brauche relativ lange dafür, wenn ich jetzt aber einen Rechner habe, mit dem ich relativ schnell durchprobieren kann. Dann wird Brutforce plötzlich für mich so ein Problem und besonders seit dann halt Systeme über das Internet erreichbar waren, muss man sich da wirklich mit befassen. Wie ihr sehen werdet, tun aber viele gängige Lösungen, die versuchen das Problem Brutforce Angriffe zu mitigieren, das ist nur sehr ungenügend. Und grunddessen sind so ein bisschen, warum wir Brutforce Protection überhaupt brauchen, sind Passwörter selber. Wer von euch kennt diesen XKCD, der ist schon relativ alt, der fasst das ganz gut zusammen. Man könnte jetzt nämlich mal sagen, okay, wir kennen das vom Zahlenschloss, wenn ich jetzt einen Rechner habe, damit kann ich schnell durchprobieren, damit ist ein Zahlenschloss für mich nicht mehr sicher. Aber wenn ich jetzt beispielsweise so was habe, wie dieses Passwort hier oben, das hat 11 Stellen, 11 Stellen ASCII, sagen wir mal, weil das ist großen Kleinschreibungen, Zahlen und Sonderzeichen, ASCII hat 128 Zeichen, davon sind 95 druckbar. Wenn ich jetzt alle Passwörter durchsuchen möchte, die 11 Stellen haben und aus den 95 druckbaren ASCII Zeichen bestehen, dann brauche ich dafür relativ lange. Das sind 5,68 mal 10 hoch 21 mögliche Passwörter und dafür brauche ich eine Weile. Also wenn ich beispielsweise 1000 Passwörter pro Sekunde durchprobieren will, dann brauche ich über 180 Milliarden Jahre, bis ich da eine Ergebnis habe, bis ich alle durchsucht habe. Tatsächlich ist es aber meist relativ einfacher als das. Das liegt daran, dass Menschen nicht völlig zufällige Passwörter verwenden. Der einfachste Fall ist, Menschen neben Passwörtern wie Passwort oder Geheim. Das ist der Detail-Zufall, da kann ich einfach ein Wörterbuch drauf werfen. Oder ich nehme mir ein Wörterbuch, der 10.000 häufigsten Passwörter und damit werde ich schon in eine Menge Accounts reinkommen, tatsächlich. Und damit muss ich gar nicht mehr alles durchprobieren. Ein anderer Punkt, der ist ganz spannend, hängt ein bisschen damit zusammen, wie Menschen sich Passwörter merken. Und zwar hat man das untersucht, da gibt es tatsächlich eine ganze Menge Paper dazu, die sich damit beschäftigen, was ist die Psychologie. Dahinter, wenn Menschen Passwörter versuchen sich zu merken und zu generieren. Und tatsächlich sind rein zufällige, also echt zufällige Passwörter für Menschen gar nicht so einfach zu merken. Und deswegen neigen Menschen dazu, Passwörter zu nehmen, die sie sich leichter merken können. Zum Beispiel dieses Beispiel hier, das ist ja auch Troubadours, das ist ein englisches Wort, da hat man jetzt ein paar Zeichen ersetzt. Hat noch irgendwie ein Symbol hinten dran gehängt, aber diese Ersetzung, also zum Beispiel ein O durch eine Null zu ersetzen, das ist eine bekannte Ersetzung, das kann man berechnen, da kann man Modelle für bauen. Und auch so was wie angehängte Symbole ist, was relativ häufig ist, weil ein Nutzer der jetzt beispielsweise das Passwort haben möchte. Gibt das in seine Maske ein, die Maske sagt ihm halt du brauchst, aber ein Sonderzeichen, dann wird er sich das Passwort nicht komplett neu schreiben, sondern der hängt einfach ein Ausrufezeichen dran und hält sich für besonders schlau. Und tatsächlich lässt sich auch das, gibt es auch dafür Modelle, mit denen man eben diese Zeichenanhänge sich vormodellieren kann. Und da muss man gar nicht mehr alle Passwörter durchsuchen, sondern allein, also sowas ist gar nicht so schwer zu knacken. Selbst wenn wir jetzt so pseudo random Sachen haben, auch da neigen Menschen dazu, dass sie sich Passwörter viel, viel leichter merken können, die man zum Beispiel aussprechen kann. Also das habt ihr vielleicht schon mal gesehen, Passwortgenerator, der so eine Option hat, einfache Passwörter. Das sind Passwörter, die man einfach tatsächlich vorlesen kann, das sind keine echten Wörter. Und Menschen neigen dazu sowas zu nehmen, weil sie sich die leichter merken können. Das Problem an der Geschichte ist, wenn man die analysiert, stellt man fest, dass diese Passwörter ungefähr gleiche Buchstaben, Folgenhäufigkeiten haben, wie die natürliche Sprache des Urhebers. Wenn der Mensch, der jetzt gerade ein Passwort gemacht hat, Engländer ist und Englisch spricht, dann wird die Wahrscheinlichkeit, dass in dem Passwort auf ein T, ein R folgt, ungefähr so hoch sein, wie das in der englischen Sprache der Fall ist, plus Ersetzungen drumherum. Auch sowas kann ich tatsächlich nachmodellieren, gibt es einige Paper dazu, die das dann zum Beispiel mit Markovketten machen oder eben künstliche Intelligenz da drumherum. Und damit unglaubliche Speedups bekommen. Also auch das hilft nicht. Der Vorschlag hier von Wendel Monroe ist eben so etwas wie eine Passphrase zu verwenden. Die Idee ist, ich habe einfach ein längeres Passwort, ich habe mehr Stellen. Wenn ich da nochmal ein Buch aus drauf wäre, dann ist das relativ schwierig. Und da es halt unglaublich viele Wörter gibt, wo das nur vier einzelne Bestandteile sind, ist das immer noch ein relativ großer Schlüsselraum. Auch da muss man sagen, gibt es Einschränkungen. Weil man hat festgestellt, dass Menschen, die so Passphras verwenden, gerne grammatikalisch korrekte Passphras verwenden. Und damit habe ich natürlich wieder weniger Entropie. Damit ist das weniger Random. Und tatsächlich gibt es eine Analyse von 2012, die sagt, wenn Menschen das machen, dann haben so vier Wortpassphrase ungefähr 30-Bit Entropie. Das ist ungefähr das, was wir hier oben haben. Das ist also nicht so besonders sicher. Also der Fall hier mit Correct Horse Battery Staple, relativ sicher, aber sobald es grammatikalisch korrekt wird, sinkt die Sicherheit ganz immens. Warum kriegen Menschen das nicht auf die Reihe? Ich habe schon gesagt, es ist für Menschen schwer, sich wirkliche Random-Passwörter zu merken. Viele sagen dann, okay, der User ist schuld. Wir müssen den Leuten einfach nur ein tolles Dokument in die Hand drücken, wo dann drauf steht. So müsst ihr Passwörter generieren. Die müssen lang sein und möglichst Buchstaben und Zahlen enthalten und so weiter. Tatsächlich ist das nicht der Fall. Die meisten Leute wissen, wie man sichere Passwörter generiert. Aber es ist den Leuten zu anstrengend, sich diese Passwörter zu merken. Schlechtes Passwortmanagement ist nicht nur Ursache der Information, sondern Leute glauben einfach, ich werde da schon nicht von Betroffen sein. Und es ist furchtbar anstrengend, dass ich mir für jeden Dienst ein Passwort merken muss und Leute wollen aus irgendwelchen Gründen keine Passwortmanager verwenden. Genau, also stellen fest, Menschen sind so blöd für echte Random-Passwörter. Das ist auch völlig okay, gibt es Ansätze für, aber deswegen haben wir das Problem Bootforce und deswegen müssen wir damit umgehen. Das ist jetzt mal so ein Beispiel von so einer einfachen Webseite, da haben wir ein Log entfällt und der erste simple Ansatz, um eine Bootforce Protection zu machen, ist einfach die Idee, wenn ich mich entmal faltein logge, dann wird mein Account für eine bestimmte Zeit gesperrt. Gibt es dann so eine Fehlermeldung, wie sagt, dein Account wurde gesperrt, versuchst doch mal in fünf Minuten nochmal, machen erstaunlich viele Seiten. Hat nur ein Problem. Wenn wir jetzt mal genau hinschauen, stellen wir fest, ich kann natürlich nur Accounts sperren, die auch existieren. Sprich, wenn ich es schaffe, so eine Meldung zu bekommen, dann weiß ich, Alice ist auf jeden Fall ein echter Benutzer-Account, den Account gibt es. Und wenn ich jetzt auch weiß, wie viele Versuche ich brauche, um in diesen Log reinzukommen, dann kann ich unter Umständen relativ leicht, zumindest alle kurzen Benutzernamen, mir auflisten lassen. Dann weiß ich, welche Benutzern im System drin sind und es ist ein Problem, weil der zweite Problem, und das ist das viel größere, wenn ich weiß, dass es den Benutzer Alice gibt und ich weiß, ich brauche fünf Versuche, dann kann ich da einfach draufknallen und Alice kann sich nicht mehr einloggen. Das heißt, wir haben die Nile of Service, also eine Dienstblockade. Und das ist tatsächlich das Problem, um das es hauptsächlich gehen wird in dem Vortrag, weil erstaunlich viele Verfahren, die Mutforce Protection machen, genau dieses Problem haben. Das ist also, wenn dann überhaupt nur ein sehr, sehr simpler Ansatz, ein paar Seiten machen das besser. Der nächste Ansatz ist dann zu sagen, okay, wir machen quasi alles wie vorher, das heißt, wir sperren den Nutzer auch, wieder nach einer bestimmten Anzahl von Fehlversuchen, aber wir sagen dem das nicht, sondern geben einfach die Meldung aus und wenn ich jetzt einen Angreifer habe, der probiert Passwörter durch und er merkt gar nicht, dass er in der Mutforce Protection reinläuft. Das erste Problem ist vielleicht relativ offensichtlich, wenn ich das aus der Sichtweise vom Security Engineer mache, der denkt, ich will mich verteidigen und der Angreifer ist das, worum es gerade geht, mag das Sinn ergeben, aber wenn ich das nochmal User Sicht mache, ist das furchtbar nicht user friendly, weil die Leute, die sich wirklich einloggen wollen, die vielleicht ihr Passwort vergessen haben oder die gerade aktiv angegriffen werden, die wissen gar nicht, was los ist und dann wird beim Support das Telefon klingeln. Ist also tatsächlich gar nicht so eine gute Idee, das so zu machen, machen aber tatsächlich einige Access Management Lösungen so. Das zweite Problem ist, was ist denn, wenn ich ein Account in diesem System habe, weil dann kenne ich ja das Passwort zu dem Account und dann kann ich bewusst falsche Passwörter eingeben und dann gucken, ob ich mich beim echten Passwort einloggen kann und dann weiß ich, ob da eine Bootforce Protection drin ist oder nicht, sprich, ich habe trotzdem Information League, darüber, dass es eine Bootforce Protection gibt und wie lange ich es auch umprobieren muss. Und wenn ich dann einfach auf Accounts drauf haue, ich weiß, nach fünf Versuchen wird der Account gesperrt, ich weiß nicht, ob ich irgendwann ein gültiges Passwort kriege, aber wenn es mir nur darum geht, in der Firma richtig auf den Sack zu gehen, kann ich das weiterhin tun. Und die Geschichte mit, ja, aber ich muss doch wissen, was denn gültige Benutzernamen sind, na ja, in ganz vielen Fällen sind Benutzernamen halt E-Mail-Adressen und große Firmen haben nicht wirklich zufällige E-Mail-Adressen, die haben halt Vornamenpunktnachnahme at domain.tld und wenn ich weiß, wie die CTO heißt, dann kann ich ihren Account blockieren. Sad. Das heißt, auch die, auch Denial of Service ist in dem Fall leider möglich, ist also tatsächlich nicht wirklich ein guter Weg, Bootforce Protection zu machen, es ist einfach nur sehr verwirrend. Jetzt kann man weitergehen und sagen, okay, dann ist das einfach das Problem, dann machen wir jetzt IP-Based Bootforce Protection und sagen wir jetzt einfach, okay, wir sperren den Angreifer und nicht den User und wenn einfach, wenn wir sehen, von einer IP-Adresse kommen, total viele Loginversuche, dann sperren wir, wird die IP-Adresse Problem gelöst. Das ist leider in der Tat auch gar nicht so einfach, weil, was mache ich denn, wenn ich einen Angreifer habe, der unglaublich viele IP-Adressen zur Verfügung hat, weil der über große Proxilisten geht, weil der halt tatsächlich einfach überall auf der Welt irgendwelche Knoten betreibt, zum Beispiel Botnetze. Denn funktioniert die Variante gar nicht mal mehr so gut. Und die hat noch ein zweites Problem. Und das Problem ist Nutt. Nutt ist eigentlich immer ein Problem. Weil, wir kennen es alle, wenn man sich aus einem Wohnheim oder von der Uni oder von der Firma auf einer Seite einloggt, dann muss man erstmal ein Capture eingeben. Naja, wenn das eine große Firma ist und die schickt viele User durch eine IP-Adresse durch, dann kann das unter Umständen passieren, das Seiten sagen, Moment mal, das ist doch, da könnte doch ein Bootforce-Angriff passieren. Und die sperrt. Und wenn ich dann tatsächlich User wirklich sperre, dann habe ich ein Problem an der Stelle, weil alle Leute, die hinter dem Nutt sind, die kommen dann nicht mehr rein. Und damit kann ich auch tatsächlich bewussten Dinal-of-Service fahren, weil wenn ich irgendwem Kiege, den ich in die Firma reinkriege und ich kann aus dem IP-Netz agieren, oder das geht jetzt im Web-Bereich nicht so gut, aber was ist denn, wenn ich IP spoofing machen kann? Wenn ich gar nicht eine Antwort brauche, sondern einfach nur Pakete schicke und so tue, als wäre ich im Firmennetz. Dann habe ich das Ganze auch wieder blockiert und da einfach viele ISPs keinen Ingress-Filtering machen und das ist nicht vernünftig genug. Ist halt IP spoofing leider ein Problem und das hilft uns auch nicht wirklich viel weiter. Okay, okay, jetzt kann man sagen, das hat uns nicht wirklich geholfen. Dann, die Idee war, wir müssen einfach den Angreifer so weit verlangsamen, dass er das gar nicht schaffen kann. Fügen wir doch ein Delay ein. Sagen tatsächlich einige Ratgeber zu dem Thema, sagen einfach, die das Login verzögern. Jeder Login versucht, keine Ahnung, fünf Sekunden, dann kommt da so ein tolles Icon, die Leute denken, oh, das ist JavaScript und braucht deswegen länger und kein User wundert sich, total gute Idee und plötzlich braucht der User ewig. Das ist eine gute Idee, wenn mein Angreifer keine Ahnung hat, was Multifolding ist. Weil, sobald ich 1.000 Verbindung gleichzeitig aufmachen kann, dann bat ich halt fünf Sekunden, habe ich trotzdem 1.000 Ergebnisse und das kann ich skalieren. Das heißt, auch der Ansatz hilft uns nicht wirklich und wenn ich dann tatsächlich sage, okay, dann sage ich halt einfach, es darf nur eine Session gerade versuchen, sich einzulocken, dann habe ich wieder ein Denial of Service, also auch tatsächlich gar nichts. Jetzt gibt es noch ein paar andere Ideen, wie man das Thema angeht. Die sind aber auch nicht wirklich Ideen, die das lösen, sondern die das nur schwerer machen. Da gibt es aber ein paar ganz spannende dabei. Der erste Teil ist, habe ich mal unter Unpredictable Behavior zusammengefasst und zwar ist das die Idee, meine Angreifer haben ja ein Skript, was über meine Seite läuft und versucht rauszufinden, ob sie jetzt Erfolg hatten oder ob sie weiterprobieren müssen und eine Sache, über das die Angreifer das machen, ist halt, dass sie sich den Return Code anschauen. Wenn die Seite mir, wenn ich mich falsch eingelockt habe, ein Stadoscode 401 zurückliefert und wenn ich mich erfolgreich eingelockt habe, ein Stadoscode 200, dann ist es voll gut, weil dann mache ich das einfach so lange, bis ich 200 zurückbekomme und dann weiß ich, ich habe das Passwort. Und wenn ich jetzt mal anfange, einfach random mal eine 200 mitzuschicken, obwohl man sich nicht erfolgreich eingelockt hat, dann kann ich damit erstaunlich viele einfache Skripte dazu bringen, dass sie einfach nicht weiter suchen. Also das ist tatsächlich eine in der Praxis gar nicht so uneffektive Variante. Das gleiche ist, was passiert, wenn ich verschiedene Fehlermeldungen rausgebe und die Skripte denken halt, okay, da kommt invalid username or password und ich gebe plötzlich andere Sachen zurück und die Skripte brechen ab, weil sie denken, jetzt haben sie es gefunden. Ist tatsächlich eine ganz spannende Geschichte, funktioniert relativ gut, funktioniert, aber auch nur für sehr, sehr einfache Angreifer, wenn da jemand sich mit Aufwand hinterklemmt und eure Firma oder eure Institution oder Organisation irgendwie den Betrieb stilllegen wird, dann wird euch das nicht lange helfen. Tatsächlich, was ich eine ganz spannende Geschichte finde, wo ich in der Recherche oder aufgestoßen bin, das haben vielleicht ein paar von euch schon mal erlebt. Ihr lockt euch irgendwo ein, kommt auf eine Willkommensseite, klickt einen Link und seid wieder auf einer Passworteingabe und denkt, okay, irgendwas ist mit der Session kaputt, ich lade mal neu, ich gehe weiter. Ich sehe so paar negende Gesichter, gibt tatsächlich Seiten, die machen das als Bootforce Protection. Die tun so, als ob man erfolgreich gewesen ist, damit die Skripte abbrechen und vielleicht habt ihr in dem Moment tatsächlich euer Passwort falsch eingegeben. Der Random hat zugeschlagen und der hat euch einen Schritt weiter gelassen und danach wieder nach dem Passwort gefragt. Fand ich ganz spannend, weil das hat für mich so ein Ah-Effekt, okay, tatsächlich tun Seiten das. Aber wie gesagt, auch in dem Fall, hilft halt nur gegen sehr einfachen Angreif haben. Die nächste Punkte fand ich auch ganz spannend. Einfach, wenn ich ein Skript habe, was einfach darauf reagiert, bekommt in dem Source Code, den die Seite zurückliefert, steht halt irgendwie als Fehlermeldung mit username auf Passwort drin. Wenn ich einfach bei einem erfolgreichen Login als Kommentar, in welcher username auf Passwort in den Source Code schreibe, kriegt der User das nicht mit, aber die Skripte laufen weiter. Also tatsächlich funktioniert auch, ist eine ganz witzige Variante. Kann man auf jeden Fall einfach mal machen, aber hilft halt bei einem wirklichen Angreifer auch nicht wirklich. Dann gibt es diesen Punkt, Secret Questions. Ich merke, okay, da wird gerade ein Bootforce gemacht. Dann frage ich halt nach dem Mädchennamen der Mutter, dem ersten Haustier, was auch immer, aber wir wissen alle, diese sicheren Fragen sind halt tatsächlich gar nicht so sicher. Ist also auch eigentlich kein wirklicher Sicherheitsmehrwert. Und dann gibt es den Punkt, auf den wahrscheinlich viele schon gewartet haben, das sind Captures. Und Captures sind tatsächlich ein relativ effektiver Weg. Das sind diese kleinen, lustigen Bildchen oder Buchstabenrätsel, wo man einfach einen bestimmten String eingeben will, der ganz stark verstört ist und dementsprechend für ein Computer schwer zu lesen ist, aber für Menschen relativ leicht. Das kann man machen. Tatsächlich ist das eine relativ effektive Lösung. Man kann sich zwar gelöste Captures kaufen, die sind auch gar nicht so teuer, aber der Angeifer, der jetzt nicht mit viel Budget auf euch drauf haut, der wird an Captures sich schon so ein bisschen die Zähne ausbeißen. Gibt aber auch Gründe, warum man Captures vielleicht nicht einsetzen will. Ein Punkt ist Barrierefreiheit, weil tatsächlich relativ viele Capturesysteme eben optisch sind. Also irgendwie mit Text- oder Bildern arbeiten und Menschen mit einer Seebehinderung da halt nicht so gut mit klar kommen. Gibt dann zwar auch so Sachen wie irgendwie, da kannst du dir noch was anhören, was du dann eintippst, auch das dann halt teilweise gar nicht mal so einfach. Vielleicht will man auch seinen User gar nicht, seinen User gar nicht die Daten abgreifen und dann zum Beispiel Google schicken für Recapture, weil man sagt, okay, Datenschutz ist mir doch wichtig und vielleicht will ich meine User auch nicht als unbezahlter Arbeiter irgendein Machine Learning trainieren lassen, von dem eine gewinnorientierte Firma nachher profitiert. Vielleicht agiere ich aber tatsächlich auch einfach in einem Land, wo Google gesperrt ist und ich kann Google Capture gar nicht nutzen oder ich agiere in dem Land, weil meine User irgendwo in Nepal auf einem Berggipfel sitzen und bei denen braucht eine Seite halt mal 5 Minuten zum Laden und wenn ich dann nochmal so ein Capture davor mache, wo Bilder nachgeladen werden müssen, sind das halt 5 Minuten mehr. Gibt schon Gründe, warum man Captures nicht einsetzen will. Deswegen habe ich die hier nicht so ganz im Fokus. Wenn man aber sagt, ist für mich total fein, sind Captures auch gar keine so schlechte Methode. Fangen wir mal zusammen. Was wir machen wollen, ist Brutforce Protection und möglichst ohne Denial of Service. Und was wir dafür tun müssen, ist Angreifer blockieren und User nicht. Das ist jetzt soweit klar, fragt euch jetzt, was soll die Folie? Tatsächlich gibt es eine Variante, die geht genau diesen Weg. Und das ist die Brutforce Protection mit Device Cookies. Das ist ein Verfahren vom Open Web Application Security Project, OWASP. Da unten ist auch der Link, findet man tatsächlich auch einfach, wenn man nach OWASP Device Cookies sucht. Da hinter ist eben eine Unterscheidung zu treffen zwischen echten Usern und Angreifern. Und wie kann ich das machen? Naja, echte User haben sich mindestens einmal erfolgreich eingelockt. Und wenn sie sich erfolgreich eingelockt haben, irgendwie ein kleines Tokengeber, mit denen sie beweisen können, dass sie das schon mal gemacht haben, dann kann ich sie anders behandeln als einen Angreifer, der das eben noch nicht geschafft hat. Weil, wenn der sich schon mal erfolgreich eingelockt hat, dann braucht der kein Brutforce mehr fahren. Und dann kann ich eben nicht nur die fehlgeschlagenen Loginversuche allgemein zählen, sondern ich kann auch pro Device Cookie zählen. Das funktioniert tatsächlich im Detail einfach so. Wenn eine Anfrage kommt, die jemand möchte sich einloggen, gucke ich erstmal, hat er denn ein gültiges Device Cookie. Wenn er das nicht hat, dann gucke ich, ob die Authentifizierung gerade gesperrt oder eingeschränkt ist, weil zum Beispiel ein Brutforce läuft. Und wenn das der Fall ist, dann wird er einfach abgewiesen. Wenn das nicht der Fall ist, dann checke ich die Credentials und wenn es geklappt hat, dann kriegt er ein Device Cookie. Und wenn es nicht geklappt hat, dann zähle ich halt eben wie bei allen anderen Verfahren, globalen Counter hoch und wenn der überschritten ist, dann wird eben genau dieser Schritt hier oben, dann wird eben die Authentifizierung eingeschränkt und dann kann der Angreifer nicht mehr weiter agieren. Da muss er eben seine 10 Minuten warten. Der User, der sich aber mal erfolgreich eingelockt hat, der hat jetzt ein Device Cookie und wenn das Device Cookie nicht gerade auch gesperrt ist, dann kann er einfach diesen Schritt umgehen und sich trotzdem einloggen. Jetzt kann es natürlich passieren, dass ein Angreifer irgendwie ein Handy klaut und dann eben die Device Cookie hat und für den Fall, dass das Device Cookie halt auch zu viele vergeschlagenen Loggingversuche macht, dann wird da auch ein Counter hochgezählt, dann wird das Device Cookie gesperrt. Der Vorteil ist aber tatsächlich, im Normalfall ist es gar nicht so einfach jemandem Handy zu klauen, wie einfach auf eine Seite drauf zu hauen mit einem Skript. Und dann ist es egal, wie doll ich auf die Seite drauf haue, Leute können sich und zwar mit jedem Gerät, also wenn man mir das Handy geklaut hat, dann kann ich mich einloggen, weil da ist ein anderes Device Cookie drauf, kann ich mich noch einloggen, weil der echt User braucht gar nicht so viel Versuche für seinen Passwort, der Angreifer schon. Und wenn wir jetzt mal so ein fiktives Beispiel nehmen, ich habe 10 Versuche und danach wird der Account für eine Stunde gesperrt, dann weiß ich, ich habe der Tag hat 24 Stunden, ich kann also 240 Versuche pro Tag machen, das ist nicht viel, da komme ich nicht weit mit einem Bootforce. Und selbst wenn ich mir jetzt ein Device Cookie klaue, habe ich nur weitere 240 Versuche. Also es ist auch für einen Angreifer gar nicht so attraktiv, sich diese Device Cookies zu klauen, weil es bringt ihnen gar nicht so viel weiter. Und nur um jemanden tatsächlich auszusperren, ist das ein ganz schöner Aufwand. Ist also tatsächlich ein ganz schickes Verfahren dafür, was auch relativ gut geeignet ist. Ist gerade dabei adaptiert zu werden, also ich weiß nicht, wer von euch Keyclaw kennt, das ist so ein Access Management Projekt, das wird von Red Hat entwickelt und relativ großes Open Source Projekt, zum Endeffekt ein Gateway, was euch ermöglicht irgendwie Anwendung mit Open ID Connect oder Sammel oder OAuth anzubinden. Und die haben das schon auf dem Schirm, die wollen das einsetzen, weil die machen nämlich im Moment den Fall, dass sie einfach immer sagen, in welches User Name auch pass wird, auch wenn die Bootforce Protection zugeschlagen hat und es furchtbar verwirrend, deswegen will man das vielleicht gar nicht so einsetzen, aber die haben das auf dem Schirm, die wollen das umsetzen. Und wenn ihr jetzt auch denkt, voll gut, das nehme ich, dann ist der Talk für euch hier zu Ende. Aber man hat ja doch immer wieder mal ein Fall, wo man sagt, ich möchte jetzt keine eigene Bootforce Protection reinhackern oder das geht bei meinem Tool nicht oder oder oder. Und dann gibt es noch ein paar Alternativen, die man einfach der Vollständigkeit halber hier aufgeführt haben sollte. Aber ich sage Alternativen in Anführungszeichen, weil die lösen das Problem an sich nicht, die versuchen nur, einen erfolgreichen Angriff zu mitigieren. Was ich dann meine, gleich ein Beispiel 2-Faktor-Otentifizierung, das ist eben die Idee, dass ich halt ein User Name und Passwort brauche und dann brauche ich halt noch irgendeine Art von Token. Das ist zum Beispiel diese Authenticator App, das ist TOTP, da kriege ich dann so eine sechsstellige Nummer. Das kann aber auch eine Bestätigungs-SMS sein, die ich bekomme. Und die habe ich, die brauche ich als 2-Faktor. Das heißt, ich habe nicht nur das, ich muss etwas wissen, also das geheime Passwort, sondern ich muss auch etwas haben, nämlich eben ein Gerät, wo ich diesen Kryptoschlüssel drauf habe oder wohin ich eben eine SMS bekommen kann. Ist auf jeden Fall eine gute Idee. Das Problem an der Geschichte ist, dass die allermeisten Seiten, das halt so implementiert haben, dass man erst Benutzernahme und Passwort eingibt. Und wenn man damit erfolgreich war, dann muss man seinen 2-Faktor eingeben. Das heißt, wenn ich ein Blutforst darauf fahre, dann komme ich zwar nicht in den Account, aber kann trotzdem Benutzernahme und Passwort rausfinden. Und da relativ viele Leute ihre Passwörter weiter verwenden und eben nicht ein Passwort pro Dienst haben, hilft mir das in manchen Punkten gar nicht so viel weiter. Und außerdem versucht das halt eben, das Problem anzugehen, dass Menschen zu dumm sind für Random Passwörter, wie eingangs erwähnt und sagt einfach, okay, ich weiß etwas, ist nicht stark genug, das heißt, ich brauche irgendwie noch das, ich habe etwas. Was das ein bisschen besser macht, ist Web-Auf-N oder die Web-Authentication-RP. Das ist relativ junge Entwicklung, wird auch immer mehr integriert. Das ist ein Projekt vom Web-Konsortium und von der Flu-Allianz. Und die Idee dahinter ist, dass die einfach gesagt haben, okay, Menschen sind zu blöd für das, ich weiß etwas, und wir nehmen nur noch, dass ich habe etwas. Die Idee ist quasi, ich habe so ein Kleint, der möchte sich einloggen, dann sagt der Server, ja, hier ist irgendein Nonz, signier mir die mal bitte, also kryptografisch, nicht händisch. Und ich stecke dann zum Beispiel so ein Ubiqui in meinen Rechner, drücke auf den Knopf, die Signatur passiert, und der Dienst sagt cool, alles klar, die Signatur kenne ich, du darfst rein. Ich brauche kein Passwort mehr, ich brauche nur noch ein Token. Das kann zum Beispiel aber auch ein TPM sein, was ich im Rechner habe, da muss ich dann ein kleines Passwort eingeben oder meinen Fingerabdruck draufhalten für Fans von Biometrie. Und dann bin ich drin und brauche nur, dass ich habe etwas, da muss man keine Passwörter merken. Ist tatsächlich mittlerweile in allen großen Browsern zumindest grundlegend unterstützt, und jetzt braucht es halt Dienste, die das auch noch nutzen. Aber auch da kommt immer mehr auf den Weg, ich glaube, da wird die Zukunft hingehen so ein bisschen. Damit sind wir auch quasi schon am Ende. Das ist auch ganz schön, weil vielleicht habt ihr ein paar Fragen. Zuerst aber noch das, was ich hoffe, dass Sie aus dem Vortrag mitnehmen. Das große Bootforce Protection ist nicht einfach, oder bietet euch halt bestimmte Nachteile. Und wenn ihr zu den Leuten gehört, die Anwendungen entwickeln, dann bitte ich euch, habt das im Hinterkopf. Es ist nicht so einfach, wie ein Account nach N-Versuchen zu sperren. Und wenn ihr die Möglichkeit habt, euren Usern zu ermöglichen, einen zweiten Faktor zu verwenden, tut das einfach, das ist nicht verkehrt. Das hilft Ihnen zumindest, dass der Account bei euch sicher ist. Und wenn ihr zu den Leuten gehört, die Systeme benutzen, und es tut ihr tatsächlich alle, dann benutzt eben einen zweiten Faktor, wo immer ihr das könnt. Und wenn ihr das nicht könnt, seid faul benutzt ein Passwortmanager, weil da könnt ihr echte Random Passwörter reinpacken, die ihr euch nicht merken könnt, die lang sind, und vor allen Dingen für jeden Dienst ein eigenes. Und wenn ihr einen guten Passwortmanager habt, dann sagt ihr euch auch, wo ihr noch einen zweiten Faktor oben draufpacken könnt. Und dann seid ihr nochmal besser abgesichert. Und hoffentlich haben wir dieses Problem mit Passwort in der Zukunft dann irgendwann nicht mehr, wenn Web Aufenden oder Ähnliches sich da mal durchgesetzt hat. Und solange wisst ihr jetzt zumindest mal, wie ihr Bootforce Angriffen begegnen könnt. Damit wäre ich soweit durch. Wenn ihr Fragen habt, könnt ihr sie jetzt stellen. Ja, du hast jetzt gerade davon gesprochen, dass es ja die Möglichkeit gibt, einen Cookie zu setzen für jemanden, der sich schon mal richtig eingeloggt hat. Warum nutzt man dafür nicht einfach die Two Factor Authentification? Also, dass man sagt nach jedem Log-Inversuch, hey, gib mir doch mal den Two Factor für diesen Account. Und dass man daran verknüpft, dass der User nochmal probieren darf, sich einzuloggen. Also, dass man sagt, hey, dein Two Factor hat funktioniert. Dein Passwort war aber falsch. Probier es doch nochmal. Versus, hey, der Two Factor war auch falsch. Mach dich ab. Probier es in 10 Minuten nochmal. Ist eine gute Frage. Tatsächlich gibt es ja einige Systeme, die gar nicht aus so was wie TOTP setzen, sondern die SMS verschicken. Und das kostet Geld. Die wollen das gar nicht so oft machen müssen. Ein zweiter Punkt ist, es machen noch gar nicht so arg viele Leute Two Factor. Es gab dann eine Studie von Duo. Die hat zwar keinen so großen Stichprobeumfang, aber die haben halt versucht, zumindest mal ein für die USA repräsentatives demografisches Abbild zu bekommen. Und die hat ergeben, dass ungefähr 28 Prozent der Leute überhaupt Two Factor Authentification benutzen. Und davon auch nur, also immerhin von den Leuten 58 Prozent das freiwillig getan haben, der Rest wurde dazu gezwungen. Tatsächlich sind die Leute diesmal verwendet haben. Also wenn das jetzt so Sachen sind, wie eben eine Bestätigungs-SMS oder ein Hardware-Key, den ich einfach nur reinstecken muss und drauf drücken muss, sagen tatsächlich relativ viele Leute, das ist cool, das ist brauchbar, das nimmt mir Arbeit ab. Aber ich glaube, viele Leute werden sagen, oh, das ist total nervig, wenn ich jetzt bei jedem Login nochmal mein Handy rauskamen muss, jetzt habe ich mich wieder vertippt. Jetzt ist der Schlüssel wieder rotiert. Jetzt muss ich wieder eine neue Passphase eingeben oder auf die SMS warten. Ich kann mir vorstellen, dass das Gründe sind, warum man den zweiten Faktor nicht bei jedem Login versucht, also für jeden Fehlversuch nochmal neu abfragt. Weitere Fragen? Ja, macht es denn überhaupt Sinn, nur noch Tokens oder TOTP mit dem WebWorth End zu benutzen und dann im Prinzip sich den zweiten Faktor wegzunehmen? Weil ich habe ja dann, also in dem Moment, soweit ich das jetzt verstanden habe von den WebWorth End Leuten, die wollen im Prinzip, dass das Passwort weg ist, was ja grundsätzlich erstmal nicht schlecht ist, aber im Prinzip benutze ich jetzt die Sachen, die vorher den zweiten Faktor gebildet haben für den Ersatz des Passwords. Also im Prinzip fällt ja da was weg und wenn ich jetzt angucke, wofür es eigentlich am wichtigsten, also gerade so corporate environment, wo Leute sich Passwörter auf Zettel schreiben und an den Monitor kleben, die sind garantiert auch nicht bewusst am Umgang mit ihrem Schlüssel. Also wenn ich jetzt am Schlüsselring den Token habe oder das Handy, was nicht gesperrt und keinen Pinnen und nix, wo ist denn da die, die tatsächlich der Mehrwert von so einem WebWorth End? Also aus Fokus von dem Talk ist es natürlich der Mehrwert, dass ich erstmal irgendwo reinkommen muss und mir das Passwort am Monitor anschauen können muss oder mir eben, ich brauche einen physischen Zugang zu dem Gerät. Klar ist es fraglich, wie gut User damit umgehen, aber wenn es mir wirklich darum geht, dass sich nur ein Angreifer, der irgendwo im Netz sitzt und nur meine Seite hat, abzuwehren, dann ist das eigentlich gar nicht schlecht, weil die Krypto, die ja in den Token ist, die hat halt quasi so lange Schlüssel, das kann ich nicht durchprobieren. Also den Use Case, für den Use Case ist das glaube ich schon ziemlich geschickte Sache und dann glaube ich halt auch einfach, das habe ich ja bei zwei Faktoren gesagt, dass zwei Faktoren an vielen Stellen besucht, den Weg zu gehen zu sagen, dieser erste Faktor, der ist einfach nicht sicher genug, wir packen da einen zweiten oben drauf und wir vergessen einfach, dass der erste ausreicht und dann finde ich, ist Web auf N eigentlich nur das Konzept weiter gedacht zu sagen, okay, wenn wir eh wissen, dass der erste Faktor nicht ausreicht, dann lassen wir den einfach weg. Wie viel, also wie gut Leute in der Praxis damit umgehen, ist fraglich, aber tatsächlich haben die Leute ja auch gelernt, auf ihren Schlüsselbund aufzupassen, weil da ja Hauszuschlüssel drauf ist. Klar, jemand, der wirklich auf eine Person anlegt, den wird man damit nicht aufhalten können, aber tatsächlich ein Angreifer, der einfach nur in den Moundsitz ein bisschen Schaden anrichten will, denke ich mal schon. Ich habe ja mal irgendwann gelernt, Cookies sind böse aus Privacy Gründen, deshalb wirft man Browser, die immer wieder weg, sobald ich den Browser gelöst habe, dann hilft mir das doch auch nicht weiter, oder? Das ist korrekt. Ganz einfach, ja klar, das ist natürlich korrekt, also wenn du die Daten einfach löscht und keine Ahnung, wenn du Tales verwendest und jedes Mal dein System frisch putest, dann funktioniert das natürlich nicht, aber du kannst dich ja trotzdem einloggen, du hast halt einfach diesen Mehrwert nicht, aber zwar hat wie so viele Dinge, wenn du dich auf bestimmte Sachen nicht einlässt, dann hast du halt bestimmte Komfortfeatures auch nicht. Zu dem reinen Webortend, wir haben ja nur alle gelernt, dass unsere EC-Karte alleine eine schlechte Idee ist, haben wir diese Pins ja, und darauf läuft es ja hinaus, auf Token rumläufe, und wenn wir da geklaut, würde ich überall auf Zugriff, auf Online-Banking und alles. Das heißt, das reine, weglassenes Passwort ist vielleicht für die Dienste interessant, wo ich nicht persönlich getarget bin. Also, irgendwie der Twitter-Account oder sowas, da wird wohl kaum jemand von uns persönliches Target sein. Aber die wertvollen Dienste sollte man, glaube ich, schon noch das Passwort beibehalten, dann halt als zweites Faktor das Passwort. Da muss man über das Angreifermodell nachdenken und über das Thread-Modelling, was ist interessant, was ist denn so schützenswert, dass ich da zwei Faktoren dafür brauche. Das Schöne ist, dass die Kryptokies auch die Möglichkeit bieten, dass sie nicht nur so einfach sind, dass du auf den Knopf drückst, sondern dass du zum Beispiel eine Pin eingeben musst und das Ding nach drei Fehlversuchen halt einfach hart gesperrt wird und du eben eine längere Pin brauchst, um das zurückzusetzen. Also, das bleibt natürlich die selber zu überlassen und überhaupt verbreitet und wie es überhaupt akzeptiert wird. Aber allein die Möglichkeit zu haben, dass es das gibt und überhaupt die Möglichkeit zum Beispiel zu haben, dass ich mehrere zweite Faktoren habe, ich kann ja mehrere Kies haben und wenn ich dann einen verliere, dann nehme ich einfach einen anderen und sperre den Kie. Das haben ja heute einfach viele Seiten, die zwei Faktoren machen noch gar nicht. Du kannst halt genau einmal zwei Faktoren konfigurieren und wenn du dann dein Handy verlierst, hast du ein Problem. Ich sehe keine weiteren Fragen. Wir sind auch zeitlich, glaube ich, am Ende. Wenn euch noch Fragen einfallen, nehmt euch einen Chunk und geht mich auf der Wiese suchen oder schreibt mich irgendwie im Internet an. Okay, danke schön.