Passwörter

Hallo und herzlich Willkommen zum INNOQ Security Podcast Folge 10! Heute bei mir zu Gast ist Christoph Iserlohn und wir wollen zusammen über Passwörter reden. Mein Name ist Lisa Maria Moritz. Hallo Christoph!

Christoph Iserlohn:

Hallo Lisa!

Lisa Maria Moritz:

Was ich mich ja frage: Braucht man heutzutage überhaupt noch Passwörter? Ich meine, wenn ich auf mein IPhone schaue, dann entsperrt sich das mit meinem Gesicht. Wenn ich meinen Laptop entsperren möchte, dann presse ich meinen Finger da drauf und alles ist gut. Warum muss ich mir dann überhaupt noch Passwörter ausdenken?

Christoph Iserlohn:

Ja, da hast du nicht ganz Unrecht. Passwörtern wird schon lange ein glorreiches Ende vorausgesagt, schon so seit 10–15 Jahren. Das Problem ist, das hat sich noch nicht so bewahrheitet. Und das hat verschiedene Gründe. Die Beispiele, die du jetzt gerade genannt hast, wie du deinen Computer entsperrst oder vielleicht dein Telefon entsperrst, da kann man vielleicht auf Passwörter verzichten an der Stelle. Aber wenn wir uns jetzt mal vorstellen wir haben jetzt irgendeinen Webdienst, bei dem wir uns anmelden wollen, dann kannst du da schwerlich deine biometrischen Daten nehmen, weil die sind A auf den Geräten, die du hast, gespeichert. Hoffe ich jedenfalls, dass sie das Gerät nicht verlassen. Und deshalb kannst du die dafür nicht unbedingt so gut nutzen. Und auch wenn du das nutzen könntest, hast du jetzt gerade auch gesagt, bei dem einen kannst du den Fingerabdruck nehmen und das andere entsperrt sich aber mit deinem Gesicht, das heißt du müsstest da schon ganz verschiedene Daten hinterlegen in diesem Webdienst. Deshalb ist an so einer Stelle natürlich ein Passwort viel einfacher.

Lisa Maria Moritz:

Gibt es denn neben den Dingen, die ich gerade genannt habe, noch andere Dinge die man als Passwort verwenden könnte, die mir gerade noch entgangen sind?

Christoph Iserlohn:

Ja, es gibt noch andere Verfahren, also das ist dieses sogenannte Password-less Login. Eine Möglichkeit ist, dass wenn man sich anmelden will, man immer einen Link zugeschickt bekommt und dann einfach auf den Link klickt. Also es wird halt davon ausgegangen, dass man dann im Besitz dieser E-Mail-Adresse, die hinterlegt ist, ist und den Link, den man dann bekommt, kann man einfach anklicken. Dann bräuchte ich mir kein schwieriges Passwort merken, dann muss ich halt mein E-Mail-Postfach ganz gut beschützen. Aber das funktioniert auch nur bedingt. Also wenn ich mich zum Beispiel auf meinem Smart TV anmelden will, dann kann ich da keinen Link hinschicken, sondern den kann ich vielleicht auf meinen Rechner schicken und wahrscheinlich auf mein Mobiltelefon, aber nicht auf meine Spielekonsole oder auf meinen Fernseher oder auf mein IoT-Gerät, das vielleicht auch einen Internetzugang in irgendeiner Form hat. Da ist wieder, das Passwort ist einfach total universell. Das kann ich mir merken und es gibt an den meisten Geräten irgendeine Eingabemöglichkeit. Mal komfortabel, manchmal weniger komfortabler, aber es geht irgendwie.

Lisa Maria Moritz:

Da sagst du gerade schon, das Passwort ist irgendwie einfacher. Weil das kann ich mir merken, aber wenn ich jetzt natürlich den Namen meines Hundes oder meines Wellensittichs irgendwie als Passwort verwende und vielleicht noch ein Ausrufezeichen oder eine Zahl dahinter schreibe, ist es ja vermutlich nicht so gut. Also was gibt es so für typische Probleme mit Passwörtern aus Nutzersicht?

Christoph Iserlohn:

Aus Nutzersicht haben Passwörter meistens zwei Eigenschaften, die so gegensätzlich sind. Also ich kann es mir gut merken, dann ist es aber von der Sicherheit schlecht oder es ist von der Sicherheit gut und ich kann es mir nur schlecht merken. Das ist ein Problem, das kann man zum Teil beheben. Ich würde dann aus Endnutzersicht natürlich immer empfehlen Passwortmanager zu nutzen. Da brauche ich zu einem nur ein Passwort für alle meine Dienste, weil ich will ja bei den ganzen Diensten, die ich im Internet benutze, auch immer ein anderes Passwort haben, damit falls mal bei dem Dienst ein Passwort verloren geht, das nicht für andere Dienste, die ich auch benutze, genutzt werden kann. Da kommen wir gleich vielleicht nochmal zu, bei den Angriffen, die so möglich sind. Das heißt ich habe eigentlich im echten Leben ganz viele Passwörter. Und die will ich mir nicht alle merken, deswegen habe ich einen Passwortmanager, da kann ich das mit einem guten Passwort schützen. Und wenn ich mir nur eins merken muss, ist das natürlich auch ein bisschen leichter. Andererseits kann der Passwortmanager mir sehr gute Passwörter erzeugen, also die sehr lang sind, sehr zufällig sind, die dann insgesamt eine guten Sicherheitsgrad haben. Das funktioniert aber auch nur zum Teil. Das funktioniert ganz gut, wie gesagt, auch für den Computer und dein Handy, weil viele kommerzielle Anbieter jedenfalls können sich da ganz gut synchronisieren, auch auf verschiedenen Geräten. Aber diese anderen Geräte, also so Nischen-Geräte nenne ich die jetzt mal, wie gesagt die Spielkonsole und Co, oder auch mein Fernseher, die können sich meistens nicht synchronisieren. Und dann muss ich gerade bei denen, vielleicht über so eine komische Fernseher-Fernbedienung, die keine richtige Tastatur hat, auch noch ein ultrakomplexes Passwort eingeben. Das ist relativ problematisch an der Stelle. Anderseits sind viele Dienste wahrscheinlich auch nicht für den Fernseher geeignet. Also meinen Smart TV nehme ich vielleicht, um YouTube zu schauen und sowas und brauche da auch gar nicht so viele Passwörter, deshalb ist ein Passwortmanager immer noch dafür die beste Lösung.

Lisa Maria Moritz:

Ich habe ja mal gehört, dass es irgendwie besonders sicher ist, wenn man vier total verschiedene Worte einfach aneinanderreiht. Was weiß ich: Lichtreflex, Lippenstift, Bleistiftspitzer und Lampe oder sowas. Und dann ist das ein besonders sicheres Passwort. Das wäre jetzt auch etwas, was ich am Smart TV gut eingeben könnte. Ist das wirklich so sicher? Oder würdest du das empfehlen oder auch nicht?

Christoph Iserlohn:

Ja, also da gab es ja mal einen berühmten xkcd Comic zu, den battery horse staple. Das ist sicher, weil mit so einem langen Passwort… Das wird ja dadurch sehr lang, wenn ich irgendwie vier oder fünf oder sechs Worte nehme, also so einen Passphrase nennt man das dann, die haben halt… Das wird sehr lang, das kann ich halt nicht so leicht brute-forcen, das hat einen hohen Entropiegrad. Andererseits, wenn ich so reale Worte nehme, kann ich mir halt irgendwie ein Gedankenbild machen, um mir das leicht zu merken. Also das vereinigt sozusagen die beiden guten Eigenschaften. Das ist gut zu merken und das ist auch relativ sicher. Manchmal gibt es Probleme mit der UX von Seiten der Dienste, wo ich das eingeben will. Zum Beispiel sind Leerzeichen oft nicht erlaubt in Passwörtern, völlig unverständlicherweise. Dann muss ich mir halt überlegen, setz ich die jetzt alle aneinander? Mache ich da jetzt einen Bindestrich zwischen oder einen Unterstrich? Weil der Dienst zum Beispiel dann eine Passwort-Policy hat, ich brauche auch ein Sonderzeichen dazwischen, dann kann ich halt normale Worte mit nur Buchstaben halt auch nicht zusammensetzen. Muss ich dann irgendwie noch eine Ziffer eingeben und so? Dann werden die auf einmal doch wieder viel schwieriger zu merken. Das liegt aber eher daran, dass die Passwort-Policy in dem Fall einfach schlecht ist, weil die überprüft nicht die Entropie des Passworts, sondern so ein paar formale Kriterien, die dann auch gute Passwörter einfach ausschließt.

Lisa Maria Moritz:

Denkst du also es ist nicht so sinnvoll irgendwelche Kriterien auf ein Passwort zu legen, wie irgendwie: Es muss auf jeden Fall eine Raute mit drin sein oder sowas. Stattdessen sollte der Nutzer besser entscheiden, was sein Passwort ist. Oder sollte man schon irgendwelche, ich weiß nicht, Rahmenbedingungen für Passwörter auf Seiten mitgeben?

Christoph Iserlohn:

Das ist sehr schwierig. Eigentlich würde ich gerne sagen: Wenn ich eine Passwort-Policy aufstelle, ich lass nur gute Passwörter zu. Das ist ja der Sinn dieser Passwort-Policy und deswegen sagen die: Gute Passwörter enthalten zum Beispiel Sonderzeichen und Zahlen und Groß- und Kleinbuchstaben, damit die Entropie erhöht wird. An dem Beispiel vorhin haben wir gesehen, das schließt dann aber zum Beispiel so eine Passphrase aus, die vielleicht sehr lang ist und dadurch auch eine hohe Entropie hat. Deshalb ist das problematisch. Dann gibt es halt viele Kriterien, wo man so denkt, man erzeugt dadurch ein gutes Passwort. Ein Beispiel dazu ist: Man soll nicht den Namen des Dienstes verwenden in dem Passwort. Irgendwie nicht PayPal123. Dann wird das einfach weggelassen… nicht erlaubt. Ich könnte aber, ich habe… PayPal ist jetzt nur ein Beispiel, da gibt es jetzt ganz viele Dienste, bei denen das so ist. Ich kann PayPal123 eingeben und dann irgendwie 56 zufällige Zeichen und dann geht das halt trotzdem nicht durch. Auch wenn dieses Wort dann da drin ist, wie der Dienst heißt, wäre dieses Passwort trotzdem extrem sicher gewesen. Das wird nicht durchgesetzt. Deshalb, die Idee für so ein, man nennt das auch Password-strength indicator, wenn einen das so angezeigt wird, die finde ich ganz gut. Ich habe nur noch keinen guten in der Praxis gesehen. Weil das Ziel, nur gute Passwörter zu erlauben, das schaffen die halt nicht immer und gleichzeitig die schlechten Passwörter zu verhindern, also das sozusagen umgedreht zu sehen, das schaffen sie dann auch nicht. Von daher würde ich sogar fast dazu tendieren die wegzulassen und lieber andere Sicherheitsmechanismen wie Have I Been Pwned einzusetzen, können wir gleich nochmal draufkommen, was sich dahinter verbirgt.

Lisa Maria Moritz:

Jetzt hast du schon über die UX von Passworteingabefeldern gesprochen. Ich musste gerade auch an diese kleinen Balken denken, die sich füllen von rot nach gelb nach grün, dann Passwort ist sehr sicher, weil ich viele Zahlen habe oder so. Oder viele Zeichen besser gesagt. Was muss man denn beim Erstellen eines Passwortfeldes in der UX beachten, dass zum Beispiel auch Passwortmanager damit kompatibel sind?

Christoph Iserlohn:

Ja, also bei diesen Feldern der Passworteingabe gibt es zwei Sachen zu beachten. Das eine ist, wie du gerade angedeutet hast, für einen Passwortmanager, das andere ist aber die normale UX. Diese Balken zeigen dann sozusagen die Stärke an, wenn man keine Einschränkungen hat. Wenn man jetzt aber vielleicht so eine Policy hat, vielleicht ist man regulatorisch dazu gezwungen, eine Policy zu nehmen, dann ist es zum Beispiel auch gut, die Policy anzuzeigen. Also schlechtes Beispiel: Ich gebe ein Passwort ein und gehe dann auf… Also ich erstelle einen Account, gebe dann Usernamen, Passwort ein und dann nächste Seite: Passwort entspricht nicht den Policies. Da weiß ich aber nicht, ja was fehlt denn jetzt? Muss ich jetzt ein Sonderzeichen eingeben oder einen Großbuchstaben oder Ziffer? Manchmal steht dann nur die Policy, dann weiß ich aber vielleicht nicht genau, was stimmte denn jetzt nicht an der Policy, wenn die komplex ist. Das kann man zum Beispiel sagen… oder die Policy so gestalten, dass der in Echtzeit überprüft. Da stehen dann die Kriterien neben dem Passwortfeld, irgendwie Großbuchstabe, Kleinbuchstabe, Sonderzeichen. Und immer, wenn man eins eingegeben hat, wird das sozusagen ausgeblendet. Dann weiß man: Diese Policy ist erfüllt. Oder wenn, das geht dann nur mit JavaScript, wenn ich sozusagen im Browser überprüfe und wenn ich das halt auf der Serverseite mache, kann ich auch sagen: Folgende Regeln sind nicht erfüllt. Das ist natürlich für den Nutzer viel besser, anstatt einfach zu sagen: Entspricht nicht der Policy. Das andere, worauf die Frage ja eigentlich gezielt hatte, ist, das für den Passwortmanager zu gestalten. Da ist halt wichtig, dass er diese Autofill-Funktion, die die meisten Passwortmanager haben, ganz gut unterstützt. Dazu muss ich zum Beispiel darauf achten, dass die Felder für das Passwort auch immer gleich heißen bei den Seiten, damit der Passwortmanager erkennen kann: Aha, an der und der Domain und da habe ich die gleichen Formularfelder, da kann ich das Passwort einfüllen. Oder wenn ich zum Beispiel, was heute öfter gemacht wird, auf der ersten Seite gebe ich meinen Usernamen ein und auf der zweiten Seite gebe ich dann das Passwort ein, dass ich so ein hidden field zum Beispiel mitgebe, damit der noch weiß: Aha, das ist jetzt hier für den User und den Account. Da gibt es… Das ist relativ kompliziert, weil das muss man an den einzelnen Passwortmanagern alles mal getestet haben. Weil die alle unterschiedlich funktionieren, beziehungsweise deren Browser Plug-Ins, die ja dieses eigentliche Autofill machen, alle etwas unterschiedlich funktionieren. Und andererseits man sich nicht immer an jeder anderen Seite orientieren kann, weil für viele Dienste haben die halt schon eigene Regeln eingebaut, da kennen die den Aufbau. Wenn ich jetzt einen neuen Dienst anbiete, bin ich nicht in deren Liste, das heißt, da müssten die ganz allgemein gültigen Regeln funktionieren. Das heißt, wenn ich eine Seite kopiere irgendwo, sozusagen so von der UX, heißt das nicht im Umkehrschluss, dass der Passwortmanager damit geht, nur weil der bei der Originalseite ging, vielleicht kennt er die schon. Da ist leider zurzeit noch viel testen angesagt. Dafür gibt es keine allgemeine Regel, aber ich würde einfach die gängigen dann mal durchtesten. Wie gesagt, immer schön auf die gleichen Namen achten und immer alle Felder mitschleifen, dann funktioniert das im Regelfall ganz gut.

Lisa Maria Moritz:

Ich hätte noch eine letzte Frage zu Passwörtern aus Nutzersicht, und zwar: Wenn ich einen Passwortmanager habe und lasse mir von diesem Passwortmanager ein Passwort generieren. Ist es mir als Nutzer dann auch möglich zu sagen: Diese Seite hat folgende Policies, bitte generiere mit diesen Policies ein Passwort. Oder muss ich ab irgendeinen Punkt mir doch wieder selber Passwörter ausdenken?

Christoph Iserlohn:

Also die gängigen Passwortmanager, die ich jetzt kenne und auch denjenigen, den ich benutze, da kann ich das einstellen. Da kann ich sagen: Die Länge soll minimal so und so sein, maximal so und so sein. Ich brauche auf jeden Fall Klein- oder Großbuchstaben. Also das kann ich mit so einem Häkchen dann immer machen, Kleinbuchstaben sollen drin sein, Großbuchstaben sollen drin sein, Ziffern sollen drin sein, Sonderzeichen sollen drin sein und ich kann auch noch die Anzahl angeben, wie viele mindestens davon drin sind. Und dann generiert er das, prüft dagegen, ob das Generierte dem entspricht. Also er versucht es halt erstmal mit Zufall und dann… Also das ist die interne Mechanik. Und dann, wenn es nicht funktioniert, generiert er halt einfach immer ein neues dann so. Damit wollen sie halt verhindern, dass durch die ganzen Regeln zu wenig Zufall reinkommt. Aber das geht… Das größere Problem ist, dass man Passwortmanager nicht auf alle Geräte synchronisieren kann.

Lisa Maria Moritz:

Genau, jetzt haben wir ganz viel über Passwörter aus Nutzersicht gesprochen. Und ich stelle mir jetzt vor, ich bin Nutzer und was kann jetzt schief gehen? Also was für Angriffsarten gibt es? Was kann ein Hacker jetzt machen, um mein Passwort zu knacken, egal wie sicher das jetzt ist?

Christoph Iserlohn:

Ja, also da müssen wir unterscheiden, ob es ein Angriff jetzt auf das Front Web ist des Webdienstes, wo er dein Passwort oder deinen Account hacken will und ob es vielleicht ein Angriff auf das Back End ist, also vielleicht die Passwort Datenbank verloren gegangen ist. Und vielleicht auch, ob es gezielt ist oder nicht. Aber wir fangen vielleicht mal beim Front End einfach an, da waren wir ja gerade mit der UX auch so ein bisschen. Da gibt es halt mehrere Angriffsarten. Also dieses einfachste ist natürlich so eine Art brute-force Angriff, wo ich einfach Dinge ausprobiere. Also dann würde ich deine E-Mail-Adresse, die ja typischerweise auch dein Anmeldename ist, nehmen. Die kenne ich vielleicht aus den sozialen Medien. Und dann einfach brute-force Passwörter ausprobieren. Ich könnte die zufälligerweise generieren, aber meistens werden dann Listen genommen mit gängigen Passwörtern, die schon irgendwie so da sind. Und dann gibt es Programme, die automatisch auch so Mutationen oder Variationen von diesen gängigen erzeugen, die dann so zum Beispiel Buchstaben ersetzen durch ähnlich aussehende Ziffern oder einfach Ziffern anhängen. Also, dass wenn du das Passwort „Lisa“ hast, dann wird der halt probieren ‚Lisa2‘ und ‚Lisa1‘ und so, das machen die dann halt alles automatisch. Ist wahrscheinlich, wenn man ein gutes Passwort hat, nicht effektiv. Weil ein gutes Passwort steht nicht in so einer Standardliste drin und alle Möglichkeiten ausprobieren funktioniert halt auch nicht, wenn es halt lang genug ist. Und wenn du jetzt zum Beispiel Passphrases bevorzugst, sind die ja sehr lang, dann funktioniert das nicht. Obwohl es dafür auch schon spezielle Programme gibt, die nehmen einfach hier aus dem normalen Wörterbuch, aus dem englischen Wörterbuch, wahrscheinlich kann man denen auch ein deutsches geben, einfach irgendwelche Wörter zusammensetzten in… also diese vier Wörter und dann einfach hintereinander setzen, um sowas zu knacken. Aber das ist auch nicht so erfolgsversprechend. Und wenn man dich jetzt nicht direkt angreift, weil man nicht genau deinen Account haben will, es kann ja auch sein, dass ich den Dienst angreife, dann erweitere ich das brute-force natürlich auch noch auf die Namen. Dann suche ich mir E-Mail-Listen oder sonst wie. Das ist natürlich noch weniger erfolgsversprechend, also noch mehr Schrotflinte, weil ich ja zum einen Namen ganz viel ausprobieren muss und das schon ganz viel Zeit kostet und wenn ich alle möglichen Namen durchgehe, dann ist das wenig erfolgsversprechend. In der Praxis kommt dann eher sowas vor, dass nennt man dann credentials spraying oder stuffing. Das spraying ist so, dass man Standardpasswörter benutzt, Admin Admin, Hut Tor oder ähnliches. Und das zielt vor allem darauf ab, auf Dienste, die man so als Software gekauft hat, wo Standardpasswörter konfiguriert sind und die nicht geändert wurden, bevor man das in Produktion gebracht hat. Also damit greift man zum Beispiel so die Router an, die zu Hause stehen. Die dann vielleicht manchmal irgendwie zugänglich sind. Die die Nutzer dann unbedarft manchmal anschließen und das Standard-Passwort nicht ändern. Es ist meistens bei den Routern zu Hause ja so, dass sie nicht direkt am Netz hängen und man wirklich physischen Zugang braucht, um da auf die Admin-Schnittstelle zu kommen, aber das ist halt nicht immer so. Also das nennt man so einen credentials spraying Angriff. Und credentials stuffing ist das, wenn man… es sind ja schon ganz viele Angriffe vorher gewesen, wo so die Nutzernamen und Passwörter weggekommen sind und in Untergrundforen zu kaufen sind, beziehungsweise auch so jetzt öffentlich bekannt sind und dann nimmt man halt Listen davon. Sagen wir mal, du warst bei einem Dienst angemeldet, der wurde gehackt und da sind die Sachen verloren gegangen, dann würden diejenigen, die den Angriff starten, jetzt deine Zugangsdaten nehmen, also lisa@…, also dein E-Mail-Anbieter und das Passwort, was sie da vielleicht erbeutet haben und das bei anderen versuchen, bei anderen Diensten. Weil viele Nutzer nehmen ja immer noch auch gerne überall das gleiche Passwort. Deshalb hatte ich ja gesagt der Passwortmanager ist so gut und kann ein Passwort nehmen, aber hat für jeden Dienst ein anderes. Das wird, also so ein credential stuffing Angriff, wird dadurch sozusagen effektiv verhindert, dass ich überall ein anderes Passwort habe. Aber das machen halt ganz viele nicht und das funktioniert dann ganz oft, dass sie dann sozusagen andere Dienste, die der Nutzer hat, übernehmen können. Ja und ansonsten gibt es noch den berühmten Timing Angriff, der wahrscheinlich in der Praxis nicht mehr funktioniert, wenn man es richtig macht. Aber der mal schön als Beispiel für Timing Angriffe gemacht wird. Also das ist so, ich gebe den Nutzernamen ein und das Passwort fange ich an mit ‚A‘ auszuprobieren. Und dann gucke ich mir die Antwort des Servers an, wie lange hat das gebraucht. Und wenn wir jetzt einen normalen string Vergleich ansehen, funktioniert der so, dass der sozusagen das ‚A‘ vergleicht mit dem was das Passwort ist und wenn ein Buchstabe nicht stimmt, dann bricht der ab. Und das heißt, ich probiere so lange aus, bis der erste Buchstabe stimmt. Also ich gehe durch ‚A‘, ‚B‘, ‚C‘, ‚D‘ und gehe dann das Alphabet durch, also von A-Z in groß und kleinen Ziffern und ein paar Sonderzeichen. Und wenn er das dann gefunden hat, dann wird er den nächsten Buchstaben vergleichen und das ist eine kleine zeitliche Differenz, die man messen kann. Das ist, mit dem Messen, das ist extrem schwierig so über das Netz, da gibt es Latenzen, da ist so ein bisschen Gitter dazwischen oder so, aber da gibt es so ein paar Papers, die gezeigt haben, dass solche Timing Angriffe auch über das Netz möglich sind. Da muss man halt relativ viele Versuche machen und dann macht man eine statistische Auswertung und dann kann man das so rausfinden. Und dann kann man sozusagen jeden Buchstaben nach und nach so herausfinden, wie der ist, des Passworts. Da sind gar nicht so viele Möglichkeiten, also wenn wir jetzt sagen, nehmen wir mal ein vereinfachtes Beispiel: Man kann nur einen kleinen Buchstaben nehmen. Dann habe ich für jeden Buchstaben des Passworts 26 Möglichkeiten. Das heißt, wenn du ein Passwort mit zehn Buchstaben hast, dann sind das 260 Möglichkeiten, das kann man schnell durchprobieren. Und auch wenn es dann Großbuchstaben dazu gibt, dann verdoppelt sich das, dann sind es halt eben 520 und dann kommen noch Ziffern und Sonderzeichen, aber das kriegt man relativ schnell hin, das ist ja auch automatisiert. Aber das funktioniert eigentlich nicht, weil das jetzt voraussetzt, dass dieses Passwort in Klartext gespeichert wäre, was es normalerweise nicht sein sollte. Da kommen wir aber vielleicht gleich nochmal, wenn wir auf die Back End Seite und deren Angriffe da auf Passwörter kommen, zurück, warum man das nicht im Klartext macht und dann klären wir auch nochmal vielleicht auf, warum dieser Timing Angriff dann nicht mehr funktionieren kann.

Lisa Maria Moritz:

Genau, ich hatte gerade zu den Sachen, die du gerade erzählt hast, noch kurze Nachfragen. Und zwar hatte ich über so, über Filme, Fernsehen, Medien, was auch immer, von diesem Social Hacking gehört, ist das dann quasi so ein Unterpunkt von einem brute-force Angriff, nur das man den Menschen kennt, der dahintersteckt?

Christoph Iserlohn:

Ja, also Social Hacking ist glaube ich jetzt ein Begriff, der nicht 100 Prozent definiert ist, aber sagen wir so, in den sozialen Medien verraten die Leute halt relativ viel über sich. Und ich hatte ja vorhin schon gesagt, dass man darüber zum Beispiel deine E-Mail-Adresse rauskriegen könnte und die ist wahrscheinlich oft auch dein Anmeldename bei vielen Internetdiensten. Und früher war es ja so, das ist heute zum Glück nicht so oft so, nicht mehr so oft der Fall, dass man zum Beispiel diese Sicherheitsfragen hatte, wenn man sein Passwort vergessen hat. So. Und wenn dann nach dem Mädchennamen der Mutter und dem Namen des Hundes oder was weiß ich gefragt wird, da kriegt man relativ viel raus über Social Media. Und das heißt, da können die Hacker, die sozusagen einen Social Media-Angriff machen, ich weiß nicht, dieses Wort gibt es glaube ich nicht „Social Media-Angriff“, aber egal, du weißt was ich meine, können dann natürlich diese Informationen nutzen, um solche Sicherheitsmechanismen zu umgehen. Diese Fragen sind natürlich auch so gestellt, dass man es sich leicht merken kann. Also wenn man da irgendeinen Quatsch angibt, dann ist das zwar sicherer, aber den Quatsch vergisst man dann halt genauso. Es sei denn, ich speichere es halt in meinem Passwortmanager. Und das kann man einmal machen und man kann natürlich auch solche Sachen direkt als Passwort nehmen, also Name des Hundes oder sowas, oder Name des Kindes und so, sind ja auch Sachen, die öfter mal einfach so als Passwort eingesetzt werden. Die kann ich dann natürlich auch für so brute-force Angriffe nehmen, um sozusagen die Wörterbuchliste, die ich dann erstelle zu verfeinern und genau auf dich dann abzustimmen, wenn ich dich im Visier habe für so einen Angriff. Das geht dann. Deshalb muss man a) aufpassen, was man alles so im Internet über sich preisgibt und b) dass dann nicht so nutzen, um sich abzusichern gleichzeitig. Was gar nicht so einfach ist, weil einem das nicht immer so bewusst ist, was man alles schon preisgegeben hat.

Lisa Maria Moritz:

Dann hattest du als zweites noch das credentials stuffing und spraying angesprochen und ich fragte mich dann, ist das vielleicht sicherer, wenn man sagt: Ach, ich wechsle einfach mal alle 3–6 Monate oder so meine Passwörter alle durch, selbst wenn ich für jeden Dienst schon ein eigenes habe. Oder ist das dann Quatsch, wenn ich eh schon Passwortmanager verwenden würde?

Christoph Iserlohn:

Also ich halte das für Quatsch. Die neueren Erkenntnisse sagen auch, dass man das nicht mehr machen soll. Früher war das in vielen Policies und auch vom BSI, wenn die geschrieben haben, wie man damit sicher umgeht, vorgeschrieben oder empfohlen, dass die Passwörter durchrotiert werden und dass das auch auf der Serverseite erzwungen wird. Also, dass du, wenn du dich nach sechs Monaten wieder mal anmeldest, einfach ein neues Passwort setzen musst. Man hat dann aber rausgefunden, dass das eher dazu führt, dass die Leute schlechte Passwörter wählen, weil sie müssen sich die merken und dann wird das auch noch geändert. Dann hat man einfach so Sachen genommen, in denen man hinten eine Ziffer drangehängt hat, das ist dann jetzt nicht mehr Passwort1, sondern danach ist es Passwort2 und 3. Oder dass die Passwörter noch mehr aufgeschrieben wurden und an den Monitor geklebt wurden. Das ist jetzt sowas, was zu Hause vielleicht nicht so schlimm ist, aber im Unternehmensumfeld, wo dann viele in die Büros kommen können, natürlich sehr problematisch. Und man hat dann umgeschwenkt dazu, solange jetzt kein Anzeichen dazu da ist, dass man kompromittiert wurde in irgendeiner Form, also entweder der Server oder man selbst, dadurch, dass die Passwörter dann auch einfach nicht gewechselt werden sollen. Und der Passwortmanager sollte ja, wenn das ein guter ist, das so verschlüsselt speichern, dass man da… also, auch wenn man jetzt so einen Rechner stehlen würde und an eine Festplatte käme und das runterladen könnte, mit der Datei nichts anfangen kann, weil die das Masterpasswort dafür nicht haben. Das du ja immer, wenn du den aufmachst und damit aktiv arbeitest, ja immer eingeben musst oder alle halbe Stunde mal, der merkt sich das eine Zeit, aber dass man den nicht sofort irgendwie nutzen kann. Und gerade, wenn man den Rechner zugeklappt hat, der in sleep ging oder sonst irgendwie, verlangen die ja auch immer wieder das Passwort neu, dann sperren die sich ja auch. Von daher ist das wahrscheinlich wenig sinnvoll das zu machen, wenn die Konsequenz ist, dass man schlechtere Passwörter hat. Aber manchmal ist das noch auch regulatorisch vorgeschrieben für die Betreiber, dass die das machen müssen, so eine Policy. Dann muss man halt den Regularien gehorchen und wider besseres Wissens sozusagen, dass es eigentlich anders besser wäre.

Lisa Maria Moritz:

Genau, also ich merke mir: Als Nutzer sollte ich auf jeden Fall einen Passwortmanager benutzen, um meine Passwörter zu verwalten. Und du hattest vorhin schon erwähnt, dass es Listen gibt, wo ich prüfen könnte, ob ich schonmal gehackt wurde oder welche Passwörter von mir geleaked wurden. Ich vermute, es gibt hier auch Shownotes und wir können das dann verlinken. Willst du dazu noch kurz was sagen oder ob es noch andere Gegenmaßnahmen gibt, die ich als Nutzer oder von der Front End-Sicht her treffen kann, um Passwörter sicher zu gestalten und gegen Angriffe zu schützen?

Christoph Iserlohn:

Ja, also fangen wir mal aus der Nutzersicht an. Das ist jetzt kein Tipp, um das sozusagen noch sicherer zu gestalten, aber wichtig ist natürlich, wenn du so einen Passwortmanager benutzt: Du brauchst unbedingt ein Backup der Daten. Also wenn du das mit Masterpasswort schützt und das sind alles welche, die du dir nicht gemerkt hast und auch gar nicht merken kannst, weil sie sehr kompliziert sind, dann bist du völlig abhängig von diesem Ding. Und das heißt, da solltest du gute Backups haben, möglichst mehr als eins. Viele Dienste bieten das ja auch so als Cloud Backup an, muss man halt gucken, ob man denen vertraut, dass die auch den verschlüsselten Passwort Storage in der Cloud nochmal speichern, dass ich da auch immer wieder drankommen kann. Also da solltest du drauf achten, weil wenn dann auf einmal alle deine Passwörter weg sind, ist das natürlich auch ziemlich blöd. Dann musst du überall versuchen, irgendwie diese „Passwort vergessen“-Funktion zu nutzen. Bei manchen ist es einfach, da kriegt man einfach nur einen Link, aber bei anderen Diensten kann das auch schwieriger werden. Gerade wenn du das zum Beispiel bei deiner Bank vergisst, da gibt es nicht einfach nur so ein „Passwort vergessen“-Ding, da musst du dich vielleicht neu identifizieren mit deinem Ausweis oder so. Also gute Backups sind da natürlich sehr wichtig. Das andere ist: Was sind die Gegenmaßnahmen? Soll ich jetzt, als Serverbetreiber oder als Dienstebetreiber muss ich natürlich gucken, dass ich solche brute-force Dinger möglichst versuche zu verhindern. Und zwar kann ich das machen, indem ich zum Beispiel, wenn so viele Login-Versuche fehlschlagen auf einem Account, dass ich den dann zeitweise sperre. Das könnte man machen. Das hat natürlich den Nachteil, dass andere Leute deinen Account sperren können, indem sie den einfach bombardieren. Das heißt, ich kann das nicht als einzige Maßnahme machen, sondern ich muss auch gucken, wenn viele… ich kann das ja erkennen meistens, dass die wahrscheinlich von einer IP kommen zum Beispiel, dass ich die von dieser IP dann erstmal eine Zeit lang aussperre. Dass ich, wenn ich so merke, da probiert einer systematisch Accounts durch, dann sollte ich diese IP natürlich sperren. Da gibt es auch Möglichkeiten das zu automatisieren. Früher hieß das Programm Fail2ban, das heißt, der hat auf mehrere Log-Messages, also auf Log-Messages reagiert, und wenn so und so viele Log-Messages in einem bestimmten Zeitraum waren, dann hat der einfach die… kann man die IP zum Beispiel sperren. Und die Log-Message, die man eben konfiguriert, ist natürlich der fehlgeschlagene Anmeldeversuch, die man da machen würde. Sowas ähnliches zu implementieren. Das würde ich machen. Dann würde ich auch verhindern, dass man viele Sachen ausprobiert. Das heißt bei einer Eingabe, einer fehlerhaften Eingabe, da baue ich ein künstliches Delay ein, dann dauert das halt drei Sekunden bis der Server antwortet. Und das heißt, derjenige, der so einen brute-force Angriff macht, kann dann von einer Adresse aus nicht mehr, sagen wir mal, 3000 Mal pro Sekunde Anfragen stellen und damit 3000 Passwörter ausprobieren, sondern nur noch eine alle drei Sekunden. Dann muss er das halt auf mehrere Rechner verteilen und die können dann das gleichzeitig machen, aber das erschwert das natürlich erheblich für so einen brute-force Angriff. Und gegen dieses credentials spraying, das hatte ich jetzt schon… hattest du ja gesagt, können wir in den Shownotes verlinken, da ist natürlich der Dienst ‚Have I Been Pwend?‘ am berühmtesten. Das wird betrieben von Troy Hunt, das ist ein australischer Security Spezialist. Der sammelt da Daten von Breaches, also wo Passwörter oder Accountdatenbanken verloren gehen. Da kann man einmal selber nachgucken, ob die E-Mail-Adresse da auftaucht zum Beispiel. Das ist so ein Dienst, den er anbietet und dann weiß man, man ist in so und so vielen Breaches drin gewesen und kann dann auch erfahren, welche das sind. Und das andere ist ein Dienst dafür, da kann man abprüfen, ob ein Passwort schonmal in so einem Breach aufgetaucht ist. Also dass man so ein credential stuffing nicht machen kann. Das berühmte hier, was aus diesen xkcd Comik ist, die Phrase ‚battery horse staple‘, die ist nämlich auch schon vorgekommen. Das heißt, die steht wahrscheinlich auch in so einer Wörterbuchliste drin. Und da kann man dann anfragen: Ist dieses Passwort schon da drin? Und wenn ja, dann würde ich das nicht erlauben. Da würde ich also, wenn jemand einen neuen Account einrichtet und Username + Passwort eingibt, würde ich das Passwort dagegen prüfen. Das kann man auch so prüfen ohne das dahinzuschicken, also das ist jetzt… hört sich erstmal komisch an, dass ich das einen anderen Dienst gebe, das ist natürlich nicht so, sondern das Passwort wird gehashed als erstes. Also daraus kann man dann nicht mehr das Passwort ableiten und ich schick dann nur so einen kleinen Präfix dahin. Von ich weiß jetzt nicht wie viele Stellen das sind, ich glaube sechs. Ich weiß es nicht genau, können wir dann in den Shownotes sehen. Und dann schickt der alle, die mit diesem Präfix anfangen. Dann kriege ich eine Liste von hundert Hashes zurück und wie oft die dann in den, also den Hash und die Zahl, in wie vielen Breaches das drin war. Und da ich ja selber den Hash gebildet habe, kann ich das vergleichen: Ist meins da jetzt dabei in diesen hundert? Oder waren das hundert andere die zufälligerweise den eigenen Präfix haben? Das heißt, ich verrate diesem Dienst nicht das Passwort und kann aber gleichzeitig auch sicherstellen, dass es noch in keinem bekannten Breach drin war und damit die Wahrscheinlichkeit in einem Wörterbuch aufzutauchen deutlich geringer ist. Man kann diese Daten mit diesen Passwort Hashes auch runterladen, also man kann so einen Dienst auch selbst implementieren, wenn man ganz sicher gehen will. Dann man die lokal vergleichen. Ist allerdings eine sehr große Datenbank, die man da hat. Von daher kann man sich aussuchen. Ist man dann aber auch nicht abhängig, dass der Dienst gerade oben ist und nicht vielleicht gerade eine Downtime hat. Und das hilft natürlich dagegen. Ja, ich glaube das sind so die Sachen, die man am Front End dagegen tun kann. Also künstliche Verzögerung, Adressen sperren, die brute-force Angriffe machen und keine Passwörter zulassen, die schonmal in einem Breach aufgetaucht sind. Und das wäre sozusagen auch die einzige Policy, die ich auf jeden Fall enforcen würde, die anderen so mit Sonderzeichen und so, da bin ich so ein bisschen kritisch. Vielleicht noch eine minimale Länge, dass sie sagen wir mal so mindestens zehn oder zwölf Zeichen lang sind, würde ich vielleicht auch noch angeben. Wobei man dabei natürlich auch doofe Passwörter, wie zwölf Mal „A“, ist kein gutes Passwort, wird dann vielleicht auch noch gehen, aber dann… Also manchmal muss man dem Nutzer auch ein bisschen Verantwortung geben.

Lisa Maria Moritz:

Okay, ich glaube dann haben wir jetzt genug aus der Nutzersicht alles betrachtet und wie Entwickler dem Nutzer irgendwie zur Seite stehen können beim Passwort auswählen. Wie sieht das denn mit dem Back End aus? Also du hast ganz am Anfang schon gesagt: Na gut, aber Passwörter werden ja nicht im Klartext abgelegt. Also das ist auch eine Hoffnung, die ich irgendwie habe. Aber worauf muss ich im Back End, wenn ich irgendwie eine Passworttabelle oder was auch immer implementiere, worauf muss ich achten?

Christoph Iserlohn:

Ja, das hatten wir jetzt auch schon einige Male erwähnt. Man sieht das immer wieder, dass diese Tabellen irgendwie mal abhandenkommen. Also typischerweise durch einen Hack wird die Datenbank gedownloaded und dann hat man diese Tabelle in der Hand. Deshalb muss man die so schützen, dass auch wenn man die Tabelle hat mit den Passwörtern, damit wenig anfangen kann. Deshalb ist Klartext natürlich eine ganz dumme Idee und eigentlich sollte man das gar nicht mehr erwähnen müssen, aber man muss nur mal auf den gängigen IT-News Seiten gucken und danach suchen. Auch in den letzen Jahren ist das immer wieder vorgekommen, dass auch sehr sensible Daten, Gesundheitsdaten oder ähnliches, nur mit Klartextpasswörtern geschützt waren. Das ist natürlich ganz schlecht. Und was dann immer geschrieben wird, dass die verschlüsselt sein sollten, das ist eigentlich auch eine schlechte Idee, weil… Also wenn jetzt die Datenbank verloren geht und die sind verschlüsselt, komme ich da jetzt erstmal nicht dran, aber ich muss ja auch den Schlüssel irgendwie schützen, mit dem das verschlüsselt wurde und der ist typischerweise ja auch irgendwo, wenn die Hacker in meinem System drin waren, dann kommen die da eigentlich auch oft dran. Das ist halt problematisch. Es gibt aber Fälle, an denen das nötig ist. Wenn ich nämlich den Klartext des Passworts wieder brauche, dann kann ich nur verschlüsseln. Und das ist zum Beispiel der Fall, wenn ich Passwörter für andere Dienste speichere. Das sollte man auch nicht tun. Ein Use Case wäre halt eine Seite, die mir Fotobücher druckt und die soll jetzt an meine Bilder in der Cloud drankommen, an meinen Cloud Bilderdienst. So. Dann muss die sich irgendwie anmelden und früher hat man das gelöst, indem man einfach die credentials, also Username und Passwort, in dieser Druckanwendung gegeben hat und die konnte dann für einen da drauf zugreifen. Das heißt, die musste das aber auch speichern, weil sie immer wieder den Klartext eigentlich braucht. Dafür hat man dann halt irgendwann mal OpenID und OAuth erfunden, die verhindern das, dass man ein Passwort dafür braucht. Darüber haben wir auch schon Folgen gemacht, die verlinken wir dann auch nochmal in den Shownotes, wer sich dafür im Detail nochmal interessiert. Aber da bin ich halt abhängig davon, dass die anderen Dienste das auch anbieten. Und von daher ist das so. Ein anderer Use Case, den ich noch kenne, der mir…, ich weiß nicht ob das noch so ist, aber früher beim Telefon Banking, ich weiß auch nicht, ob es noch Telefon Banking gibt, heute machen wir ja alle das Online Banking. Aber man konnte ja bei seiner Bank anrufen und da Bankgeschäfte tätigen über das Telefon und dann mussten die Mitarbeiter in diesem Callcenter, in dem man dann aufgeschlagen ist, einen auch irgendwie identifizieren. Und dafür gab es so eine Telefon-PIN. Bei Banken gibt es ja immer PIN und keine Passwörter typischerweise. Und da musste man halt immer… wurde dann gefragt: Sagen sie mal die dritte, die achte und die zwölfte Stelle ihrer Telefon-PIN. Das war natürlich so gemacht, damit die Mitarbeiter im Callcenter nicht den kompletten PIN kriegen, sondern wurden immer zufällig Stellen ausgewählt. Aber dann musste ich ja… Das System musste ja immer noch den Klartext-PIN irgendwie haben, um das vergleichen zu können an der Stelle. Weil einzelne Ziffern kann ich in so einem Hash, dazu kommen wir gleich, warum wir das hashen wollen, kann ich dann nicht mehr vergleichen. Also braucht man da den Klartext und müsste das auch im Klartext gespeichert haben. Aber ich weiß nicht mehr, ob man so noch Bankgeschäfte tätigen kann oder will. Aber das wäre eine Möglichkeit, dass man sagt: Wir speichern sie verschlüsselt. Aber davon sollte man eigentlich absehen. Besser ist natürlich, wenn man es so gar nicht speichert, sondern nur den Hash speichert. Weil aus dem Hash kann ich halt nicht mehr das Passwort zurückrechnen, wenn ich eine vernünftige Hash-Funktion habe, also man nennt die dann halt kryptographische Hash-Funktion. Und da ist es ja halt so, dass ich beim Anmelden, habe ich das Klartext Passwort, das wird dann gehasht und mit dem Hash verglichen. Und dann kann ich halt feststellen, ob der User, der sich anmeldet, im Besitz des Passworts ist, ohne dass ich das irgendwie speichern muss. Und das heißt, wenn dann die Datenbank verloren geht, dann kann man erstmal mit den Hashes nichts anfangen. Weil die kann ich nicht direkt zum Anmelden nehmen und ich kann daraus auch nicht rückwärts berechnen, wie das eigentliche Klartext Passwort ist. Da muss man jetzt aber noch ein bisschen darauf achten, da gibt es noch ein paar Probleme, wenn ich nur einen einfachen Hash nehme. Also normalerweise könnte man da sowas wie MD5, sha1, sha2, so die typischen Hash-Funktionen nehmen. Die sind dafür aber wenig geeignet, weil die sind optimiert da drauf schnell zu sein. Und wenn es schnell ist, kann ich zum Beispiel sagen, ich mache einen brute-force Angriff da drauf. Also ich habe jetzt so eine Datenbank, da steht die Lisa drin und der Hash in sha2 gehasht, dann kann ich halt ganz auf so eine Grafikkarte heutzutage halt Millionen Hashes in der Sekunde ausrechnen. Dann kann ich halt versuchen da möglichst schnell das knacken per brute-force und da gibt dann ja auch keinen Delay, der eingebaut ist, weil die Datenbank ist ja auf dem Rechner des Angreifers. Deshalb sind diese Hash-Funktionen nicht so gut in Sachen Passwortablage, da kann das nicht verhindern, das brute-forcing. Das andere Problem ist, das liegt jetzt nicht direkt am Hashing, aber da gibt es auch eine Gegenmaßnahme: Ich sehe sofort wer das gleiche Passwort hat. Also wenn da die Leute sind, die alle das Passwort ‚QWERTY‘ haben, weil sie oben bei der Tastatur einfach mal die Buchstaben eingegeben haben, die haben auch alle den gleichen Hash. Das heißt, wenn ich dann merke: Aha, in meiner Datenbank haben jetzt 30% der Nutzer dieses Passwort. Dann würde ich natürlich zuerst versuchen das zu knacken per brute-forcing, weil ich dann direkt 30% geknackt hätte. Also wäre es gut, wenn eigentlich jeder Hash da drin irgendwie unique ist in der Datenbank. Und dagegen gibt es jetzt zwei Möglichkeiten. Also erstmal, um das unique zu machen, kann ich einfach ein sogenanntes salt oder ein pepper davorsetzen. Pepper heißt, ich habe eine Folge random Bytes, weiß ich nicht, 16 Bytes random und bevor ich das Passwort hashe, setze ich das einfach davor und hash dann die 16 random Bytes plus das Passwort. Beziehungsweise, jetzt habe ich Unsinn geredet. Das pepper besprechen wir gleich, wir nehmen das salt. Das salt ist gleich… also sind auch irgendwelche random Bytes, die sich da folgen, aber für jeden Eintrag in der Tabelle, für jedes Passwort unterschiedlich. Also wenn du einen Eintrag da hast und ich, dann haben wir ein unterschiedliches salt. Also sind einfach wie gesagt random Bytes. Aber wenn wir jetzt das gleiche Passwort benutzen würden ‚12345‘, dann wird das salt unterschiedlich und der Hash dadurch unterschiedlich. Und das heißt, ich kann nicht mehr erkennen wer das gleiche Passwort benutzt. Und dieses salt kann ich einfach mit in die Datenbank schreiben, das ist jetzt kein Geheimnis dabei, was ich noch extra brauche. Weil jeder hat ein unterschiedliches salt und wenn die Angreifer das knacken würden, dann müssten die für jeden das einzeln machen. Alle haben einen unterschiedlichen Hash, egal wer ein gleiches Passwort hat. Und das wird das brute-forcing dann halt ein bisschen einschränken, da wird ein Angreifer wahrscheinlich versuchen, irgendeinen interessanten Eintrag zu kriegen. Also wenn dann zum Beispiel hochrangige Politiker in dieser Datenbank wären und… also ich erkenne die vielleicht an ihren Anmeldenamen, an ihrer E-Mail-Adresse, dann würde ich vielleicht versuchen, die erst zu knacken. Aber ich kann nicht mehr sagen: Ich knacke irgendwie folgendes Passwort, folgenden Passwort Hash, weil 30% der Nutzer diesen haben. Also das verhindere ich mit so einem salt. Und jetzt habe ich das pepper genannt, das ist so ähnlich, das ist aber für alle gleich. Und da geht es um noch eine weitere Schwierigkeit, die ich vorhin noch gar nicht erwähnt hatte. Das ist… Ich kann ja nicht nur diese Sachen einmalig berechnen, während ich das knacke, ich kann das ja vorberechnen. Ich kann ja sozusagen Hash-Wörterbücher machen. Also ich nehme meine Listen, meine Passwörter, die alle Leute kennen und berechne schonmal die Hashes vor, dann brauche ich nur noch so ein Wörterbuch zu vergleichen: Ist da ein Eintrag drin oder nicht? Und um das zu verhindern könnte ich zum Beispiel so ein pepper nehmen. Weil das ist den Angreifern erstmal unbekannt und das heißt, die können das nicht vorberechnen. Durch das pepper sind die Hashes alle anders, auch wenn das Passwort schon im Wörterbuch stehen würde. Also nehmen wir an, die haben das Passwort ‚IchLiebeDich‘, auch sehr oft eingesetzt, hat man schon den Hash vorberechnet und aber in der Tabelle wird das halt pepper + IchLiebeDich stehen und dann wäre der Hash wieder ganz anders. Das heißt, man kann halt keine Wörterbücher vorberechnen. Und das war das pepper und man hat sozusagen danach das salt erfunden, weil das auch noch gegen diese doppelten Tabelleneinträge schützt. So. Du wolltest eine Frage stellen, ich habe die ganze Zeit geredet.

Lisa Maria Moritz:

Genau, ich wollte nur nochmal fragen, ob ich das richtig verstanden habe. Also ein salt ist für jedes Passwort unterschiedlich, das sind random generierte Bytes, die ich, bevor ich das Passwort hashe, vorne vorhänge und dann eben salt plus Passwort hashe. Und ich speichere dann sowohl das gehashte Passwort mit dem zugehörigen salt in der Datenbank ab. Und beim pepper, habe ich das richtig verstanden, dass ich dann an das schon gehashte Passwort dann einen pepper danach oder davor oder so hänge? Oder war das auch noch vor dem Hash-Vorgang?

Christoph Iserlohn:

Also das salt und pepper hänge ich an das Passwort dran. Der Unterschied ist, das salt für jedes Passwort, also für jeden Eintrag ist das ein unterschiedliches und das pepper ist für die gesamte Tabelle das gleiche. Das pepper verhindert nur die Vorberechnung des Angriffs, also das ich so ein Dictionary mit Hashes aufbaue. Und das salt verhindert sowohl die Vorberechnungsangriffe, weil das salt kennen die ja auch vorher nicht, erst wenn sie die Datenbank geleaked haben, dann stehen die salts da und es verhindert auch noch gleichzeitig, dass gleiche Passwörter den gleichen Hash erhalten, weil es für jedes Passwort unterschiedlich ist. Also salt ist wie ein pepper, nur noch besser sozusagen. Das ist pepper 2.0.

Lisa Maria Moritz:

Okay, also baue ich einen salt ein, wenn ich jetzt meine Passwort…

Christoph Iserlohn:

Man baut ein salt ein. Es gibt auch noch pepper wenn man im Internet googelt und in einer anderen Bedeutung. Da ist das pepper noch der Schlüssel, wenn man die Passwörter nach dem Hashing auch noch verschlüsselt speichert. Dann nennen das einige auch pepper, zum Beispiel bei Dropbox, hat da einen berühmten Artikel drübergeschrieben. Da nennen sie das auch pepper. Da ist die Bedeutung halt nicht so ganz klar, aber ursprünglich war es halt einfach diese random Zeichenkette. Und die muss man natürlich auch geheim halten wie den Schlüssel, damit man vorher keine Wörterbücher berechnet. So. Aber pepper ist mehr so der historische Wert, man sollte auf jeden Fall eigentlich einen salt nehmen, damit ist man auf der sicheren Seite dafür. Das andere ist natürlich jetzt noch das Problem, dass diese Hashes sehr schnell berechnet werden können. Deshalb will man spezielle Hash-Funktionen haben, die nicht so schnell sind, damit man halt nicht so einen brute-force Angriff fahren kann. Weil wenn ich im normalen Betrieb sage, der Passwortvergleich dauert jetzt eine halbe Sekunde, dann ist das nicht so schlimm beim Anmelden. Das ist aber schlimm für denjenigen, der solche Hashes berechnen muss. Wenn der jetzt auf einmal irgendwie nur noch hundert pro Sekunde berechnen kann, anstatt eine Millionen, dann ist das natürlich sehr schwierig so ein brute-force Angriff. Deshalb gibt es da spezielle Funktionen für, für diese Passwort Hashes. Das sind pbkdf2, bcrypt und scrypt eigentlich sind so die gängigen und ganz, was heißt ganz neu, aber das neuste ist argon. Da gibt es verschiedene Varianten, also 2i und 2d und 2id. Die sind so aufgebaut, dass sie relativ lange dauern und man das auch noch genau tunen kann. Also man kann den Parameter angeben, wie viele Runden soll das machen? Weil eigentlich ist das nämlich sozusagen Hash von Hash von Hash von Hash, also der geht da so immer weiter durch, vereinfacht gesagt und braucht dadurch entsprechend lange. Und das schützt dann. Und bei bcrypt und scrypt ist auch noch dazu, dass es nicht nur lange dauert, sondern auch relativ viel Speicher verbraucht für so eine Hash-Funktion, damit das sozusagen auch den Angriffsvektor da ein bisschen erschwert da an der Stelle. Dass man nicht nur schnell sein muss, sondern auch noch viel Speicher braucht. Und wie gesagt, pbkdf ist so das älteste Verfahren, das auch noch im Einsatz ist. Da kann man nur tunen wie viele Runden das macht, also wie lange das dauert. Da ist man im Moment glaube ich so auf aktuellen Rechnern sollte man so 10.000 Runden glaube ich machen. Das war, oder ist glaube ich noch, zum Beispiel im IPhone im Einsatz. Also das ist jetzt kein Verfahren, das total veraltet ist. Aber wenn man neu anfängt, würde ich das nicht nutzen. Dann gibt es bcrypt, das kommt von OpenBSD. Das hat, 4 Kilobyte benutzt das. Das hört sich nicht viel an, aber im Gegensatz zu einer normalen Hash-Funktion ist das halt unglaublich viel gewesen als man das gemacht hat. Und das kann man auch nochmal tunen dabei. Also bcrypt hat so ein paar Einschränkungen. Das kommt zum Beispiel nicht mit Unicode klar und hat auch eine hohe Bytegrenze von glaube ich 56 Bytes davon. Und das ist zum Beispiel für solche Phrases nicht so gut, also da wird das Passwort dann einfach abgeschnitten. Man kann das umgehen, indem man zum Beispiel erst das Passwort einmal hashed mit so einem normalen MD5, um das zu verkürzen und dann den Hash erst in Decrypt rein gibt, aber das würde ich auch nicht empfehlen. Meine Empfehlung wäre scrypt, das hat diese Beschränkung nicht. Das kann ich tunen da drauf, wie lange das dauert, wie viel Speicher das braucht und auf, wie parallel kann ich das ausführen? Also diese GPU sind ja so massiv parallele Kerne und da kann man auch was gegen tun. Diese Berechnungen bauen dann so aufeinander auf, dass man es auch noch nicht einmal parallelisieren kann vernünftig. Das finde ich ganz gut. Dazu gibt es auch ein Paper, das kann man verlinken. Da hat der Autor von scrypt das mal analysiert wie viele Kosten man hätte, wenn man jetzt irgendwie in der Cloud einen Server mietet, um bestimmte Passwortlängen zu knacken. Und das geht dann ganz schnell in Bereiche, die viel zu teuer sind und die auch unrealistisch sind, weil so viel Serverpower würde einem gar nicht zu Verfügung stehen. Da hat er bcrypt, scrypt und pbkdf nebeneinandergestellt. Ganz neu ist argon2. Was heißt ganz neu? Das ist jetzt auch schon ein paar Jahre alt, aber bei so kryptografischen Sachen sollte man immer vorsichtig sein, da sollte man nicht immer das neuste Einsetzen, sondern warten bis das sozusagen gut abgehangen ist. Und das ist aus dem Wettbewerb entstanden, um da einen vernünftigen Passwort Hashing Algorithmus zu haben und das war unter anderem auch der scrypt Autor zum Beispiel mit in der Jury, die die Algorithmen bewertet haben. Und da hat man… gibt es halt zwei verschiedene Varianten. Das eine ist so optimiert auf die Grafikkarten und das andere für die normale. Es gibt auch noch so eine Hybridvariante, deshalb gibt es „i“ und „d“ und „id“ und das kann man auch auf alles tunen. Und eigentlich ist das ganz gut, aber vom Einsatz schreckt ab, dass es das in den wenigsten Programmiersprachen schon in vernünftigen abgehangenen Bibliotheken gibt, wo man sagt: Dem würde ich jetzt sofort vertrauen. Da muss man sehen, das ist jetzt so die Übergangszeit so von nutzt man scrypt oder nutzt man schon argon. Das muss man dann entscheiden, auch vielleicht vom Technologie-Stack her, den man einsetzt. Wie gesagt, ich würde noch persönlich auf scrypt setzen zum jetzigen Zeitpunkt. Muss man sehen. Und damit kriegt man dann ganz sichere Passwörter raus.

Lisa Maria Moritz:

Da muss man ja echt auf ganzschön viel achten, sowohl am Front End als auch am Back End mit den ganzen Hashen und irgendwelches salt und pepper. Wäre es dann nicht viel einfacher, wenn wir alle einfach auf die social Logins gehen? Also dass wir alle einfach die Google Geschichte anbinden und Facebook und was es nicht alle gibt und dann können wir uns darüber einloggen? Ist ja sicher für den Nutzer einfacher und vielleicht auch für mich im Back End, wenn ich das entwickele?

Christoph Iserlohn:

Also im Back End ist das natürlich relativ einfach, weil da gibt es fertige Bibliotheken, da muss ich gar nicht viel tun. Das hat auch den Vorteil, weil ich, ich sage mal, ich würde Google und Facebook wahrscheinlich viel mehr zutrauen als vielen anderen kleine Firmen, dass die ihre Daten gut schützen können. Also da arbeiten ja viele fähige Leute und die haben auch entsprechende Ressourcen und können das dann mit Geld zuschmeißen, damit das sicher wird. So gesehen ist das komfortabel und gut an der Stelle, aber das ist natürlich nicht ohne Nachteile. Also einmal auf der Nutzerseite ist die Frage: Will ich denn das Google und Facebook weiß, wo ich sonst noch überall im Netz mich anmelde? Das muss man sich überlegen, das muss man halt für sich selbst entscheiden. Das kommt wahrscheinlich auch auf den Dienst an, den man da hat. Also wenn ich jetzt diese Fotobuch Drucker Sache nehme, dann ist das vielleicht gar nicht so schlimm, wenn jetzt Google das auch weiß, dass ist so ein Dienst, den ich benutze. Wenn ich jetzt aber bei der Suchthilfe einen Account habe, um da persönliche Beratungen zu kriegen, dann will ich das vielleicht nicht, dass das Google und Facebook auch wissen können. Also das ist eine Entscheidung, die muss ich von Dienst zu Dienst treffen und sozusagen mein persönliches Aluhut-Niveau abschätzen wollen, wie weit bin ich bereit das zu teilen? Aus Sicht des Dienstanbieters, wie gesagt, aus der Implementierungssicht ist das schön einfach, aber dann muss ich auch sehen, dann weiß ich vielleicht gar nicht mehr so alles über die Kunden, was ich wissen will und kann und muss. Also nehmen wir mal an, Google schmeißt mich dann aus irgendeinem Grunde raus, man hat ja schon oft gehört, dass irgendwelche Sperrungen von Account oder ähnlichen so ist, dann können sich meine Kunden auf einmal gar nicht mehr einloggen bei mir, weil die alle über Google gekommen sind oder GitHub oder Facebook oder whatever. Also da begebe ich mich natürlich dann schon in die Abhängigkeit davon, wenn ich darüber keine Hoheit mehr habe. Also das ist dann problematisch. Und jetzt neu in der Reihe ist ja dieses Login with Apple und da werden ja auch dann anonymisiert E-Mails zum Beispiel erzeugt. Das kann auch problematisch werden. Dann habe ich zum Beispiel keinen Rückkanal mehr für so Feedback an meinen Kunden, weil ich über die E-Mail-Adresse den vielleicht gar nicht erreichen kann, weil die gar nicht durchgeleitet wird. Dafür können wir auch nochmal einen Artikel verlinken, da wird das nochmal im Detail erklärt, wie problematisch das ist. Wie so… Wenn Leute beim Customer Care sich melden und dann hat man keine Möglichkeit, denen eine E-Mail zu schreiben, weil man die Daten dann nicht mehr hat. Das muss man sich dann halt überlegen, braucht man das? Was ist denn mein Dienst überhaupt? Kann ich mir das erlauben, dass die Daten dann mal… dass ich, wenn ich mal ausgesperrt bin, die Leute sich nicht einloggen können? Das ist immer so eine Sache, wie das so typischerweise ist, es kommt drauf an, muss man abwägen. Von daher, ja. Und in Sachen natürlich, gerade hier in Deutschland mit Datenschutz. Wenn die Anmeldedaten dann bei Google und Facebook liegen, könnte man natürlich auch vielleicht Probleme bekommen. Ich bin kein Datenschutzexperte, aber die ganzen Datenschutzabkommen mit den Vereinigten Staaten sind ja alle vor den Gerichten gescheitert und da ist auch eine unklare Lage. Ist vielleicht auch die Frage, ob ich das machen will. Auch wenn die mich nicht aussperren, ob ich dann woanders Probleme kriege und dann auf einmal hier mit dem Gesetz im Konflikt bin. Ja.

Lisa Maria Moritz:

Ja, spannend. Also ich merke mir, das ist alles nicht so einfach und es kommt drauf an, ob ich mir das jetzt so einfach machen kann für meinen Dienst im Back End oder ob ich mich doch ein bisschen mit Verschlüsselung, beziehungsweise nicht Verschlüsselung, sondern Hashing und der Passwort-Hashing-Funktion beschäftigen muss. Ja, ich habe super viel gelernt, ich bin dir sehr, sehr dankbar für diese Folge, weil sie mich auf jeden Fall weitergebracht hat. Ich hoffe auch, dass die Zuhörerinnen und Zuhörer sich freuen. Ja, vielen, vielen Dank Christoph!

Christoph Iserlohn:

Gerne!

Lisa Maria Moritz:

Vielen Dank fürs Zuhören! Ich hoffe, ihr hattet genauso viel Spaß und habt so viel gelernt wie ich. Und ja, dann bis zur nächsten Folge!