Transkript: Security

Ja, hallo, liebe Hörerinnen und Hörer.

Willkommen beim Python Podcast in der 26.

Episode heute.

Heute ist das Thema Security.

Ein Thema, was ich persönlich sehr, sehr spannend finde.

Dazu haben wir natürlich auch wieder Gäste eingeladen, neben dem Jochen und mir, dem Dominik.

Sind heute wieder dabei der Christian, der Teuni und der Philipp.

Hallo, Philipp.

Hallo!

Wie geht's euch?

Stellt euch doch mal kurz vor, wer ihr denn seid und dann erzählen wir ein bisschen was über die Folge.

Tja, wer fängt an?

Also ich bin der Jochen.

Ja, okay.

Also ich glaube, das brauche ich gar nicht weiter ausführen.

Aber ich glaube, am interessantesten ist wahrscheinlich Philipp, der ist jetzt gerade zum ersten Mal dabei.

Genau.

Ja, ich bin Philipp.

Ich habe bis vor kurzem noch an der Uni Düsseldorf studiert und nachher auch gelehrt zum Thema unter anderem auch Security.

Also ich habe da die Vorlesung zur Internetsicherheit, glaube ich.

Oder wie haben sie sie genannt?

Also intern ist sie einfach Security.

Die Security-Vorlesung gehalten.

Netzek haben wir sie genannt.

Also Netzwerk-Sicherheit ist sie offiziell.

Und bin jetzt seit zweieinhalb Jahren arbeite ich für die Firma Boxine in Düsseldorf.

Die ist wahrscheinlich bekannt durch ihr Produkt, die Tonibox.

Also wenn man kleine Kinder hat, dann kennt man die Tonibox.

Oh ja.

Und genau die läuft auch mit Python.

Vielleicht kommen wir dann nochmal ein bisschen dazu.

Oh cool, da haben wir letztens am Wochenende noch jemanden getroffen, der für die Firma arbeitet.

Interessant.

Ja, ja, ich habe mich jetzt letzte Woche, genau mit Jens, den kannst du dann wahrscheinlich auch lange unterhalten.

Genau, der Jens ist auch in meinem Team.

Jens ist auch ein anderer, einer von den Python-Entwicklern bei Boxine.

Ja, ja, ja, die Tonibox ist super beliebt.

Ja, das ist ein Python-Projekt geworden ist, ne?

Also ihr kennt ja bestimmt, das sind diese kleinen Spielzeug, Figuren, die man auf eine Box stellt und dann spielen sie ein Hörspiel.

Also für alle, die keine Kinder haben.

Genau.

Ja, schön.

Also heute das Thema Security.

Wir wollen das so ein bisschen aus mehreren Perspektiven beleuchten, die wir noch gar nicht so genau festgelegt haben.

Ist wie immer, ich habe keine Ahnung, stell dumme Fragen.

Und die Jungs antworten ein bisschen.

Ja, fangen wir doch direkt an.

Was ist denn Sicherheit?

Security, was meint das denn?

Also, dass niemand irgendwie einbricht und dann hat jemand irgendwie einen kaputten Pullover an und dann riecht er so einen Rechner mit grüner Schrift und dunklem Monitor oder wie sieht das aus?

Das trifft wahrscheinlich schon ziemlich gut.

Du kannst ja, also du möchtest Leute schützen davor, dass das oder möchtest Systeme schützen vor irgendwelchen Angreifern.

Das ist das grundsätzliche Prinzip der Sicherheit.

Du hast dann verschiedene Ziele.

Ganz traditionell hat man die Integrität, dass ich sagen möchte, niemand möchte was ändern.

Ich habe die Vertraulichkeit, dass ich sagen möchte, niemand möchte, also niemand soll herausfinden können, welche Daten meine Benutzer haben.

Zum Beispiel bei uns, beruflich bei der Toni-Box, auf die kann man ja beliebige Audioteilen draufspielen und es soll auf keinen Fall möglich sein, dass irgendjemand anders die Audioteilen von einem Kunden abrufen kann.

Also das wäre Vertraulichkeit.

Und dann haben wir noch Ziele, die werden manchmal so Zuverlässigkeit genannt oder Availability, wo es halt darum geht, dass das System verfügbar ist die ganze Zeit.

Okay, also schon irgendwas, was einen auch privat betreffen kann natürlich und vor die man vielleicht geschützt werden möchte.

Ja, und wie macht man das denn in Python?

Ja, also ich würde jetzt so spontan sagen, eigentlich hat man ja in Python schon mal ganz gute Karten, weil ein großer Teil der wirklich bösen Fehler, die einem da so begegnen können, hat man jetzt in Python eigentlich gar nicht.

Also so mit Buffer-Overflows hat man eigentlich eher nicht so wirklich viel zu tun.

Obwohl, jetzt ist es eigentlich schon wieder, dem müsste ich erklären, was das ist.

Oh nein, das sollte.

Wir sind dringend einstiegen, du hast gesagt, man kann Fehler machen und das bedeutet, dass Fehler zu Sicherheitslücken führen können, die dann Angreifer ausnutzen können.

Ist vielleicht einer der Punkte, über die wir vielleicht reden, welche Sicherheitslücken es denn gibt.

Aber was du sagst, heißt, es gibt Fehler, die jemand gemacht hat, also ein Entwickler, eine Entwicklerin gemacht hat, die dazu führen, dass es schwierig wird.

Genau, das Programm macht dann irgendwas, was der Entwickler nicht gedacht hat.

Also der Entwickler dachte sich, okay, da kommen doch immer gute Daten und dann hat jemand mit einem grünen Bildschirm und einem Kapuzenpulli nach herausgefunden, okay, wenn ich ganz bestimmte Daten sende, dann macht das Programm etwas, was der Entwickler nicht wollte und erlaubt mir dann Zugriff auf irgendwelche Geheimdaten oder im schlimmsten Fall erlaubt mir sogar Code auszuführen bei irgendjemand.

Und genau das wollen wir halt verhindern.

Und da gibt es halt eine ganze Menge Schwachstellen, je nachdem, auf welcher Plattform man ist.

Also zum Beispiel auch mit Python gibt es Unterschied natürlich, ob ich einen, wenn ich einen Treiber schreibe, dann kann auch der eventuell Buffer Overflow vielleicht schon mal passieren.

Wenn ich mit Python eher eine Web-Anwendung schreibe, dann muss ich mir da halt typische Sicherheitslücken anschauen.

Aber das ist eigentlich immer, dass ich irgendwelche Eingaben des Benutzers nicht richtig interpretiere und dann plötzlich komische Sachen mache.

Benutzereingabe speichert, also Buffer-Overflow, vielleicht nochmal ganz kurz, dass irgendwie der Speicher läuft voll und dann kommt man in Bereiche rein, die das Programm gar nicht vorgesehen hat und dann passieren komische, magische Dinge.

Das ist dann diese Blackbox, der Mensch mit dem Kapitul zu Polo.

Naja, also so ganz, ganz kurz irgendwie ist auch eine relativ spezielle Art von Sicherheitsproblem, aber das war irgendwann, ich glaube, das war dann Mitte der 90er, ich weiß nicht mehr so ganz genau.

Gab es einen Artikel im Frag Magazine von Aleph One, irgendwie Smashing the Stack for Fun and Profit.

Und es betrifft vor allen Dingen die Programmiersprache C, die ist halt, da sind Strings Nullpointer terminiert.

Und naja, wenn man.

Ach so.

Genau.

Also da steht nicht an einem String vorher dran, irgendwie, der ist jetzt so und so lang und dann liest man halt nur bis da, sondern man liest halt so lange, bis halt ein Nullbyte kommt und dann hört man halt auf damit.

Oder halt eben auch nicht, wenn man irgendwie das falsch macht.

Ah, das heißt, wenn man am Ende sagt, da sind gar keine Nullbyte, sondern sein eigener Code, dann liest er gar nicht, liest das immer noch weiter.

Genau, wenn man zum Beispiel einen festen Buffer definiert hat und aber nicht überprüft, ob die Eingabe von dem Benutzer halt vielleicht länger ist, dann kann man halt über den Buffer hinweg schreiben unter Umständen.

Und dann halt auch, also was man dann macht, man schreibt dann irgendwie eine Menge Knobs, was ist das?

Irgendwas A oder so rein, hofft dann, dass beim Rücksprung aus der Funktion irgendwie man in diese Bereich landet und dann rutscht es halt durch bis zu einem Shellcode, den man mit reingeschrieben hat.

Und dann kann man also im besten Fall irgendwie direkt das Programm komplett übernehmen.

Und ja, das war, das war lange Zeit war das ganz, hatte, hat bei viel Server-Software hatte diese Fehler und man konnte das halt ausnutzen.

Obwohl, ich meine, heute spielt das vielleicht auch immer noch eine Rolle, vielleicht eher so bei Clients, ich glaube Server, obwohl gibt es vielleicht immer noch, ich weiß es nicht mehr so genau, ich habe auch so lange nicht mehr drauf geguckt.

Ja, aber das ist halt so eine, das ist eigentlich genauso das, was man, was sich Leute vielleicht vorstellen, wenn man davon redet, dass jetzt irgendwie irgendwelche Server gehackt werden oder so.

Man gibt irgendwas ein oder führt ein Programm aus und dann hat man eine Shell auf einem anderen System, wo man einfach Code ausführen kann oder beliebige Kommandos.

Da kann man auch tatsächlich sozusagen diese Perspektiven von, man muss halt, da kann man nochmal einen ganzen Schritt zurückgehen, weil im Prinzip das Thema Sicherheit kann man noch weiter aufmachen.

Wenn ich halt, Philipp hat gesagt, Anwender-Input, das ist so ein, das muss man oder kann man noch weiter abstrahieren, weil im Prinzip sind Viren halt auch nichts anderes als Anwender-Input.

Das ganze Thema von Security lässt sich halt darauf zurückführen, warum muss ich überhaupt drüber reden, warum machen Programme überhaupt was, was man nicht will.

Lässt sich halt stark darauf zurückführen, dass wir halt eine sogenannte von Neumann-Architektur haben.

Ja, das geht halt zurück auf die, was weiß ich jetzt schon gar nicht mehr.

Mir wurde immer vorher geworfen, Opa redet vom Krieg, aber da war ich nicht dabei.

60er, 70er, irgendwo da, noch älter, 40er von Neumann-Architektur.

Noch älter, ne?

Es war vor dem Zweiten Weltkrieg wahrscheinlich sogar, ne?

Irgendwo da, also als es so richtig losging, gerade erst mit den ganzen allgemeinen Rechenmaschinen.

Und die von Neumann-Architektur hat halt ein wichtiges Konzept und das ist halt, dass der Programmspeicher und der Datenspeicher eins sind.

Das ist in der von Neumann-Archektur.

Es gab früher Rechnerarchitekturen, da waren Daten von der Eingabe und die Daten, die den Prozessor gesteuert haben, also das Programm, komplett getrennt.

Macht halt das große Problem, dass du nicht einfach irgendwie Programme als Daten runterladen und ausführen kannst.

Also der Effekt, den wir dadurch haben von der von Neumann-Architektur ist ja, ich kann ins Internet gehen, kann mir Daten runterladen und sie dann als Programm ausführen.

Das Problem ist aber, der Vorteil ist gleichzeitig ein Nachteil, das heißt, auch Daten, die vielleicht gar nicht als Programm gedacht waren, werden als Programm ausgeführt.

Und das ist sozusagen die ganze Kruxa dran, dass die CPU schon nicht unterscheiden kann von, ist das jetzt hier, sind die Bytes bei mir gerade gedacht für, ich soll mit ihnen rechnen oder ich soll damit meinen Instruction Pointer befüttern?

Und das kannst du halt, da gibt es ein, dieses Grundproblem wird never ever jemals weggehen.

Das geht nie weg.

Na gut, also moderne CPUs haben ja durchaus einige Verteidigungen dagegen.

Also moderne CPUs haben einen Marker, wo dann drin steht, okay, diese Speicherseite ist ausführbar oder nicht.

Und genau das würde ja, das geht ja dann schon in Richtung der konkurrierenden Harvard-Architektur ein bisschen, dass man sagt, okay, das sind die Daten, das sind die Instruktionen.

Aber natürlich gibt es immer noch Tricks.

Also selbst bei den Buffer Overflows gibt es halt sehr, sehr viele Möglichkeiten, wie man genau dann doch irgendwie noch ein Programm konstruieren kann, das dann eigentlich nur aus Daten besteht.

Also, wo du sagst, okay, das sind eigentlich nur Daten, aber die auf komischen Stellen liegen und dann trotzdem den Programmfluss irgendwie beeinflussen.

Das Spannend, also ich wollte eigentlich zu dieser Frage mit den, was machen denn die CPUs dann da falsch, ganz zum Schluss kommen, ihr habt ja jetzt damit den Einstieg gefunden, dass es das vielleicht die unterste Ebene, auf der wir jetzt anfangen.

Ich finde das aber sehr spannend, weil was du sagtest, dass diese unterschiedlichen Architekturen, also ich glaube, von Neumann nennt man auch irgendwie Prinzen-Architektur.

Und ich glaube, es war irgendwie, ich habe gerade nachgeguckt, 45, als sie rausgekommen ist.

Und diese Harvard-Architektur, die daneben liegt, die macht halt diese Trennung von Daten und Programmspeicher.

Und du sagst jetzt, es gibt auf dem CPU, also der CPU benutzt für alle Menschen, die da vielleicht nicht so drin sind, Ob Codes, ja, also Operation Codes, das heißt, die sagen, was für eine Rechenoperation er machen soll, der Kern.

Und dann macht er genau mit den Daten, die ihm dazu geschickt werden, in den einzelnen, was sind das, Decks, nein, Registern irgendwie, macht er dann diese Operation.

Und da kann was schief gehen.

Vielleicht kannst du das noch ein bisschen erklären, weil das irgendwie klingt sehr spannend.

Ja, weil wenn ich einen ganz klassischen Buffer Overflow habt, was halt passiert, ist, wie gesagt, der Benutzter, äh, der Benutzer in Anführungszeichen, aber in Wirklichkeit ist das der Angreifer, gibt halt irgendwie eine längere Datenfolge an.

Und wie wir eben schon erwähnt haben, da könnten dann zum Beispiel verschiedene Instruktionen wie Knobcodes drin vorkommen.

Und das sieht aus wie ein normaler Text, aber das ist halt genau so designed, dass man das auch als Obcodes für die CPU interpretieren kann.

Und genau das ist das Problem danach, dass der Entwickler dachte, okay, da kommt einfach nur Text rein, aber in Wirklichkeit hat der Angreifer den Text so geschickt konstruiert, dass er ein gültiges Programm ist.

Und es ist sozusagen, wir können für die CPU, weil das konkret zu machen, ist häufig sehr schwer so im luftleeren Raum, aber weswegen ich schnell zur Neumann-Architektur gegangen bin, ist, das Problem ist ein ganz grundsätzliches Architekturproblem.

Und die Features, die wir jetzt da oben drüber legen, wie zum Beispiel Non-Executable Pages und so ein Kram, oder was dann halt auf anderen Ebenen kommt, Address Randomization und so ein Zeug, das sind alles bloß kleine Trostpflaster und man macht es den Angreifern schwerer und teilweise auch um Größenordnungen schwerer, dagegen anzukommen, aber das Restrisiko kann in der Architektur halt nie weggehen.

Sie wird nie weggehen.

Und die Effekte, die wir aber sehen, lassen sich auf anderen Ebenen genauso wieder erklären.

Und ein Buffer-Overflow lässt sich gut vergleichen und das ist für viele Leute wieder einfacher vorstellbar, wie mit einer SQL Injection.

Das ist genau das gleiche.

Eine SQL Injection ist, gib hier bitte deinen Namen ein und dann kommt das berühmte, mein Name ist Bobby, blablabla, Semikolon, Drop Tables.

Und auch da ist es so, das Programm hat gedacht, ich habe eine Eingabe und die Datenbank haut dann aber einmal volle Kanne daneben und sagt, na das ist doch jetzt die nächste Quary hier.

Weil wir drücken ja alles als Text aus.

Der Name ist Text und das Programmierstatement für die SQL-Datenbank ist auch nur Text und wird dann aber eben als Programm interpretiert.

Und wenn ich das eben nicht richtig escape an der Stelle, dann finden solche Modusübergänge statt, wo etwas, was eigentlich als Eingabe zu verarbeiten gewesen wäre.

Und der Trick ist ja eben der, von Neumann-Architektur, die SQL, äh, das SQL-Statement, was ich an den Server drücke, ist ja aus Serverperspektive erstmal Daten, die als Programm zu interpretieren sind.

Und wenn darin halt Mist stattfindet, dann geht da alles quer durcheinander.

Und das ist ein Buffer Overflow im Prinzip nichts anderes.

Also das Glas Milch, das zu voll ist und dann tropft das auf die Erde und dann hat man alles nass und denkt sich, oh nein.

Ja, genau.

Und Buffer Overflow ist sozusagen die Variante von, dass das Glas ist zu voll.

Und auch Python schützt einen vor sowas im Prinzip erstmal nur im Sinne von, ja, Python selber gibt sich extrem viel Mühe, selber kein Mist zu machen.

Wenn du aber, und ich habe mit sowas halt selber auch, also ich sage immer, ich fasse C Not dann an, wenn die anderen es verrissen haben.

Ich schreibe nie C-Code neu.

Ich habe den C-Code nur in der Hand, wenn die anderen es völlig kaputt gemacht haben und ich gerade so noch weiß, wie ich es mir ganz mache.

Der Psycho-PG ist zum Beispiel halt im Datenbankumfeld.

Da merkt man so, dass die Leute halt eigentlich keine C-Programmierer sind, wenn man den Code anguckt.

Und es hat lange gehalten.

Philipp macht genau das richtige Gesicht, das können jetzt die Podcast-Hörer nicht hören, aber wir haben so einen Corona-tauglichen Video-Back-Channel.

Und da ist es halt zum Beispiel so, nicht jeder Buffer-Overflow ist gleich halt als Security-Problem ausnutzbar.

Bevor ich halt sozusagen selber Code ausführen kann, kommen noch andere Fehlerklassen oder Effekte vorher.

Typischerweise ist das dann erstmal ein Denial of Service.

Also zum Beispiel, dass halt das Programm crasht.

Das ist erstmal noch nicht so dramatisch.

Das ist natürlich auch aus dem Thema Availability als eine der vier Sicherheitsperspektiven.

Nur die Recovery ist halt einfacher typischerweise.

Bei dem Crash starte ich im schlimmsten Fall starte ich normalerweise die Anwendung einfach neu, dann geht es weiter.

Und beim Psycho war es zum Beispiel so, dass der, das ist im Postgres gibt es Encoding-Namen.

Und die meisten Encoding-Namen, die von den Leuten verwendet werden, haben ein Minuszeichen drin.

ISO 88591 und so Gramm.

Und im Psycho-PG ist es so, dass der Encoding-Buffer tatsächlich davon ausgeht, dass da ein Minus drin ist und sie meinten, es wäre eine gute Idee, sie müssen alles normieren und die Minus rausnehmen.

Und das ist in Postgres auch okay.

Der hat die ganzen Encoding-Namen auch immer noch mit ohne Minus rumliegen.

Und ein Kunde von uns kam aber dann damals auf die Idee, es gibt in Postgres einen Alias für UTF-8, der heißt Unicode.

So, und dann hat der Psycho halt gesagt, na jetzt kommt hier ein Encoding-Name, also streiche ich das Minus, das Minus raus.

Allizieh einen neuen Buffer, der genau ein Byte kürzer ist, und schreibe dann Unicode ohne Minus in einen, statt, was haben es?

In einen 6-Byte-langen Buffer statt in einem 7-Byte langen Buffer.

Und weil sie aber nicht einfach nur Melllock benutzt haben, weil ganz kleine Objekte zu allotisieren im Speicher halt ineffizient sein kann, hat Python einen sogenannten Small Object Allocator.

Damit kann ich in eine Page, die ist typischerweise ein K oder sowas, je nachdem System kann die auch ein Megabyte oder größer sein, aber gehen wir mal von einem K aus oder 4K.

Dann packt Python halt solche 6 Byte-Objekte alle zusammen in eine Page und dann brauche ich halt statt irgendwie, wenn wir mal kurz rechnen, 1006 sind 20, nee, 200.

200.

Dann brauche ich halt statt 200 Pages, also statt 200k nur 1K.

Die werden eng an eng hintereinander gepackt.

Und was dann passiert ist, ist, dass der Server, der das hatte, so alle Woche mal gecrashed ist.

Und ich habe das halt versucht rauszufinden und irgendwann habe ich da mit, ich habe mit Guido mal reingeguckt, die hat mit Martin von Löwis reingeguckt, ein bisschen Leuten und irgendwann haben wir festgestellt, der schreibt dann halt manchmal genau auf den letzten Eintrag in dieser Page, dieses eine Byte zu viel.

Und das eine Byte zu viel in einer sogenannten Arena im Small Object Allocator ist der Pointer auf die nächste Arena.

Und der landet dann halt im Nirvana und dann flägt, dann gibt es halt ein Segfault und dann sagt das Linux halt, so geht es hier nicht.

Und das ist ein typisches Beispiel für.

Da hat jemand dann einen zu kleinen Buffer alloziiert, das ist dann ein Buffer Overflow.

Er schreibt mehr Daten rein, als da reingehören, weil er sich einfach bloß verrechnet hat.

Und der Effekt muss noch nicht sein, dass jemand Code ausführen kann, aber der Effekt ist halt, typischerweise, dass das Programm anfängt, Müll zu machen und dann haben wir, Philipp hat da ja auch genickt, schon mal die Availability, die Verfügbarkeit von der Anwendung reduziert und das ist ein Sicherheitsproblem tatsächlich auch.

Genau, es könnte ja auch dann sein, dass es nachher auf dem Server irgendwo läuft, wo dein Postgres läuft und das kann vielleicht auch jemand, den Server möchtest du für viele Kunden bereitstellen und dann ist es auch richtig kritisch, wobei hoffentlich niemand dein Encoding im Server steuern kann.

Das wäre wahrscheinlich eine andere Sicherheitslücke.

Ja, aber also Denial of Service ist halt, das ist böser, als die meisten Leute so zunächst vermuten würden.

Ich meine, wir hatten jetzt auch letztens irgendwann in Düsseldorf an der Uniklinik ja auch so einen eher gemeinen Fall.

Irgendwie so diese Ransomware-Geschichten, die es da gibt, ich weiß nicht, das war irgendeine Remote-Verwaltungssoftware, ich weiß den Namen wieder vergessen.

Citrix.

Citrix, genau.

Ja, irgendeine uralte Version davon und dann ist irgendjemand hingegangen und hat denen ihre Daten verschlüsselt oder so und hat sie erpresst.

Und da ist, glaube ich, dann tatsächlich auch jemand bei gestorben oder so.

Das war irgendwie sehr unschön.

Ja.

Das ist dann auch der Teil, den grenzt man in der Security manchmal ab.

Im Englischen ist es halt.

Safety.

Ja, das ist im Deutschen haben wir das sozusagen nicht getrennt.

Ich finde das eigentlich so schön, ein schönes Beispiel, dass Konzepte mit extra Begriffen in anderen Sprachen einem nochmal einen neuen Blick liefern, dass Sicherheit im Englischen halt mit Security und mit Safety übersetzt werden kann.

Und Safety ist halt die auf Menschenleben und körperliche Unversehrtheit bezogene Perspektive von Sicherheit.

Und Security ist halt die Frage, ob das Fahrrad noch da ist.

Aber kannst du das denn in der modernen Gesellschaft wirklich auseinanderhalten?

Ja, das ist halt sozusagen genau das Thema, dass man damit machen wir jetzt einen schönen nächsten Bogen, dass Security extrem kontextspezifisch ist.

Also ich stelle mir ja gerade die Gesichtsbemalung vor, die dazu führt, dass die Kamera als den Algorithmus verändert und ein anderes Gesicht immer in die Dinge, also die Daten erkennen lässt und dann kann ich mich tarnen mit einer gewissen Schminke und da jemand anders ausgeben.

Weil der Algorithmus dadurch, denke ich wie jemand anders, weil ich einen anderen Gesichtshash bekomme oder so.

Das ist so spannend in dem ganzen Machine Learning-Umfeld, dass du diese Adversarial-Models hast, dass du sozusagen auf der einen Seite ein Model haben kannst, was Dinge erkennt und jemand anderes weiß, aber, wie er auf Basis eines Models Outputs generiert, die dieses Model dann wieder aus dem Takt bringen.

Ja, nur für seinen Social Score oder sowas kann man die dann hochhalten, obwohl man andere Sachen tun kann.

Ne, die Ecke von Philipp fand ich jetzt nochmal wichtig und spannend, dass halt dieses Thema, ah, hier passiert ja nichts Schlimmes.

Das Interessante ist eben, durch dieses Architekturproblem trifft es halt alle und jeden.

Also jedes Stückchen Code, was du schreibst und mit dem großen Problem Dual Use, du weißt halt nie, wofür wird Code halt mal eingesetzt werden.

Den schreibt man jetzt und der ist da und ganz ehrlich, Leute, die Code finden, werden ihn benutzen.

Er wird irgendwo benutzt werden und er wird für Dinge benutzt werden, die man sich nie vorgestellt hat.

Wobei ich da auch immer eine Lanze dafür breche, zu sagen, naja, der, der den Code in den Kontext einführt, hat die Verantwortung, sicherzustellen, dass er da was Sinnvolles tut.

Also dann macht er ein

Projekt mit NPM-Paketen oder sowas.

Ja, aber das ist deren Verantwortung.

Es ist nicht die Verantwortung von jemandem.

Es gibt im Open-Source-Umfeld kann man ja auch viel da nochmal drüber reden, über die Motivation von Leuten, die halt so Open Source Packages maintainen, die dann ein Riesenschwergewicht kriegen.

Ich finde, die Leute haben keine moralische Verpflichtung anderen gegenüber aus ihrem Freizeitprojekt, wo sie sagen, da steckt einfach nur meine Lust und meine persönliche Motivation drin, anderen Garantien auszusprechen, dass sie damit jetzt einen Space Shuttle betreiben können.

Ja, das ist natürlich nicht.

Das darf man so nicht umdrehen.

Und nichtsdestotrotz ist es natürlich ein.

Das ist alles ein etwas zusammengeschimmertes kleines Raumschiff, was immer droht, auseinanderzufallen, was auf der einen Seite mit Kohle und auf der anderen Seite mit einem Handpedal betrieben wird und kann also genau weiß, wo denn jetzt ins nächste Leck entsteht.

Ja, ich meine, ja, ich hätte auch große Bedenken, irgendwie so medizinische, also Software für medizinische Geräte zu schreiben oder irgendwelche Software, die Flugzeuge steuert oder so, da hätte ich irgendwie groß, würde ich wahrscheinlich eher lieber nicht.

Wahrscheinlich schon bei Banktransaktionsgeschichten schon bedenken, aber.

Allein das zeichnet dich aber eigentlich schon aus, als jemand, der qualifiziert sein könnte, das zu tun.

Nein, zu

viele Leute gehen nämlich ohne diese Vorsicht heran.

Also man hat mal früher gesagt, die Deutschen bauen die besten Atomkraftwerke, weil die so scheiß viel Angst davor haben.

Und halt entsprechend in die Sicherheit investieren.

Deswegen ist Siemens mit den Atomkraftwerken so ein Exportschlager.

Andere haben halt weniger Angst davor und machen dann halt auch weniger Sicherheit.

Das ist so ein bisschen ein, wer sich halt auf dem Fahrrad sicher fühlt und kein Helm aufsetzt, ja, wer sich unsicher fühlt und einen Helm aufsetzt, ist am Ende bei einer echten Kollision halt feiner raus.

Ja, aber ich meine, das ist einfach, ich glaube, also das, was mich da so unsicher fühlen, lässt es halt einfach, es ist schwer zu hinzukommen.

Also es ist schwer überhaupt sicherzustellen, dass da nichts passieren kann.

Es kann so viel schief gehen, es ist.

Es geht auch nicht.

Das ist dann der schöne Übergang zu dem Thema Security als Prozess halt.

Man kann halt immer, ich glaube, etwas, was lange in der Informatik gelehrt wurde, ist halt das Problem sozusagen, Security als abstrakte mathematische Eigenschaft eines Systems.

Das wird an vielen Stellen auch noch verfolgt und da kommen interessante Sachen raus, gerade wenn wir gucken in Richtung strenger Typsysteme und also im Zeug.

Also ADA zum Beispiel, dieses ganze Umfeld.

Und da finde ich es auch spannend, dass die tatsächlich Dot Engineering haben.

Ich hatte ADA nur mal im Studium und muss sagen, also es ist halt, was die Garantien angeht, wirklich straff.

Es ist auch ziemlich schnell.

Ich habe aber nie irgendwas Sinnvolles damit programmieren können.

Kannst du vielleicht nochmal ganz kurz erklären, was ADA ist?

ADA ist eine Sprache, die ist extrem formal definiert und die wird hauptsächlich im militärischen Bereich eingesetzt.

Also bei uns in der Uni ist sie gelehrt worden und dann gab es halt gerne mal von der Eurocopter und von anderen Leuten Besuche, wo es darum ging, irgendwie Steuersysteme für Kampfhubschrauber und so ein Kram zu programmieren.

Und die ist halt, die zeichnet sich dadurch aus, dass sie ein sehr umfassendes Typsystem hat.

Das heißt, da wo man in anderen Sprachen halt sagt, ich hatte ja gern ein Integer, kannst du dem Ding halt sagen, ja, ich will hier einen Integer haben, der darf aber nur von 7 bis 9, 11, 13 und 12 sein.

Und der Compiler kann dir vorher über alle Operationen deines Programms schon sagen, ob die Verkettung der Operationen in Summe noch zu zulässigen Ergebnissen führt.

Oder ob du irgendwo deine Wertebereiche sprengen würdest.

Und gleichzeitig, und das ist halt wirklich cool, die können halt Echtzeit und sie sind auch auf anderen Systemen sehr, sehr schnell in der Laufzeit nachher.

Und das ist halt, das ist was wert.

Gleichzeitig ist es aber so, immer wenn es um I.O.

geht, nämlich da, wo halt dieses Thema, da kommen Daten von draußen rein oder müssen wieder raus, da gucken so ein bisschen die Luft und sagen, naja, das macht die mal anders.

Das ist dann halt immer, also daher zu gehen und zu sagen, ich hätte jetzt hier gerne mal schnell eine Uhr eine HTTP-Library und ich würde dir ein SSL, nochmal da drüben, über ein Repository von GitHub, das sowas ist bei ADA halt, eher nicht so an der Tagesordnung.

Und du brauchst halt auch eine entsprechende Engineering-Menge und Genauigkeit, all die Kombinationen, mit denen du sozusagen konfrontiert wirst, dir so genau anzugucken, das lohnt sich halt auch eigentlich nur, wenn da wirklich Menschenleben dranhängt.

Ja, wenn du sagst, es ist okay, wenn dieses kleine Programm jetzt zwei Millionen Euro kostet.

Wo jemand anders sagt, komm, da hack ich dir jetzt das Shell-Skript runter und dann ist es gut.

Da muss man nur mal aufpassen, dass es halt kontextbezogen ist.

Also die kommen halt aus dieser Ecke von einer mathematisch perfekten, idealisierten Variante von so, wir schreiben jetzt das Programm und das ist dann sicher.

Und wenn du in ausreichend komplexe Systeme kommst, musst du aber eigentlich eher einen prozessorientierten Ansatz machen.

Genau, genau, da würde ich nämlich jetzt auch gerade noch kurz konzt einhaken und sagen, naja, das Blöde ist, dass einem halt auch diese Geschichten nicht unbedingt schützen vor wirklich fatalen Fehlern, wie zum Beispiel, ich weiß nicht, ob das der Jungfernflug der von irgendeiner neuen Ariane-Version war, Ariane 5, äh, Ariane oder Ariane, an der Ariane, glaube ich, fünf.

Ich glaube auch die Steuerungssoftware dafür ist auch in ADA geschrieben oder so.

Und die ist sogar bewiesen, dass die tatsächlich das tut, was an der Spezifikation steht.

Nur das Problem ist halt, sie haben irgendwie die falsche Spezifikation verwendet.

Es bald.

Nee, ja, die Spezifikation war halt für die alten Motoren irgendwie.

Und dann waren die Sensordaten für den Computer halt irgendwie so, nee, das kann nicht sein.

Aber es ist ja bewiesen, dass es richtig ist, daher muss sich defekt sein.

Dann hat sich der erste Steuerungskomputer ausgeschaltet und dann hat sich der zweite auch noch ausgeschaltet, der dann übernommen hat, und dann war halt Schluss.

Und dann ist die Rakete halt abgestürzt.

Und ja, das ist ja auch sowas.

Ich meine, klar, man kann halt beweisen manchmal, dass Programme das tun, was sie tun sollen, aber dann muss man ja immer noch sicher sein können, dass die Spezifikation richtig ist.

Aber wie, also irgendwie, man kommt da in so einen infiniten Regress und selbst das hilft einem nicht.

Das war jetzt ein Fall, wo ein Hardware-Update dazu geführt hat, dass das Ding nicht mehr lief.

Also keine Updates fahren, ne?

Wer Touch-Running System.

Aber auch in Python hat man ja nicht völlig verloren.

Also auch wenn Python solche strengen Garantien nicht so direkt hat, man kann natürlich Assertions einbauen und damit kann man so ein bisschen in die Richtung gehen, was Ada auch kann.

Wenn ich sage, ich baue hier eine Assertion ein und sage, okay, ich erwarte, dass die Eingabe nur so lang ist oder ich erwarte, wie du eben als Beispiel gebracht hast, Christian, dass halt nur irgendwelche bestimmten Zahlen davor kommen.

Das kann ich auch in Python machen.

Das geht, das macht den Code ein bisschen länger, da muss man sich ein paar Gedanken machen.

Aber das ist ja sicherlich auch ein Merkmal von qualitativem Code, dass man sich halt immer Gedanken macht, okay, was sind meine Eingangsbedingungen, was sind meine Bedingungen, die ich vielleicht rausgebe, dass ich auch schaue, okay, die Daten, die ich nochmal rausgebe, die kann ich in ein anderes Modul in meinem Programm, die kann ich auch nochmal validieren, dass da alles in Ordnung ist, dass das zum Beispiel irgendeinem Schema entspricht oder sowas.

Also das ist ja auch in Python nicht unmöglich.

Und es gibt natürlich auch in Python noch sehr viele andere Sachen im Rahmen eines sicheren Prozesses, die ich durchführen kann.

Also das beginnt ja bei ganz normalem Code-Review.

Da guckt halt jemand anders drauf und sagt halt vielleicht, okay, der Code sieht komisch aus.

Und dann kann ich halt sowohl Tests durchführen gegen den Source-Code, also dass ich mir den gesamten Source-Code nehme und ein automatisiertes Programm drüber laufen lasse, das mir halt sagt, okay, die Stelle sieht komisch aus.

Hier machst du wahrscheinlich eine SQL-Injection.

Oder in C einen Buffer-Overflow, das sieht irgendwie gefährlich aus.

Und dann kann ich natürlich auch sogenannte Blackbox-Tests fahren, wo ich sage, okay, ich starte meine Anwendung einfach mal und dann nehme ich mal so ein Hacker-Tool und das probiert einfach mal aus.

Kann ich hier komische Sachen eingeben und crashen in das Programm oder macht das Programm irgendwas komisches.

Also auch in Python ist das nicht verloren.

Da kann man auch sehr sichere Anwendungen schreiben, was meistens das gleiche ist wie eine gute Anwendung zu schreiben, weil die stürzt halt nicht ab und die kann auch mit allen Benutzerangaben umgehen.

Noch nicht mal nur von Angreifern, sondern auch von Benutzern.

Also ich hatte das beruflich auch so.

Wir haben, wir dachten erst, wir hätten einen Angreifer, weil uns unsere Anwendung abgestürzt ist, aber hat sich rausgestellt.

Wir hatten ein ähnliches Problem wie beim Buffer Overflow.

Wir hatten ein Datenbankfeld mit einer bestimmten Länge.

Und die Länge war aber in Bytes.

Und dann kamen halt User an und haben ihre kleine Tonifigur mit ganz viel Smileys genannt.

Und dann passte das nachher nicht.

Und führte zu einem Crash.

Und auf sowas kann man natürlich auch vorher darauf achten und entsprechend auch testen.

Das ist ja noch ein anderer sicherer, ein anderer Bestandteil eines sicheren Prozesses, dass ich sagen kann, ich schreibe vorher Tests und ich überlege mir entweder manuell oder sogar automatisiert, wie sehen komische Eingaben aus.

Bei Nummern sind das meistens null oder sehr kleine Zahlen oder sehr große Zahlen, typischerweise auch Zahlen, die vielleicht über die 32 Bytes hinausgehen, was in Python jetzt nicht so ein Problem ist oder über die 64, äh, äh, Bits, über die 64 Bits hinausgehen.

Also wenn ich da eine sehr große Zahl, wenn ich 2 hoch 64 plus 1 schreibe, dann in Python gar kein Problem.

Aber in vielen anderen Programmiersprachen führt das halt zu einem Absturz oder zu komischen Verhalten.

Und damit kann ich auch in Python, glaube ich, sehr gut Sicherheit sichern.

Also du wirst tatsächlich in solchen kritischen Fällen, wo du überlegst, ah, ich weiß nicht so genau, was bei rauskommt, Assertment-Statements in den Code schreiben einfach und dann sagen, Assertons should never happen oder sowas.

Und dann, wenn es fliegt, dann.

Genau, auch vielleicht auch testen.

Also bei dem Beispiel, was ich eben gebracht habe, wo die Nutzer Emojis eingegeben haben oder andere komische Unicode-Zeichen, haben wir halt einen Test gemacht.

Und dieser Test, also wir haben sowohl einen Unit-Test, der also ganz normal in der Anwendung läuft, wo wir halt mal ausprobieren, was passiert, wenn ich nur Emojis eingebe oder andere komische Strings.

Und wir haben aber auch einen End-to-end-Test, der das aus, der das gesamte System testet.

Also zum Beispiel hatten wir auch mal einen Bug, der das, ähm, der durch den Reverse-Proxy vor unserer Anwendung verursacht wurde, dass der halt Sachen falsch macht.

Und sowas kann man dann halt nicht so richtig testen.

Natürlich könnte man auch in Nginx sagen, ich schreibe eine Art Unit-Test für unsere Nginx-Konfiguration.

Aber da ist dann praktisch halt wirklich einen N-to-N-Test zu schreiben, der halt wirklich eine echte Anfrage gegen das echte System steckt oder gegen einen Prot.

Also da kann man sogar sein Production-System testen.

Aber natürlich testet man das im Normalfall zuerst gegen Development und sendet mal komische Anfragen und schaut, okay, geht das?

Kommen hier auch ordentlich Ergebnisse raus und meldet das System vielleicht auch hinten drum schon, dass irgendwas umgefallen ist.

Und das kann man halt damit schon ganz gut testen.

Ich finde es halt auch spannend aus der Perspektive von User lassen sich halt mehr Dinge einfallen, als man selber halt vorher konstruieren kann.

Tests sind an der Stelle immer natürlich auch super, weil man, wenn man im Hinterkopf behält, dass Tests halt eben nicht dafür da sind, Beweise zu ersetzen.

Also ja, sie sind sogar eine Annäherung eines Beweises, aber sie können halt nie alle Fälle abdecken.

Das geht halt schon in dem Moment schief, wenn du halt ein kontinuierliches Wertesystem hast an der Stelle.

Und was da halt interessanterweise zum Tragen kommt aus einer ganz anderen Ecke von Security, ich weiß gar nicht mehr, welches, welcher amerikanischen Militär das war.

Das kommt so aus dem Counter-Terrorism-Zeug.

Das ist Only Variety can match variety.

Also das Problem von Terrorismus ist halt, dass Terroristen extrem variierte Inputs, also Angriffe fahren.

Wirklich, die halt, also da geht es ja nicht um eine reguläre Kriegsführung nach irgendwie Genfer Konvention, sondern die machen Dinge, gerade weil sie verboten sind und weil keiner damit rechnet, an Stellen, wo keiner damit rechnet.

Und die Amerikaner haben halt irgendwann herausgefunden, wir können dem halt nicht mit herkömmlichen Maßnahmen, indem wir alle möglichen Fälle durchdeklinieren, entgegentreten, sondern du brauchst halt kognitive Diversität, um auf diese absurden Ideen zu kommen.

Du brauchst tatsächlich Leute, die unterschiedlich ticken.

Und ganz ehrlich, keiner von uns, wenn ich allein hier in die Runde gucke, wir haben halt vier mittelalte weiße Männer und die Diversität ist auf der Ebene halt auch kognitiv dadurch mit dem Bias belegt.

Keiner von uns kommt auf die Idee, in seinen Tests halt Katzen-Emojis in den Inputs zu tagen.

Das macht halt von uns keiner.

Und an der Stelle ist Security als Prozess halt tatsächlich auch von einer hohen Diversität, also braucht eine hohe Diversität, immer mit dem kleinen Zusatz von kognitive Diversität, die aber auch tatsächlich überlappt mit kultureller und persönlicher Erfahrung etc.

Um halt das erzeugt zu kriegen, dass man halt auf genügend Ideen kommt, die dann mal so eine Baseline herstellt von, okay, das ist jetzt hier nicht mehr scheiße.

Man kann sich, naja, das ist immer, ich finde das aus einem prozesshaften Ansatz gesehen und das ist halt das, wo ich dann, wenn Jochen, der halt sagt, Hilfe, ich will keinen Space Shuttle Coach schreiben, aber Leute, die halt besser differenzieren können zwischen, ja, wie gut oder schlecht ist es denn, versus ist es jetzt perfekt sicher oder ist es nicht perfekt sicher.

Weil das für, das kenne ich halt aus vielen, auch so Corporate-Umgebungen, wenn man Diskussionen führt, für die ist halt Sicherheit ein An- oder Ausknopf.

Entweder es ist sicher oder es ist nicht sicher, weil die müssen unter irgendeinem Produkt ihre Checkliste machen von ja, dieses Produkt ist sicher, deswegen dürfen wir es einsetzen.

Ja, da steht halt im Abrott die Lampe, wenn man ehrlich ist, ne?

Ja, ich hab, also ich habe halt schon Sachen gehabt, wo wir mit Institutionen aus dem Finanzumfeld, für die wir dann Sachen betreiben außerhalb der Kernrechenzentren, weil wir dann immer mit irgendwelchen jetzt so, oh, die Finanzwelt entdeckt, dass die Leute Apps wollen, aber nein, ihr dürft, die App darf nicht mit unserem Kernbanking-System reden.

Und dann sind wir da häufig so ein Layer dazwischen, wo wir sagen, okay, wir betreiben für euch diese ganzen APIs und machen da den Kran dazwischen, dann sind wir so diese Pufferzone.

Und wenn ich dann aber einen Excel-File kriege mit 5000 Einträgen, wo die ganzen Security-Anforderungen laut dieses Finanzinstituts drin sind, und ich dann in Zeile 2327 sage, ja, wenn ich jetzt die Cypher, die ihr da vorgebt, raus ins Internet lasse, dann ist es von heute auf morgen kaputt.

Weil ihr habt das letzte Mal vor drei Jahren eure Cypher-Liste aktualisiert und für eure Rechenzentren, wo kein Internet reinkommt, mag das jetzt alles okay sein.

Aber wenn ich damit jetzt halt raus ins Internet gehe, dann ist es halt kaputt.

Und jetzt musst du ihnen klar machen, naja, im Internet wird ständig alles angegriffen und du kannst jetzt nicht mit mir einen Vertrag schließen, wo du reinschreibst, welcher Cypher da aktuell da drinnen stehen soll, sondern du machst mit mir bitte einen Vertrag, wo du sagst, nach bestem Wissen und Gewissen haltet ihr euch informiert und kompetent und ihr aktualisiert das so, wie es halt nötig ist und jada, jada, jada.

Aber das war dann halt auch plötzlich ein Kampf, wo die da vorstanden und sagten, ich muss jetzt hier Siegel drauf machen, obwohl ich eigentlich in der Liste geschrieben habe, verstößt gegen unsere Sicherheitspolicy.

Ja.

Ja, stimmt, das ist ein großes Problem.

Das ist auch so ein Problem mit so Zertifizierungen, die man ja sonst vielleicht macht.

Wenn man jetzt irgendwie ein Auto fährt oder keine Ahnung, wo das eigentlich herkommt, Kirmes irgendwie Geräte hat, auf denen Leute rumfahren.

Dann kommt der TÜV und sagt halt, okay, ist noch nicht durchgerostet, alles klar, hier das Siegel.

Das geht halt bei Software nicht so gut, weil die muss man ja ändern und eigentlich braucht man dann eine neue Zertifizierung, aber das.

Ja genau, das wäre, ja könnte man jetzt denken, dass das die Lösung wäre, aber.

Ich hab das schon gemacht.

Ich habe schon einen Software ernsthaft.

Ja.

Ich habe 2000 oder 2004 haben wir damals mit Soap eine Common Criteria Zertifizierung gemacht.

Und das war so ein, das war so ein Challenge.

Da gab es einen Sponsor, der uns das bezahlt hat.

Und parallel dazu hatte damals Red Hat den J-Boss, glaube ich, durch eine Common Criteria gejagt.

Und wir hatten im Prinzip das gleiche Schutzniveau anzubieten.

Du hast das gerade irgendwie ein kryptische.

Ah, ja, ja, das ist, das ist, ich kann es nicht, ich kann auch nur die, glaube ich, die humoristische Variante irgendwie so.

Die unterste ist irgendwie, das Programm existiert, irgendwie, die nächste ist dann irgendwie, ja, das Programm existiert und es gibt Dokumentation dazu.

Dann die nächste ist irgendwie, jemand hat mal geguckt, ob die Dokumentation zum Programm passt und dann irgendwie, die nächste ist dann irgendwie, es existiert ein formaler Beweis, dass das Programm korrekt ist.

Ja, wo dann irgendwie so ein Zwischenschritt fehlt, das ist auch diese Stufe 6 oder weiß ich nicht genau.

Ja, ERP6 ist die formale Verifikation, genau.

Und ne, nee, wir hatten da schon ein relativ hohes Schutzniveau und die Common Criteria als Framework, um über Security nachzudenken, inhaltlich, ist toll.

Weil du kriegst halt einen Katalog von, also du hast zum einen einen Prozess, der dir sagt, okay, mach dir mal Gedanken über wer sind denn deine Assets, wer sind deine Angreifer, was haben die für Motivationen, was haben die für Ressourcen.

So, und jetzt gucken wir mal, wie mappen wir das alles aufeinander von, wie sind deine Assets mit was geschützt gegenüber welchen Angriffsszenarien, jadada yada.

Und die haben auch noch einen tollen Implementationskatalog, wo sie sagen, okay, also wenn du folgendes countern möchtest, könnte man zum Beispiel Logging machen.

Wenn du Logging machst, dann musst du dir über die Integrität vom Log Gedanken machen, dann musst du dir über Zeitstempel Gedanken machen, dann musst du, so und das ist sozusagen, das ist so ein bisschen, da kannst du bei so einem Spinnennetz irgendwie reingreifen, erstmal, was interessiert mich, und dann kommen alle Sachen hinterher, von die du noch berücksichtigen musst.

Das ist viel, aber es ist eigentlich erstmal auf der Ebene fachlich gar nicht schlecht gewesen.

Das große Problem ist, die Common Criteria kommt aus der Produktsicherheit.

Und die gehen halt davon aus, dass ein Produkt eben siehe ein Karussell auf dem Jahr markt, das Ding wird einmal gebaut und existiert jetzt, und jetzt ist das ab und jetzt läuft das 30 Jahre.

Wenn du aber so etwas wie ein Open Source Application Server hast, wo du exakt ein Release hast, wo du exakt ein Release einmal verifizieren darfst, und dann kommt aber in 23 Stunden das nächste raus und du fängst die ganze Zertifizierung wieder von vorne an, das geht dann halt schief.

Ja, also man muss ja die Zertifizierung erstmal, also es kann manchmal sehr gut sein, dass man sich halt über alle Sachen Gedanken macht, aber man kann ja auch ganz viele Sachen vermissen.

Also ich glaube, der viel besser oder für viele Anwendungen besser ist es, wenn man sagt, ich mache einen Pentest, also ich einen Auftrag geben.

Bei einem Pentest geht halt jemand anders hin und sagt, ich checke deine Software.

Also entweder checke ich die von außen oder ich schaue mir den SourceCode an, ich schaue mir das mal an, was du so in Python oder auch in anderen Programmiersprachen alles programmiert hast.

Und da sind dann halt erfahrene Entwickler in der genau der Programmiersprache.

Und die können halt schon, vielleicht auch mit automatischen Tools, sehr schnell kritische Stellen finden.

Also damit habe ich auch gute Erfahrungen gemacht.

Das ist natürlich ein ganz anderer Herangehensweise, dass man sagt, okay, ich versuche nicht alles irgendwie, den ganzen Prozess, ich schreibe kein Papier, sondern ich lasse im Wesentlichen Leute anfangen und zu coden.

Und das muss man natürlich auch regelmäßig wiederholen.

Das bringt natürlich nichts, wenn man vor zehn Jahren das mal gemacht hat.

Aber das ist auch sicherlich eine Methode, mit der man seine Anwendungen gut absichern kann.

Also den Angreifer Hut aufsetzen und da draufhauen, solange bis auseinanderfällt.

Da braucht man halt gute Angreifer auch, die so ein bisschen Patricks kennen.

Und ich glaube, wenn man jetzt nur so Tools drauf loslässt, dann weiß ich nicht.

Genau, also wenn man nur ein Tool selber drauf loslässt, hilft es wahrscheinlich nicht, aber wenn man halt jemanden beauftragt, der da wirklich Experte ist, ich glaube, das ist eine ganz gute Möglichkeit, um auf so einen Blick zu bekommen, wie schlimm ist denn mit unserer Anwendung?

Haben wir nur eine ganz kleine Schwachstelle oder ist uns unsere Admin-Oberfläche ohne Benutzername und Passwort irgendwie verfügbar und man kann einen beliebigen Code hochladen.

Und ich glaube, das ist noch ein bisschen eine andere Herangehensweise, aber ich glaube, das ist oftmals effektiver, vor allem für so kleinere Projekte.

Wenn man natürlich eine Zertifizierung braucht, dann braucht man sie.

Aber ich weiß nicht, ob das immer auch wirklich zu Sicherheit führt, wenn ich nur ganz viel Papier schreibe.

Also ich würde an der Stelle halt eine Lanze verbrechen für das, was wir jetzt zu Corona-Zeiten kennengelernt haben, als irgendwie Schweizer Käsemodell.

Du kannst halt, also für alle, die das noch nicht gehört hatten, ist sozusagen die ganzen Maßnahmen, alle Anti-Corona-Maßnahmen sind für sich genommen natürlich durchlöchert, wie so ein Schweizer Käse.

Aber wenn ich halt fünf Scheiben Schweizer Käse hintereinander lege, ist die Filtrationsrate dann doch relativ gut.

Dass also wirklich über fünf Schichten an der gleichen Stelle überall die Löcher sind, das passiert halt normalerweise nicht.

Und deswegen würde ich halt immer, also aus meiner dann längerfristigen Erfahrung, würde ich halt sagen, je nachdem, es kommt immer auf den Kontext drauf an, man muss immer erstmal gucken, was sind hier eigentlich die Assets gerade.

Und wenn ich gerade hier in meinem Heimkeller irgendwie die Temperaturdaten von meinem Haus aufschreibe, denke ich mir so, ja, egal.

Dann darf es halt auch mal, wenn ich für mich entschieden habe, die dürfen auch ins Internet putzeln, dann ist schon okay.

Aber tatsächlich diese Layer zu haben, auf der einen Seite Produktsicherheit tatsächlich sich anzugucken mit den, was sind hier eigentlich die technischen Maßnahmen und sowas wie eine Common Criteria im Hinterkopf zu haben, ist für mich inzwischen eher das Know-how, von das setze ich ein, während ich ein System aufbaue, um sozusagen schon vorher zu wissen, okay, wo ist denn die Checkliste, wo ich dann weiß, jetzt bin ich, jetzt habe ich wenigstens nichts unnütz vergessen.

Während dann halt das Thema ist halt auch jemanden zum Beispiel vom Pentest, da würde ich auch sagen, einige Leute, mit denen ich mich dann austausche, sagen, nee, dann machst du halt lieber auch noch gleichzeitig sozusagen eine externe Code-Revie, die sozusagen über das, was ich überhaupt halt dann nochmal Whitebox drüber guckst und dann kannst du nochmal von draußen draufhauen und diese ganzen Schichten ergeben dann halt.

Und gleichzeitig kannst du dann an vielen Stellen ja auch, wenn man standardisierte Protokolle wie halt HTTP immer so dazwischen hat, dann gibt es da ja auch noch die Möglichkeit, immer nochmal so Schichten einzuziehen wie eine Web Application Firewall, die einem so bestimmte Sachen bestimmte Sachen schon mal wegfängt.

Also ich habe zum Beispiel ein paar Kunden, den gucke ich über die Schulter und da weiß ich dann so, okay, bei dir knalle ich da jetzt eine Waffe davor, weil ansonsten traue ich mich nicht, das ins Netz rauszulassen.

Du sagst mir, es muss raus ins Netz.

Das ist das gleiche Prinzip wie ein Virenscanner.

Also da habe ich irgendwie ein Muster, das ich suche bei einer Waffe.

Genau, ja.

Ich sage, okay, wenn ich das Muster finde, dann mache ich irgendwas, dann unterbinde ich die Anfrage oder schmeiße das Muster raus oder mach irgendwas.

Genau.

Das heißt, das ist, das hatte ich schon ein bisschen gefährlich, weil also eine Möglichkeit ist halt schon wie bei einem Virenscanner, dass der, also die Wald- und Wiesen-Attacken findet ihr sicherlich.

So was im Internet das Grundrauschen ist, das findest du auf jeden Fall.

Aber wenn dann wirklich jemand deine Firma angreifen will, dann wäre es dich da vielleicht auf in falscher Sicherheit.

Weil man halt doch immer.

Also du hast recht, mit dem Schweizer Käsemodell, das macht es vielleicht ein bisschen besser, aber gleichzeitig kann ja so ein WAF auch wieder ein Angriffsmodell sein, weil der muss ja auch wieder alles interpretieren.

Und ein Problem kann halt sein, dass mein Server davor und mein Server danach sowieso schon unterschiedliche Details anders interpretieren.

Also bei HTTP zum Beispiel Chunk Encoding oder irgendwelche komischen HTTPS-Optionen anders interpretieren und dass dann die Waff sogar noch ein neues Problem aufmacht, dass sie plötzlich Sachen anders interpretiert und dann vielleicht sogar eine Schwachstelle an sich hat.

Also auch die WAS ist ja ein Code.

Nee, genau, deswegen ist es auch für uns zum Beispiel keine Maßnahme, die wir halt so blanko überall drüber gießen.

Sondern das ist halt, wir haben halt dann Kunden, wo feststellen, also die Waffe ist für uns mehr oder weniger dann der erste Move, also manchmal, wie du sagst, will irgendwer einfach in seiner Ausschreibung sehen, da muss eine Waffe davor.

Dacke ich da eine Waffe davor.

Und wenn, das muss er ja anbieten können erstmal in dem Moment, wenn er das fragt.

Und wenn der dann irgendwie nach zwei Monaten fragt mit, warum ist das hier alles so doof, dann sage ich ja, du wolltest eine Waffe haben, dann sagt er mir ja, jetzt machst du wieder aus, dann mache ich es dann wieder aus.

Der, wo wir es häufiger als Werkzeug tatsächlich sehen, ist, dass tatsächlich diese Wald- und Wiesen-Scans und Angriffe gerne mal massiv für Last sorgen.

Und das ist halt, also wir sehen immer wieder Anwendungen, wo Leute mit SQL-Injection versuchen, quer über so eine Anwendung drüber gießen und die Anwendung dadurch in Performance-Probleme gerät.

Und das ist halt tatsächlich, was das Filtern wird dann damit zum Beispiel vorneweg.

Also jetzt hier haben wir den ganzen SQL-Kram, das hat da nichts drin zu suchen, zack, weg, raus.

Ah, okay.

Ja, ja, aber ich, genau, also das, ich habe auch schon mal von jemandem gehört, der so Pantests macht, dass er meinte, so ja, da war eine Bank, die hatte irgendwie ein System vor den Datenbanken und das sollte eigentlich aus dem SQL irgendwie alles rausfiltern, was und das hat dazu geführt, dass SQL-Injection wieder möglich wurde, weil es halt Dinge zu viel rausgenommen hatte.

Du hast ja ein Kombinator, also aus Komplexitätsperspektive hast du immer das Problem der Kombinatorik.

Das heißt, wenn du N Dinge hast, die miteinander reden, dann hast du halt N Quadratverbindungen mindestens.

Und wenn du jetzt sagst, okay, das ist mir zu unsicher, ich pack noch eins davor,

dann hast du noch mehr.

Das Problem ist, glaube ich, an der Stelle auch, wer halt irgendwie diese Architektur entscheidet und so und wem man da vertrauen kann.

Gerade wenn Leuten, die jetzt keine Ahnung haben von Sicherheit oder von Computern allgemein, aber irgendwie Software als Manager irgendwie bestellen wollen, die haben ja eine unheimliche Asymmetrie gegenüber denen auch Entwicklern und so.

Und die müssen halt vertrauen auf das, was denen da erzählt wird.

Und die stellen sich dann meistens so ein Sammelsurium an, weiß ich, Angebot und Nachfrage oder Best Practice oder irgendwas, was die halt dann Informationen saugen können, zusammen.

Und das ist ja auch schon so eine Art Baukasten und das ist ja nie ganzheitlich irgendwie gedacht.

Was wird ja auch immer dann teuer und so, muss ja auch dann wieder sparen und wenn man das dann rauslässt, dann ist ja klar, dass es ja Fehler sind ja völlig vorprogrammiert.

Und sich da richtig vor zu schützen, ist fast eine unmögliche Aufgabe.

Und die Frage wäre vielleicht, wie man solchen Menschen auch eine Möglichkeit geben kann, Systeme in sicherer zu denken.

Also ich hatte jetzt gesagt, so Prozesse von Anfang an so ein bisschen, ich denke, das würde ja wirklich bedeuten, dass man sich, bevor man damit anfängt, mit einem Systemarchitekten oder sowas intensiv auseinandersetzen muss, welche Text-Stacks man benutzt oder sowas oder wie der Prozess halt aussehen muss und wo man Sicherheits- ja, was ist das, Netze einzieht oder.

Ja, die Frage ist halt, welche Angriffsmöglichkeiten man irgendwie zur Verfügung stellen möchte.

Da gibt es ja unzähliges ja nicht immer nur so diese Website, die nach außen dann da das Aushängeschild ist, wo man dann draufhauen kann.

Ja, die versuchen sicherlich groß sicherheit sozusagen als Feature, als Draufklopf einzukaufen, also man hat ein riesiges System, was aktuell existiert, was in Wirklichkeit wahnsinnig unsicher ist und dass man sagt, okay, ich mache jetzt einfach, ich kaufe jetzt eine Waffe oder irgendwas anderes, mach einmal einen Pentest oder mach eine Sache und hoffe dann, dass das damit okay ist, dass ich Sicherheit dazu kaufen kann.

Ich glaube, es ist viel, es entsteht viel bessere Software, nicht nur sichere, sondern auch bugfreiere Software, wenn man die gesamte Software direkt so anlegt, dass man sagt, okay, bei der Produktion der Software, ich mache mir vielleicht vorher Gedanken.

Ich würde nicht mal sagen, viel über die eigentlichen Zertifizierungen oder die Prozesse, sondern vielleicht mehr, wie lasse ich die entwickeln.

Wie sorge ich dafür, dass das, wie gesagt, wie ich eben erwähnt hatte, Code Review, also wie sorge ich dafür, dass das halt schon bei der Entwicklung direkt die Software sicher ist, weil nachher das draufzubauen, ist immer schwieriger.

Also nachher mit dem Scanner zu suchen, ist, glaube ich, schwieriger als zu sagen, okay, ich habe Entwickler, die sich direkt drüber Gedanken machen und.

Das ist ja zum Beispiel total kaputt.

Also, ich hatte jetzt irgendwie mal so die Situation, dass so ein Konzern da war, die wollten dann Software bereitstellen und dann haben sie gesagt so, nee, aber neue Software ist irgendwie komisch, wir wollen die alle auditieren vorher, so persönlich, also als Security-Team, und haben dann so ein Service dann rausgebracht, dann jetzt im November.

Und da war dann Django 1.10.4, weil das dann die sichere Version war.

Das ist also LTS war 1.11 für alle, die es noch wissen.

Das ist halt schon ein altes System.

Und da gibt es halt dann irgendwie schon jede Menge irgendwie Exploits, wenn man irgendwie genug nachsucht, die irgendwo drinstehen.

Und das wird dann von den Leuten irgendwie geauditet und man fragt sich halt, okay, was machen die denn da eigentlich?

So, warum tun die das?

Und das ist halt vielleicht so ein, ja, das kriegt man glaube ich gar nicht so gut.

Das ist halt wieder der Griff in Richtung Product Security statt Process Security.

Die, also ein prozesshafter Ansatz, und wir haben jetzt ja auch seit anderthalb Jahren, seit doch seit ein bisschen mehr als anderthalb Jahren machen wir bei uns ISO 27.000.

Und der Trick ist halt bei vielen, die prozesshaften Security-Sachen werden häufig missverstanden, weil die Standards, die es dazu gibt, wie eine Keule aussehen, obwohl sie eigentlich gar nicht so schlimm sind.

Man muss da bloß, wenn man die Standards interpretiert, immer unterscheiden zwischen, was fordert der Standard formal und was ist im nächsten Satz schon nur noch die Implementationsguideline, wo man dann eigentlich selber Hoheit hat.

Also ich habe halt auch jemanden, der meinte, na, ISO 27.000, seitdem müssen wir sämtliche Stromkabel einmal im Jahr irgendwie auf die Erdung prüfen.

Also, äh, nee, musst du nicht, ich habe auch eine 27.000, aber dann müsst ihr das doch auch mal so.

Nee, müssen wir nicht.

Ja, aber, aber, ja, nee, müssen wir nicht.

Und dann dreht man so eine Schleife mit, naja, die ISO sagt, du musst dich halt um die für dich relevanten Normen und Vorschriften kümmern.

Das sagt die ISO 27.000.

Also macht man das.

Und die sagt aber auch, du musst sie bewerten und musst dann Schlussfolgerungen für dich da draus ziehen.

Und es ist völlig legitim, im Rahmen der ISO zu sagen, ja, wir haben zur Kenntnis genommen, dass ortsveränderliche elektrische Verbraucher irgendwie alle zwei Jahre auf X geprüft werden müssen.

Machen wir nicht.

Aber jetzt kann ich euch mal erklären, was für eine Lücke das offen lassen könnte, warum man das testen wollen möchte.

So, naja, ISO als Prozess, die ISO als Informationssicherheitsprozess ist extrem umfassend und zwingt dich dazu, den kompletten Wertschöpfungsprozess von einem IT-System zu betrachten.

Da gehört halt dann unter anderem auch dazu, dass du eben rechtliche Rahmenbedingungen bewertest etc., weil du musst am Ende immer für alle deine Assets, und Philipp hat das halt schon, die vier Grundsicherheitsaspekte, also bei uns sind sie aufgeschluss, manchmal wären es drei, manchmal wären es vier, halt nach Vertraulichkeit, Confidentiality, nach Integrität, Integrity, nach Authentizität und nach Availability zu schützen.

Und was hat das jetzt damit zu tun, dass da so ein Stromkabel ist, in das sich.

Ja, Strom ist zum Beispiel für die Availability relativ sicher, relativ wichtig.

Okay, also Availability, okay.

Und du misst halt dann da quasi nur die Stromleitung, um zu testen, ob das Ding irgendwann mal ausfällt.

Naja, es gibt eine, es ist halt eine deutsche Norm, die kommt aus dem, ich weiß nicht welches ist, die schreibt halt vor, dass halt alle ortsveränderlichen Verbraucher auf Fehlerströme zu prüfen sind, alle zwei Jahre.

Und wenn die ISO halt sagt, du musst halt alle für dich gültigen Rechtsnormen berücksichtigen und überwachen etc., dann schlägt sowas halt auch zu.

Was die Leute aber eben häufig missverstehen, ist, dass in der ISO drin steht, du sollst es bewerten.

Und du sollst für dich daraus ableiten, ob das jetzt, was relevant ist oder nicht.

Du kannst als Geschäftsführer oder als CISO an der Stelle immer sagen, okay, ich habe da fünf Risiken gesehen, ich akzeptiere die.

Jetzt hast du aber meine Story kaputt gemacht.

Ich wollte eigentlich die Story hören, wie man durch das Stromkabel in den Rechner des Teamus einringt.

Stromkabel, also das kann zum Beispiel passieren, wenn du deinen Prozess so aufstellst und sagst, naja, Stromkabel sind für uns keine sicherheitsrelevanten Dinge.

Deswegen kaufen wir die aus der Grabbelkiste beim Euroshop nebenan.

So.

Und das heißt, dann verkaufen die dir plötzlich Enmas Dinge, wo sie wissen, in einem halben Jahr geht da drinnen irgendwas kaputt und dann geht bei dir im Rechenzentrum mit einem Mal das Licht aus und dann ist deine Verfügbarkeit hin.

Und weil dein Redundanzkonzept natürlich davon ausging, dass dir niemand so ein Ding untergejubelt hat mit der Absicht, dass da ein kleiner Sollbruchkondensator oder irgendwas drin ist, der dann halt in nach so und so viel schönen Laufzeit einfach eine Schmelzsicherung durchgehen lässt.

Also das geht jetzt, glaube ich, auch erstmal nur relevant für so Atomkraftwerke oder sowas, die halt dann vernünftige Kühlung brauchen.

Nein, das kommt auf deine, das kommt auf deine Angreifer und die Motivation der Angreifer drauf an.

Also die Story da drum wäre zum Beispiel, jemand zu sagen, wir betreiben Dienst, wir betreiben Dienste sehr, sehr lange, teilweise 10, 15 Jahren länger.

Das heißt, wenn ich, und auch teilweise mit politischem Impact, also wir haben ein paar Systeme, die sind unter anderem zu uns gewandert, extra aus Amerika raus, von Non-Profits, die unter anderem im Nahen Osten halt aktiv sind.

Und die haben ein massives Sicherheitsbedürfnis um das Leben derer, deren Daten in dem Ding drin stehen, weil da halt Decknamen unserem Zeug auftauchen.

Und die wenn du dann halt sagst, naja, wenn da jemand ein richtiges Long Game spielt und sagt, ich habe hier drei Jahre Zeit, das ist nicht das Problem.

Ich will aber, dass diese NGO mal so richtig gegen die Wand fährt, dann fahre ich jetzt die Lücke und sage, aha, ich habe herausgefunden, deren Hoster kauft immer irgendwie aus der Grabbelkiste die Stromkabel.

Das dauert jetzt, naja, der tauscht nur so und so oft die Stromkabel aus.

Aber wenn ich schaffe, irgendwie ein Drittel seiner Stromkabel durch meine mit dieser Schmelzsicherung zu ersetzen, dann bin ich in drei Jahren so weit, dass dann irgendwie bei dem das RZ implodiert.

Das ist sozusagen die, und da muss man immer aufpassen.

Da kommt dieser, welcher XKCD ist das mit der hohen Verschlüsselung und dem der 5 Dollar Entschlüsselungsmaschine.

XKCD, bitte nochmal einmal.

XKCD, Comic.

Da gibt es

wo die Idee ist, dass du eine ganz, ganz teure Verschlüsselung kaufen kannst, mit super zertifiziert.

Und dann kommt aber jemand zu deinem Admin mit einem 5 Dollar Baseball-Schläger und bedroht ihn dann und sagt, okay, gib mir das Passwort, wenn du das für nicht gibst, dann haue ich dich mit dem Schläger und dann bringt dir die beste Zertifizierung und die beste Sicherheit nichts.

Ja, tatsächlich, ja.

Und man sagt halt auch an der Stelle, weil häufig, also wenn du jetzt halt gerade dieses Thema Advanced Persistent Threat, also die typischerweise staatlich finanzierte Organisation oder Teams, die irgendwo reingehen sollen, man sagt halt auch so schön, gegen den Mossad schützt du dich nicht.

Weil den Mossad interessiert nicht, was du für Security irgendwo in deinem EZ hast.

Der kommt zu dir nach Hause und nimmt dich mit, und dann reden wir nochmal.

So, deswegen ist, wenn man das mal schluckt und sagt, okay, ich bin hier nicht der, der sich gegen den Mossad schützen muss, weil ich habe eh keine Chance.

Dann brauche ich aber auch nicht so, dann brauche ich aber auch nicht so tun, als wenn ich sozusagen alles auf dem Niveau machen müsste.

Oder du brauchst einen eigenen Geheimdienst.

Bitte?

Oder du brauchst einen eigenen Geheimdienst.

Ja, genau.

Aber das Fiese am Internet ist ja, dass du immer mit den besten Angreifern kommunizierst.

Das heißt, vielleicht nicht mit dem Mossad, aber vielleicht hast du irgendwelche russische Hacker, die durchaus was drauf haben.

Und die installieren dann halt, wie hier in der Uniklinik Düsseldorf, deine Rennsomra und die wollen halt, die sind auch fast auf dem Level von so einem Advanced Places Thread.

Die haben vielleicht jetzt nicht so, also die machen schon ein bisschen Streufeuer, aber die haben durchaus das technische Know-how und auch die Zeit und die machen sich auch die Mühe, das an deine Architektur anzupassen.

Also vielleicht nochmal kurz ohne Düsseldorf, da gab es einen Vorfall, da sind die Server rausgefallen und da das Netzwerk intern nicht geordnet war, konnte man durch den einen befallenen Rechner irgendwie mehrere OP-Säle ausknipsen, irgendwie, wenn ich das richtig verstanden habe.

Ja, ich weiß nicht genau, was da passiert ist, aber war es

nicht verfolgt, muss ich zugeben.

War aber auch, glaube ich, nicht der erste Fall in Deutschland und ich glaube, die hat es auch ein paar Mal so richtig erwischt.

Nee, natürlich, also das ist halt ja jetzt erstmal die Moss-Hard-Beispiele kommen immer zu dem Thema, wenn man anfängt, die Physical Security halt extrem stark zu übertreiben.

Und das ist aber dummerweise auch das, wo Leute gerne übertreiben, weil das können sie sich bildlich vorstellen.

Dann kommt halt immer noch ein, ja, warum ist denn hier vom EZ keine Panzersperre und alle nur, ja.

Denk dran, Panzersperre hilft dir nichts, weil in Deutschland hat die Feuerwehr.

Guck mal da draußen, siehst du diesen kleinen, unaufälligen grauen Kasten?

Da ist der Generalschlüssel für das ganze Haus drin.

Ja, wie?

Na, das ist der Feuerwehrschlüsselkasten.

Da gibt es einen Feuerwehrschlüssel, den hat die Feuerwehr, die kann das Ding aufschließen, die kommt hier rein.

Also spar dir mal bitte deine Panzersperre.

Also deswegen, das ist immer so dieses für mich bloß abzugrenzen von, wenn du das Niveau hast, musst du dir nochmal um ganz andere Sachen Gedanken machen.

Und wenn man das aber mal so übertrieben hat, dann wird den Leuten schnell klar, dass Security halt in eine Abwägung ist und eine kontextspezifische Abwägung und immer nur auf 100% zu schalten, geht halt nicht.

Und damit macht man auch mehr kaputt.

Ich würde halt nochmal anknüpfen an den Punkt von dieser Prozessempfehlung, ich würde halt immer versuchen, an allen Enden weniger ist mehr zu machen.

Weniger Code, den du schreibst, ist typischerweise weniger Architektur, über die du nachdenken musst, ist weniger, und damit auch ein Team, was gerade erst anfängt, würde ich eben nicht sagen, ihr fangt jetzt mal an, euch über Security-Gedanken zu machen.

Auch bei uns in der ISO ist es halt, in unserer Umsetzung der ISO 27.000 ist es halt auch so, dass wir sagen, du willst irgendwie ein neues Feature für die Plattform etc.

entwickeln, ja, mach halt.

Ja, mach halt.

Ja, und du kannst gerne auch irgendwie deine drei, vier Testmaschinen auf der Plattform halt schon mal auf diese Branch umstellen.

Habe ich kein Problem mit.

Aber bevor das dann halt in den großen Einsatz kommt, muss das halt mal durch eine vier Augen-Revie durch.

Dann musst du mal irgendwem anders erklärt haben, was du dir gedacht hast.

Und dann gibt es dort eine Checkliste und die fragt, jetzt erklär mir mal, was du dir zur Security für Gedanken gemacht hast.

Und das ist im Prinzip der, das ist bei uns der komplette formale Prozess für die Entwicklungssicherheit.

Also übertrieben jetzt ein bisschen, aber im Prinzip ist sozusagen bei uns nur ein, ja komm, entwickel halt, da drüben sind die zehn Guidelines, was man in welchen Situationen so alles mal berücksichtigen könnte.

Und aber das Einzige, wozu wir dich zwingen, ist, du musst in dem Pull Request, wo dein Feature in die General Availability geht, musst du mir oder deinem PR-Reviewer glaubhaft vermitteln, dass du dir jetzt wirklich adäquat zu dem Ding Gedanken gemacht hast.

Schreibt man das alles dann als Text in den Pull-Request?

Als Text in den Pull-Request rein.

Da gibt es zwei Fragen.

Das eine ist, was sind hier die Sicherheitsanforderungen?

Und B, wie habt ihr die erfüllt?

Wo ist hier der Nachweis, dass die erfüllt wurden?

Wie seid ihr zu der Frage gekommen von, was sind hier die relevanten Sicherheitsanforderungen?

Und wie weiß ihr nach, dass ihr das jetzt halt ordentlich umgesetzt habt?

Das hört sich so ein bisschen an, als sollte man die Angst weglassen und tatsächlich nur, also die Worst-Case-Szenarien, also was ist das Schlimmste, was passieren kann?

Also bei dir wären zum Beispiel jetzt Daten weg gewesen, das wäre nicht so gut gewesen, weil die so sehr privat sein müssen.

Und an anderer Stelle ist es vielleicht so, ja, okay, wenn man die Backups noch hat, dann ist halt nicht so schlimm.

Und das ist halt dann vielleicht der Worst Case und da muss man sich halt Gedanken drüber machen, dass der nicht eintreten kann.

Und der Rest ist dann egal.

Also auch bei uns ist es so, unser Auditor zum Beispiel sagt halt auch immer, ein Unternehmen, was hochsicher ist und aber am Markt kein Produkt platzieren kann, hilft halt nicht.

Es geht halt nicht.

Und dieses Angstthema ist da schon relevant, weil halt Angst ist, häufig wird Security, gerade wenn es eine eigene Abteilung ist, immer wahrgenommen, als das sind halt die, die halt nachher unterschrieben haben sollen mit, hier ist alles sicher.

Und deswegen sagen sie per Default einfach nein.

Und für uns ist der Review-Prozess aber zum Beispiel auch umgedreht.

Der Review-Prozess in einem PR bei uns ist halt immer nur ein Ja, man darf nicht alleine Zeug nach draußen prügeln.

Sternchen Fußnote, doch, es gibt Situationen, in denen man das darf, aber dann muss man noch mehr Dinge beachten.

Weil es gibt halt bei uns auch so Gefahren im Verzugssituationen, dann muss ich handlungsfähig sein.

Aber der Pull Request ist halt, wenn er gemerged wird, ist das halt nicht die Aussage von dem Reviewer, dass er seinen Erstgeborenen irgendwie mit Blut unterschrieben dem Teufel überantwortet, dass er sagt, hier ist alles sicher.

Sondern der vier Augen-Prozess ist dafür da, dass ein zweiter Mensch dem ersten nochmal in die Augen guckt und sagt, also wenn du jetzt nicht noch sagst, ich soll nach irgendwas schauen, dann merge ich den Kram jetzt.

Das ist aber dein Code, den ich jetzt gleich merge.

Und das ist ganz spannend, weil das ist ein kognitiver Prozess, der halt einer Person, einen anderen Menschen, und da gehört Empathie eben mit dazu, gegenüberstellt und sagt, ich lasse das hier raus.

Du hast jetzt gerade gesagt, du sagst mir, das ist das Beste an Arbeit, was du abzuliefern hast, und ich gucke mit dir nochmal gemeinsam drüber, aber ich werde es nicht aufhalten.

Ich bin hier nur der, der deinem Gewissen nochmal auf die Sprünge hilft, zu sagen, na, hast du nicht doch abgekürzt?

Bist du dir wirklich sicher, ich lass das jetzt raus.

Und das macht einen ganz massiven Unterschied, weil dann was passiert, die Änderungseinheiten werden kleiner.

Klassisches, agiles Thema, weil die Leute nicht mehr sagen, oh Gott, oh Gott, oh Gott, der Review-Prozess ist so aufwendig, dann muss er sich aber auch lohnen, sondern wir drehen es halt um und sagen, nee, der Review-Prozess ist erstmal freundlich und der Default ist, wir gucken da zusammen drüber und alle machen ihre Arbeit und reden drüber und klären das.

Und dann lassen wir es auch raus und dann ist der in fünf Minuten erledigt.

Also wenn ich halt zum Beispiel nur, weiß ich, ein Pull-Request bei uns kann sein, Paket-Update vom Nginx, weil war ein CVE drin, kommt die nächste Minor-Version.

CVE ist.

Ja, genau, also war eine Vulnerability, die bekannt war, die haben ein Patch bereitgestellt, wir spielen den Patch ein.

Dann ist der Div bei uns auf der Plattform typischerweise so zwei Zeilen lang.

Also irgendwie Version vom Nginx hochgedreht und den Hash halt angepasst.

Und die Review dazu sieht dann so aus.

Ja, ne?

Machen wir, oder?

Ja.

Was war da noch drin in der Änderung?

Ja, nichts war, nur der CVE.

Und beim Ngin X?

Ja, auch nur der CVE.

Ja, gut, okay, was waren hier die Anforderungen?

Anforderungen war, wir müssen Updates machen, weil wir die Sicherheit aufrechterhalten sollen.

Nachweis, naja, das ist jetzt die alte Version war die, die neue ist die, zack, fertig, raus damit.

Ende.

That's it.

Das ist das halt den Leuten in den Prozessen das so an die Hand zu geben, dass sie nicht jedes Mal vor so einer Checkliste stehen, von du musst jetzt aber, um halt, damit dir nachher keiner den Kopf abbeißt, weil das ist ja dann alles immer nur noch Ass-Covering, dass niemandem die Schuld zugeschoben werden kann.

Und das ist ja nicht der Prozess, um den es geht, sondern der Prozess ist, dass Leute produktiv arbeiten können und während dieser Arbeit der Vektor der Änderung immer heißt, na mit jeder Änderung machen wir es erstmal potenziell sicherer und nicht unsicherer.

Und wenn man dann sagt, okay, wenn ich das für alle Änderungen sicherstellen kann, dass alle Änderungen die richtigen Vektor haben, ja, dann mache ich doch einfach mehr Änderungen und werde halt immer sicherer.

Ja.

Ja, das ist interessant.

Also was mir da gerade noch als Idee kommt, es gibt da eigentlich ein Problem bei dieser Sache mit den quasi Pull-Requests.

Wenn das jetzt nicht in so einer Firma ist, wo alle Leute da Ahnung haben von dem, was sie tun, sondern wieder den nicht ganz optimalen Fall angenommen, dann kann sich jedem jemand hinstellen, kann sagen, er ist jetzt hier der Türsteher und der guckt sich das alles an.

Und dann hat er eine Existenzberechtigung, obwohl er eigentlich sonst gar nichts tun muss.

Und das kann dann sehr, ja, es ist so ein bisschen an dieser Informationsasymmetrie dann ausnutzen.

Für mich

regelt das der Wettbewerb.

Eine Firma, die so drauf ist, wird halt Schwierigkeiten haben, wirklich innovativ nach vorne zu laufen.

Was ich halt noch spannend finde, ist, dass Python natürlich, um mal die Schleife jetzt noch zu ziehen, auch als Sprache natürlich ein gutes Standing hat.

Ich hatte vorhin nochmal irgendwie durchgeguckt und wenn man halt guckt, wenn ich, wir könnten jetzt sozusagen, also der völlige Tiefschlag ist natürlich, wenn ich es gegen PHP vergleiche.

Da habe ich halt das Problem, dass allein die Laufzeitumgebung von PHP und die Sprache selber, ich habe vorhin geguckt, über die letzten 20 Jahre über 600 CVEs eingesammelt haben.

Und die machen im Prinzip in einigen Jahren das Fünffache von dem, was Python über die letzten 20 Jahre insgesamt hat.

Also bei Python kamen irgendwie 20 CVEs oder sowas raus über die letzten 20 Jahre.

Viel mehr kommt da einfach nicht.

Und das ist halt auch schon mal was, wo man immer sagen kann, okay, das ist was.

Auf der einen Seite die Sprache selber hat viele Probleme nicht, sowas wie ein Buffer Overflow zum Beispiel.

Kannst du mit Python erstmal so nicht erzeugen.

Und es ist auch in der Community ja so verankert, dass extrem viele Bibliotheken, viele Frameworks das ja auch als Thema für sich erklärt haben und eben sagen, wir basteln nicht nur um Security-Probleme rum, sondern versuchen sie dann ordentlich zu fixen.

Und es gab auch in Python selber, also die Sachen, die es gab, wenn ich halt schaue, das war mal irgendwann ein LibXML-Thema, weil du halt zum Beispiel LibXML über, wie war das externes Auflösen von Entities dann irgendwie Code ausführen konntest und so ein Kram.

Aber die wurden halt in der Community immer sehr differenziert und schnell diskutiert und auch adäquat behoben.

Da habe ich einfach eine völlig andere Basis, von der ich ausgehe, als wenn ich praktisch bei jeder Code-Zeile, die ich schreibe, da denke ich dann eher so an C, tatsächlich meinen Doktorkittel angezogen haben muss, um ja nicht daneben zu tappen.

Ja, dann glaube ich sowas wie Rust auch deswegen bekommen, oder?

Weil das genau das dann wieder anders macht und in den Griff kriegt, ja.

Ja, ja, also Rust ist auf jeden Fall, also ich meine, es kommt halt drauf an, was man, was man jetzt, ich glaube eben vor Buffer Overflows, so muss man gar nicht so viel Angst haben, aber wenn man jetzt Server betreibt, die halt super viele Requests bearbeiten oder so, was hat letztens in einem Podcast irgendwie der, der Entwickler von Fluss, der Armin Ronnacher, gesagt, meinte so, Rust ist halt für ihn schon allein deswegen so viel netter, weil Python hätte er ja auch irgendwie sehr

gern gemacht, aber das liegt halt wie Sau.

Das ist halt, da kann man, man kann nicht viel dran machen und das ist natürlich schon irgendwie so, ja.

Das ist, ähm.

Das würde ich gern verstehen, weil da geht mir Philipp dreht den Kopf und ich habe auch so ein kleines Messer, was mir in der Tasche aufgeht.

Ja, ja, klar, also es ist, es ist muss, aber ich kann schon in gewisser Weise verstehen, was er meint.

Also ich meine, bei Rust kannst du dir halt sicher sein, dass da nichts liegt.

Wenn du es halt richtig machst.

Der musst du mitmerken, was meinst du denn damit da liegt?

Was?

Rum?

Naja, zum Beispiel, dass halt der Hauptspeicher immer weiter anwächst, ohne dass du das eigentlich wolltest, ja, sozusagen.

Oder dass du wirklich den Hauptspeicher brauchst, sondern dass halt Sachen nicht wieder weggeräumt werden, die halt irgendwann mal angefallen sind.

Klar, also Python nimmt dir das Memory Management halt komplett weg.

Und das ist tatsächlich Fluch und Segen zugleich, logischerweise.

Also jede technische Entscheidung, der hinsicht hat, immer Trade-Offs.

Und ein Aspekt bei Python ist nun mal, dass Python Speicher, den es mal gebraucht hat, auch wenn es den Akut gerade nicht braucht, nicht einfach mal so wieder hergibt.

Also wenn dein Prozess mal irgendwie, keine Ahnung, ein Gig oder zwei Gig groß ist, dann kann es gut sein, dass der das jetzt für die nächste Zeit mal behält, auch wenn du alle Objekte gelöscht hast und wenn die Garbage Collection durch war.

Weil es ist halt auch ein Trade-Off, zu sagen, naja, ständig Mellox groß und klein und groß und klein zu machen, hat auch Nachteile.

Es hat Nachteile in der Hauptspeicherfragmentierung, das ist an sich ein Performance-Thema.

Jada, yada, jada, yada.

Und Python als Universalsprache in der Hinsicht, wo eben Memory Management als ich kümmere mich drum draufsteht, verstehe ich, dass es in diese Richtung neigt, eben eher diesen universalen Ansatz dazu verfolgen.

Und Rust tritt nun mal an mit, du hast deinen Speicher im Griff, dann müssen sie das auch abliefern.

Das ist klar.

Also nochmal ganz kurz, vielleicht, was ein Melloc ist.

Also du assoziierst irgendeinen Speicher, oder?

Genau, also wenn du vom Betriebssystem halt Speicher haben möchtest, dann ist es ja heutzutage eh schon nur noch virtueller Speicher.

Also dass das in deinem Rechner irgendwie 8 Gig, 16 Gig oder halt mal ein halbes Tera oder ein Tera RAM drin ist, das weiß ja kein Programm.

Das guckt auch kein Programm so wirklich nach heutzutage, sondern ein Programm geht her und sagt, ey, du, könnte ich mal irgendwie Speicher im Wert von 3 Terabyte haben.

Und dann sagt, normalerweise der Linux-Körner heutzutage, klar, kein Thema, hier hast du.

Und erst in dem Moment, wo es das dann auch anfängt zu beschreiben, sagt der Körner, ach, du willst es auch noch benutzen?

Na dann.

Dann teilt er ihm tatsächlich irgendwie diese Sachen zu.

Und deswegen gibt es einige Programme.

MongoDB ist halt auch so ein Ding, die alloziieren zum Beispiel immer bloß in Vielfachen von zwei oder in zweier Potenzen oder so ein Kram.

Also wenn der halt hergeht und sagt, so ich brauche hier mal RAM, dann sagt er als erstes, ich brauche 64 Mac und dann irgendwie, ja jetzt hätte ich euch lieber 118, jetzt mal, okay, also jetzt hätte ich gerne einen Gigabyte.

Und das kann manchmal schon so ein bisschen unangenehm sein.

Aber der Vorteil ist halt, wenn der Speicher dann auch am Stück ausgeliefert wird, dann hat das bestimmte andere charmante Aspekte, weil dann bestimmte Overhead-Strukturen im Kernel dann halt reduziert werden können.

Der kann sogenannte Huge Pages machen.

Das heißt, du musst dann halt nicht, wenn du einen Gigabyte alloziierst, muss der Kernel halt nicht eine Million Mal eine 1 Kilobyte-Page irgendwo in seiner Tabelle abmarkern, weil auch das kann plötzlich schon mal 200, 400, 500 Millisekunden dauern, sondern der sagt dann einfach nur noch, hier hast du das Gigabyte.

Und das sind so Sachen, wo Python dann eben auch häufig optimiert.

Und Python ist extrem erfolgreich, was diese Optimierung angeht.

Ein Beispiel dafür sind zum Beispiel Listen.

Listen haben eine, es gibt eine Operation bei Listen, die ist unaufensichtlich O von 1.

Nämlich ein, genau, ein Append an Listen bei Python ist, wie war denn das?

Nee, sind Listen nicht immer ein O von 1 Append?

Ich weiß es, da war es gab irgendeinen spezifischen Fall.

Also die Story drumherum grob ist die, dass die Speicherallokation für Listen in Python auch immer nur verdoppelt.

Der allozierten Buffer für das Array, um die Indizes zu verwalten.

Und alloziiert aber, wenn er dann sozusagen es größer machen muss, nicht einfach sozusagen, dann muss er ja sozusagen das Ganze.

Achso genau, das Problem ist, wenn du es dann größer machen willst, musst du den Bestandsspeicher plus 1 nochmal neu alloziieren, alles umkopieren und dann halt das Neue reinschreiben.

Was Python aber macht ist, Python alloziiert immer dann das Doppelte von dem, was es vorher hatte, kopiert es einmal um, dann sind die nächsten N gratis, dann muss er wieder einmal verdoppeln, einmal kopieren und dann hast du wieder 2n gratis.

Und das sind so typische Sachen, die man in solchen Situationen halt hat, was so Laufzeitumgebungen für einen automatisieren und machen und weswegen sich dann hinten so ein bisschen komische Speichereffekte ergeben.

Da habe ich lange Zeit meines Lebens auch immer mit meinem Kopf kratzend davor gestanden und konnten Leuten nicht erklären, warum es das jetzt gerade tut.

Und da muss man sich halt irgendwann sagen, kann man nicht erklären.

Warum es genau das jetzt gerade tut, kann ich dir nicht erklären.

Ich bin mir relativ sicher, dass es kein Leak ist, wenn du halt dann irgendwie mal sowas beobachtest über eine Woche oder einen Monat, wenn du einen langlaufenden Prozess hast und die Saisonalitäten findest und du was merkst wie, ah, okay, früh morgens haben die Leute ihren Kaffee getrunken, jetzt lesen sie alle irgendwie das, was auf deiner Webseite ist, dann geht ihr Speicherbedarf irgendwie hoch.

Dann kommen abends irgendwann die Conjobs, dann geht er nochmal ein bisschen hoch, dann passiert lange nichts und dann mal wieder ein bisschen Speicher frei und dann ist irgendwie gut.

Und wenn du dann aber siehst, okay, über einen Monat ist es immer das gleiche, dann mag das zwar sein, dass er zu jedem einzelnen Zeitpunkt mal Speicher hat, den er jetzt gerade akut nicht braucht, aber es liegt nicht.

Ja, ich weiß auch nicht, was er damit genau gemeint hat.

Nee, ich verstehe das, dass er sagt, ich kann zum Beispiel, in Python ist es schwierig, kontrollierbar schlanke Prozesse zu bauen.

Das geht nicht so ohne weiteres.

Also es geht schnell, dass dein, dass dein, wenn du zum Beispiel eine Datenverarbeitungspipeline hast mit neun oder zehn Schritten und jeder Schritt davon braucht irgendwie einen Gigabyte RAM, dann kann das schon sein, dass dein Python da halt 10 Gig frisst.

Weil er halt eben den Speicher von vorher noch nicht freigegeben hatte, der jetzt aber auch gerade nicht gepasst hat, um das nächste Ding zu bearbeiten.

Und dann, so.

Das kriegst du unter Python halt nicht gut kontrolliert.

Ja, vor allem weil alles so dynamisch ist, weil ich also im Zweifel auch wirklich den Stack hochwandern kann und schauen kann, was da rumliegt oder ein Integer-Objekt als beliebiges Objekt sehen kann, was halt in Rust ohne weiteres nicht möglich ist und auch in anderen Programmiersprachen nicht geht.

Aber auch ohne Speicherverwaltung kann ich ja in Python durchaus noch andere Sicherheitslücken machen, die also gar nichts mit dem Speicher zu tun haben, mit dem, was wir jetzt die meiste Zeit besprochen haben, sondern halt zum Beispiel, dass ich sage, ich verwende den Subprozess und öffne den Subprozess und gebe da übergebe einen String und habe diesen String halt konstruiert aus Benutzerdaten und jetzt habe ich plötzlich eine Command-Injection, dass man beliebig Shell-Kommandos ausführen kann.

Das kann man in jeder Programmiersprache und also in jeder Programmiersprache die Shell-Kommandos ausführen kann.

Natürlich kannst du dich auf den Standpunkt stellen, okay, man hat das gefälligst nicht zu machen oder man hat gefährlichst immer Shell gleich Freils zu setzen oder das ist ja der Standard, also dass man eine Liste übergibt.

Aber das ist, also es gibt noch zahlreiche andere Schwachstänge, glaube ich, die in höheren, auf höherem Level noch passieren können, die gar nichts mit dem Speicher direkt zu tun haben.

Ja, absolut, genau.

Was habt ihr da?

Habt ihr schon mal böse Sachen gesehen, die in Python schiefgegangen sind?

Ich weiß, ich überlege gerade, ob ich irgendwas mal wirklich Schlimmes gesehen habe.

Django, ja.

Der Shell-Out, den Philipp da nennt, das ist halt schon schlimm.

Das ist das klassisch.

Auch sehr beliebt ist, wenn Leute meinen, ich muss hier Flexibilität reinbringen und jagen halt irgendwie User Input einfach durch ein E-Wall durch.

Das ist sozusagen die interne Variante des Shellouts.

Was ist dann eher ein E-Vi?

Ach, also E-Vile, ja, okay, ja.

Entschuldigung.

Ja, Funktionen.

Eval ist Evil.

Aber das ist im Prinzip die.

Oh ja, doch, Pickle.

Ja, da kann man sich.

Da kann man es ja schon mit dem Fuß schießen.

Mit E-Vile haben wir sogar einen ganz, ganz schlimm Bug und zwar hat eine Anwendung auf die Idee gekommen, dass man doch das cachen könnte.

Und man könnte doch den Code nehmen und dann kann man sich so ein kurzes, also man nimmt irgendwelche Benutzerdaten, die oftmals abgerufen werden.

Dann schreibt man einen dynamischen Python-Code, der das ausführt, und dann kann man das cachen.

Und dann war aber das Problem, dass sogar die noch eine Datenbank Schwachstelle hatten, dass man sehen konnte, was in der Datenbank lag und da lagen deren Cache-Objekte.

Und dann lagen da plötzlich Benutzerpasswörter oder sonst irgendwelche Sachen, die halt, also da kann man halt, wenn man halt so Schwachstellen verkettet, kann man das auch mal auf sehr krumme, also sehr fiese Sachen, die man mit einer einzelnen Schwachstelle gar nicht machen könnte.

Also das war jetzt nicht der Fehler, von denen, dass sie, also es war ein Fehler, dass man den Cache plötzlich sehen kann.

Und es war ein anderer Fehler, dass sie überhaupt E-WAR verwendet haben, aber erst durch die Kombination ist es halt eigentlich eine Schwachstelle gewesen.

Auch so ein klassisches Ding ist ja auch Directory Traversal, dass halt du irgendwie von außen sagen kannst, ich will XYZ haben, und dann wird halt nicht ordentlich geguckt, ob du durch Punktpunkt Slash-Kombinationen plötzlich dir dann irgendwie ETC-Passwege in unserem Kram halt auslesen lassen kannst.

Und das sind immer auch, das ist tatsächlich, glaube ich, am wichtigsten.

Und deswegen ist dieses, das ist wieder Variety Matches Variety.

Deswegen sagen wir, wir wollen so schnell so viele Verbesserungen in der Security wie möglich durch unsere Entwicklungspipeline jagen können.

Weil die eigentlichen Vektoren ist nachher, dass du hast immer eine Vielzahl von potenziellen Schwachstellen, die für sich genommen alle gar nicht so schlimm sind.

Und wenn du aber immer nur auf der Suche nach dem einen großen Ding bist, um alles zu reparieren, dann vergisst man schnell, dass es halt eher um diese Verkettung geht, wie Philipp sagt.

Da gibt es viele Kleinigkeiten, die das halt machen.

Also eben Directory Traversal irgendwie Daten abzusaugen, die dir dann einfach nur noch den Pointer geben für, ah, guck mal, da könntest du da drüben nochmal gucken.

Ein Klassiker, den ich mag, sind Exceptions.

Exceptions sind für mich die sensibelsten Daten, die dein System zur Laufzeit eigentlich von sich gibt.

Weil das Problem ist ja folgendes: Dein System ist an einem nicht bekannten Zustand mit Daten, die du dich kennst, und weißt nicht mehr, was es tun soll.

Und die Daten können halt alles sein.

Das können die Kreditkartendaten sein, das können die was auch immer.

Und dann steht da irgendwie Value Error hast du nicht gesehen.

Und du kannst den User nicht davon abhalten, Daten ins falsche Feld zu schreiben.

Dann schreibt er seine Kreditkartendaten halt das erste Mal irgendwie bei seinem Nachnamen aus Versehen rein.

Und deswegen diese Bewertung von was ist eigentlich sicher und was ist unsicher, ist total schwer.

Das Paradigma sollte auch eher sein, lieber ein bisschen zu sensibel zu sein und sozusagen dein Schutzniveau einmal grob festzulegen und zu sagen, okay, wir gehen ja mit Kreditkartendaten um.

Du musst davon ausgehen, dass irgendein doofer User, nein, die User sind nicht doof.

Es ist ein Usability-Problem.

Und das Usability-Problem ist, dass wir halt ein Gehirn haben, was bekloppt ist.

Da kommt dieses ganze Thema Cognitive Processing rein, von unser Gehirn will Energie sparen und deswegen reagiert es auf irgendeine Form von Challenge immer mit der billigst möglichen Antwort, also Patternmatching.

Und das Patternmatching von unserem Gehirn ist auch nicht Best Match, sondern First Match.

Das heißt, du hast eine Seite vor dir, hast aus deinem Passwortmanager deine Kreditkartennummer kopiert, dein Kind will was von dir, ja bitte, ich muss nur noch.

Klick, klick, klick und dann hast du halt deine Kreditkartennummer in das falsche Feld eingetragen.

So, und das ist halt, wie man bei Microsoft damals, alle zwei Millionen Mal, ja, das ist bei uns halt nächsten Dienstag.

Und sowas, und deswegen sagen wir auch, wenn wir Anwendungen damit Schutzniveaus belegen und sagen, was macht man hier?

Dann gucken wir eigentlich nur noch nach dem Worst Case und sagen, jetzt müssen wir davon ausgehen, dass das ganze Ding mit dem Niveau geschützt werden muss.

Weiter differenzieren macht überhaupt keinen Sinn mehr, weil du kommst dann von Hölzchen zu Stöckchen und irgendwer greift eh daneben.

Und deswegen bin ich mal sensibel darum, wenn es darum geht, so Exceptions an externe Systeme weiterzuleiten, weil im Prinzip übergibst du jemandem Externes alle deine Daten, weil du ja gar nicht weißt, was in der Exception drin ist.

Wenn du es gewusst hättest, hättest du halt schon irgendwas geschrieben, damit die nicht auftritt.

Aber wie bekommst du dann mit, wenn Exception passiert?

Also an irgendeinem System muss das ja weitergeleitet werden, oder?

Ja, internes System.

Also ich meine, wir, wir, also ich habe mich hier heute jetzt noch nicht wieder vorgestellt, ich bin ja so ein bisschen Stammgast schon.

Philipp und ich, wir kennen uns noch nicht, ja.

Wir betreiben halt Systeme auf eigenen, wir sind ein eigener sozusagen Cloud-Anbieter in der Hinsicht und haben die Infrastruktur und wir machen das auch so, dass wir halt zwischen den unterschiedenen Locations, die wir haben, halt entweder verschlüsselt Sachen weiterreichen oder eben lieber Dienste dezentral überall lokal nochmal vorhalten und dann musst du halt selber noch eine Greylog-Instanz da haben.

Und wenn man das heutzutage alles vernünftig ein bisschen automatisiert, dann lässt er halt noch eine Greylog-Instanz raus und das kannst du Daten da einfüttern.

Was ist Graylog, Christin?

Das ist ein Log-Agggregationssystem.

Also den kannst du mit Logdaten befüttern und ihnen dann nachher Parser drüber jagen lassen und dir automatisch Alerts schicken.

Das sind auch so ein Dinge, da spielen wir gerade zum Beispiel mit rum für so Thread-Themen.

Der kann aus Logdaten IP-Adressen rauspuppeln und der technische Begriff für parsen und hat halt dann wieder eine Anbindung an daran abzugleichen, ob diese IPs assoziiert werden mit irgendeiner Form von da kommen ständig Angriffe her.

Und dann kann ich die Auswertung dann wieder zurückfüttern auf meine Firewall vorne und kann sagen, so, und immer wenn irgendwie eine IP, die den Threat Indicator hat, irgendwie öfter als so und so oft pro Stunde vorkommt, dann wird die jetzt erstmal für drei Tage lahmgelegt.

Ah, das ist aber gefährlich.

Es kann ja sein, dass jetzt irgendjemand auf die Idee kommt und sagt, okay, du hast einen ganz, ganz wichtigen Kunden, mit dem du immer kommunizierst, und derjenige schafft es, irgendwie in das Netz reinzukommen von dieser IP und dann löst du diese Anfrage aus.

Ich glaube, da gab es auch schon mal Virensgänger, die sobald ein Paket kam, dann die genannte IP geblockt haben und dann konnte man die lustig anschreiben von 8888, einem typischen DNS-Server und irgendwie gesagt, oh, das Paket sieht nach Virus aus, sofort blocken wir alles von diesem Rechner und da geht nichts mehr.

Ja, genau.

Nee, nee, da muss man immer mit vorsichtig sein.

Und nichtsdestotrotz so ein bisschen mit so einen Sachen experimentieren wir halt gerne mal rumzugucken, wie sie aussehen.

Und dann willst du halt immer noch die Möglichkeit haben, nochmal durchgreifen zu können in dem Moment.

Klar.

Aber ich meine, das ist, macht das auch solche Sachen wie, weil ich kenne das eigentlich eher so als, ähm, es gibt immer, entweder verwenden Leute diesen Kibana-Stack oft.

Kibana hört sich nach Kibakirsch-Banane an.

Ja, schmeckt nicht so gut wie Kirsche oder Banane, leider.

Aber klingt auch lustig, ja.

Nee, das ist so irgendwie Elastic Search und also diese Richtung.

Aber da werfen Leute auch Logdaten rein oder halt eben Relock oder manche machen das auch mit Postgres oder aber ich meine jetzt für Python speziell, da gibt es dann irgendwie so Sentry oder Bugsnack oder so, wo die Tracepacks halt gesammelt werden.

Kann man sowas eigentlich auch gut selber hosten?

Weil das habe ich jetzt tatsächlich verwendet.

Ich kenne es auch immer nur, dass man da externe Services verwendet.

Kein Problem, Century kann man ohne Probleme, ist ein Open-Source-Projekt, kann man sagen.

Kommt ja auch selber aus der Python-Ecke.

Ist glaube ich auch Django, ist, glaube ich, Django unten drunter oder so.

Ich bin mir gar nicht mehr sicher.

Aber stimmt ist auch.

Vielleicht nicht mehr.

Century ist ja relativ groß geworden, tatsächlich, Armin und so.

Und die kannst du selber hosten, tatsächlich an der Stelle.

Das würde ich dann auch immer empfehlen.

Wichtig ist sozusagen ein Unterschied von der Log Aggregation versus Exception Logging.

Exception Logging hat die große Aufgabe, wenn du viel vom Gleichen entgegenkriegst, weil irgendwie der eine buggt gerade 50.000 Mal im letzten Tag auf, dann willst du, dass der dir die schon normalisiert und sagt, hier, das Problem gab es jetzt 50.000 Instanzen, hier sind die Parameter, die ich gesehen habe.

Logging macht natürlich immer nur, hier ist der Hydrant, hier kommt alles raus.

Ja, interessant.

Also viele verschiedene Typen von Angriffen, die man irgendwie mit verschiedenen Typen von Verteidigungsmaßnahmen beantworten möchte, können muss.

Probieren kann das, ja.

Sollen wir uns mal unbeliebt machen?

Oder ich mache nicht unbeliebt.

Wir einen Scanner oder sowas.

Ich meine, was die Leute mal so machen, wenn sie zu Hause, ich meine, vielleicht, also ich sehr beliebt, aber irgendwie glaube ich zum Beispiel, das bringt alles nichts.

Aber vor allen Dingen müssen die ganz viel mit Speicher machen und ganz, ganz viel Low-Level arbeiten.

Genau, das, was du uns nicht haben will, ja.

Also wo ich es noch sehe, wo ich noch mitspiele, ist, wo wir es gern haben, wo es angefragt wird und wir dem nicht harsch widersprechen, ist, wenn du sozusagen tatsächlich sowas hast wie deine Anwendung nimmt Daten per Mail oder Upload entgegen und du weißt, die werden dann nachher auf eher schlecht gepflegten Rechnern wieder weiterverarbeitet.

Also wir haben so ein Kram, wo dann irgendwie, keine Ahnung, Word-Files reinkommen und die sollen dann von irgendeiner dritten Partei auf ihrem Windows-Rechner verarbeitet werden.

Dann habe ich halt mal einen Klamm AV da mit drauf sitzen, der halt diese eine Datei scannt.

Aber das ist halt kein Ding, was das System scannt, sondern es ist bloß ein Programm.

Hier scannt die eine Datei, du sagst ja, okay, dann geben wir die weiter und wenn nicht, dann spermen wir sie halt zur Seite.

Das ist eine Form von Virenscanner, da spiele ich punktuell halt noch mit.

Das kann man schon mal machen.

Was ich halt nicht leiden kann, sind diese Security-Suites, die dann irgendwie einen Rechner irgendwie übernehmen und irgendwie mehr Schaden machen als, also gut, ich meine, da braucht man bloß Fefellesen, da kriegst du es halt alle zwei Wochen wieder serviert, Schlangenmüll und so.

Ja.

Gutes Konzept.

Was ich eben noch kurz erwähnt hatte, was mir noch irgendwann drüber gestoppt hat, was bei Django eine DOS-Attacke möglich waren.

Zwar bei RackEx, die benutzt worden ist, um bestimmte Formularfelder auszulesen.

Das heißt, man konnte einfach, indem man in Formulare, ich glaube E-Mail oder so, einen cleveren Recage reingeschrieben hat, irgendwie eine exponentiell wachsende oder Endlosschleife produzieren und dann dann die Seite.

Man kann Regex bauen, die sehr, sehr langsam werden, dann.

Dann hat man einfach ganz viele Requests da dran geschickt und dann hat man halt die Seite in die Knie ziehen können.

Das haben die irgendwann gefixt.

Ich glaube auch relativ spät, das bei einer 2er-Version, wenn ich das richtig bekommen habe.

Sehr interessant, solche Sachen.

Also das denkt man immer, jemand, der keine Ahnung hat, nicht dran, dass in so einfachen Bibliotheken wie Regex da was Tolles hinterstehen kann.

Ich glaube, was ist das?

Pearl-Regex oder wie nennt man das?

Diese Pearl-Compatible Regex ist PCAE, aber ich weiß nicht.

Das ist nicht in Python.

Die Python-Regex-Engine hat eine eigene.

Ja, okay.

Also moderne Regex-Engines können schon nicht alle Fälle, aber viele Fälle da besser erkennen und haben dann da auch bessere Garantien.

Also nicht erkennen, aber haben Garantien, dass das halt nicht in diesen Exponentiellen freiläuft.

Natürlich nicht immer.

Und natürlich kann ich immer einen Regex produzieren, der einfach so lange dauert, weil ich einfach sage, okay, hier kommt irgendwas Beliebiges und das darf beliebig oft vorkommen.

Und wenn ich dann ein langes String habe, dann ist es halt total, dann gibt es natürlich exponentiell viele Möglichkeiten, wie ich das Matching nehmen kann.

Und wenn ich den String so konstruiere, dass das Matching nie passiert, dann dauert es halt ewig.

Also und unendlich nicht, aber schon mal länger ist das Universum.

So, ich mache hier mal kurz, wir müssen eine Chaptermark hier ziehen.

Ich muss jetzt raus, ihr könnt mich rausschneiden.

Oder ich, also ich glaube, du kannst

ja mal schon mal gar nicht raus, du kannst einfach Tschüss sagen und ab.

Ja, wir haben eine Sekunde Pause gehabt, das könnt ihr rausschneiden.

Alles klar.

Gut, dann insofern.

Bis zur Fortsetzung demnächst mal wieder, genau.

Euch noch viel Spaß, bis dann.

Ciao.

Ciao.

Ja.

Haben wir denn zu dem Security-Thema noch irgendwie, ich weiß nicht genau, irgendwelche Dinge, die wir unbedingt erzählen wollten?

Ja, also mir fallen noch einige Sachen ein, aber fragt euch erstmal euch weiter.

Was geht es denn, Philippe fragen wir ja nochmal, was wolltest du denn noch erzählen, Security?

Es gibt, also was vielleicht wichtig ist, dass man eine Funktion nimmt oder eine Standardmöglichkeit nimmt, um sich gegen eine Sicherheitsschwachstätte zu verteidigen.

Also wir haben eben schon PastraVersus angesprochen, da könnte man denken, okay, also bei Pastraversus ist das Problem, dass ich irgendwas in den Pfad einschleuse, typischerweise halt Punkt.

Slash, Punkt Punkt, Slash, Punkt Punkt Slash, um halt aus dem Pfad der Anwendung rauszukommen und dann statt eine lokale Datei der Anwendung zu lesen, bekomme ich halt eine Datei irgendwo aus dem System, was sich die Passwortdatei oder die Datenbankdatei oder irgendwas anderes.

Und eine Möglichkeit, um sich dagegen zu verteidigen, ist natürlich zu sagen, ich nehme immer alle Punkte raus oder so.

Oder alle Slashes raus.

Und dann kommt man halt auf andere Systeme, zum Beispiel unter Windows, da ist ja ein Doppelpunkt wichtig.

Und da muss man auch an denen denken und dann ist der Backslash wichtig und es ist halt sehr schwierig, sowas richtig zu schreiben.

Da gibt es immer wieder Leute, die es versuchen, die sagen, ja, ich weiß es trotzdem.

Und bei einigen Systemen geht das auch.

Also man kann zum Beispiel bei SQL-Indexen kann man relativ einfach vermeiden, weil das halt eigentlich nur ein einfaches Anführungszeichen ist.

Aber es ist halt immer gut, dann für eine fertige Funktion oder eine fertige Struktur zu nehmen, die genau dafür programmiert ist.

Und die dann auch, zwar, die sicher ist, aber die ist halt sicher oder hoffentlich sicher, weil es halt nur eine ist.

In Python zum Beispiel, um Path-Traversor zu verhindern, kann man halt OS.path.baseName oder aus der Pathflip was nehmen, statt halt selber zu versuchen, diesen String zu bearbeiten.

Also nicht selber machen Security war das der.

Ja, genau.

Ja, es sei denn, wenn man weiß, was man tut.

Also an einigen Fällen kann es richtig sein.

Und ich glaube, ein anderes häufiges Problem ist auch, dass man sagt, ich versuche die Eingabedaten zu früh abzufangen.

Also dass ich sage, okay, ich habe eine ganz komplizierte Anwendung und immer wenn mir jemand was mit einem Anführungszeichen schickt, dann sage ich, geht nicht, ist Fehler oder ich schmeiße das Anführungszeichen raus.

Und das ist natürlich klappt vielleicht, aber dann muss ich halt überall dran denken.

Und es gibt halt verschiedene Kontexte.

Also wenn ich einen Pfad habe, dann ist halt ein Slash oder ein Backslash ein Problem.

Wenn ich aber HTML habe, dann ist das kleiner Zeichen oder das doppelte Anführungszeichen ein Problem und so weiter und so fort.

Das heißt, es ist wichtig, dass man darauf acht, dass man das in jedem Kontext richtig macht.

Und es ist schwierig zu sagen, oder es ist ein häufiger Anfänger vielleicht zu sagen, okay, ich gehe davon aus, dass meine Daten irgendwie korrekt sind.

Das ist dann doch immer sehr schwierig, weil man halt ein komplexes System hat, vielleicht sogar mit mehreren Mikroservices, die die Daten aus verschiedenen Quellen anliefern.

Aber wenn man darauf vertraut, dass die Datenbank irgendwie gute Daten enthält, das ist immer sehr, sehr gefährlich.

Ja, ist interessant, welche Assertions man dann daraus gibt oder welche Dinge man draus macht, wenn das nicht dem erwarteten Standard entspricht oder so.

Ein paar Stolperfallen.

Dass man einfach interpretiert, was da kommt, ist wahrscheinlich.

Immer Misstrauischstein gegenüber allen Daten, also auch der eigene Datenbank, auch die kann schon einhalten.

Okay, guter Tipp.

Ja, ansonsten genau, ein Thema, wo ich immer denke, das kann doch nicht so schwer sein, aber ich tue mich irgendwie schwer damit.

Ist halt, wie authentifiziert man sich eigentlich richtig irgendwie zum Beispiel per einer API, per HTTP oder so.

Oder die Web-Authentifizierung ist irgendwie nicht so einfach.

Und dann, ja.

Es gibt ein paar interessante Artikel dazu, die wir irgendwie ja letztens gelesen hatten.

Warum JBT.

Ja, JBT sieht echt gut aus, ja.

Und das ja viele Leute nutzen und da sagen, das ist der Standard, den es da gibt.

Ja.

Und ich habe aber auch jetzt auch noch nicht so viel gefunden, was man da anderer machen kann.

Es gibt irgendwie Paceto oder PiPaceto, aber da gibt es noch nichts wirklich Nutzbares.

Das muss man irgendwie auch alles wieder selber machen, vielleicht.

Und das ist da vielleicht wieder nicht so eine gute Idee.

Und da ist es gar nicht so einfach, irgendwie sich vernünftig per Token zu authfizieren.

Ja, tatsächlich, also das, was ich jetzt auch, ist halt, ja, HTTP-Only-Cookies.

Ja.

Vielleicht auch.

Oder Sessions dann?

Oder Sessions?

Session-Cookies ist halt manchmal ein bisschen schwierig, aber damit um, aber ja, es ist, also das ist immer wieder, wo ich mir denke, so, das müsste doch eigentlich jetzt einfach sein, aber irgendwie ist es das nicht.

Tja.

Oh, oder hast du, äh, hast du mal so von Indie ausgehört?

Oder ich meine, das ist halt so eine etwas abgespeckte O-Aus-Variante.

Gar nicht, okay, ja, ja.

Was ist das?

Das ist sozusagen, dass man halt selber also naja, also das ist auch von den gleichen, also das hat, ja Gott, jetzt muss ich wiederkomme ich vom Hölzchen auf Stückchen.

Das hat was mit dem Indie-Web zu tun.

Das ist so eine Bewegung, um dass man halt die Dinge selber machen kann, wo man normalerweise immer irgendwelche Unternehmen für braucht, die das halt machen.

Und es geht zum Beispiel darum, dass man sich mit seiner eigenen Webseite einloggen können will.

Sozusagen, also nicht Username, Passwort, sondern man gibt halt eine UR an.

Und dann hat man, gibt es halt sozusagen einen Hook, wo dann irgendwie man sagen kann, wie man jetzt, wie man sagt, dass man jetzt authentifiziert ist und dann zum Beispiel kann man sich dann halt irgendwie eine Push-Notification schicken lassen aufs Handy.

Und dann sagt man halt, ja, okay, das war jetzt richtig.

Oder man kriegt einfach eine E-Mail geschickt oder so und drückt dann auf den Link und dann.

Ja, dann Yu-Gi-Oh, bitte, oder sowas.

Genau, genau, genau.

Solche Sachen.

Und man ist ja sehr frei in der Art, wie man das halt dann, wie man diese Authentifizierung gestalten kann und das klingt eigentlich schon sehr nett.

Aber.

Das ist ja sicherlich immer die einfachste Lösung, wenn du sagst, ich möchte selber keinen Benutzernamen, kein Passwort speichern, weil einerseits sind mir die Daten zu sensitiv und ich muss genau gucken, wie ich das richtig speichere, ist zu sagen, okay, ich mache einfach, ich speichere überhaupt keine Benutzernamen, Passwörter und ich verwende irgendein Single Sign-On-System.

Du hast ja schon OS angesprochen oder OpenID Connect, ist ja der alternative Standard, dass man sagt, okay, jemand anders muss sich drum kümmern.

Und dann habe ich zwar diesen anderen Dienst, der irgendwo vielleicht auch in meinem Netzwerk ist oder vielleicht sagt, okay, ich erlaube Login mit Facebook, mit Google, mit Twitter und so weiter und mit GitHub.

Dann müssen die sich halt drum kümmern und dann kann ich halt da auch meinen, bin ich da raus aus der Sache, ich muss kein Passwort speichern.

Und für Benutzer ist es eigentlich auch nicht schlecht, weil der Benutzer muss kein Passwort wählen.

Weil wenn der Benutzer ein Passwort wählt, das ist ja auch nicht so gut so.

Aber das hat auch so ein paar Fallstricke wieder, ne?

Also zum Beispiel, wir hatten jetzt das System, dass wir auch so ein OpenID Connect irgendwelche Schnittstelle bauen mussten, aber wir haben das dann über Dango All aus versucht zu implementieren, die ja viele davon schon bereitstellt, irgendwie als Pakete.

Und dann müssten wir aber so einen eigenen Provider dafür bauen, weil der, den wir da hatten, da nicht genau das gemacht, was wir wollen.

Weil ich bin mir nicht sicher, ob das, was wir da gebaut haben, alles so gut richtig funktioniert.

Das wird sich dann irgendwie im Laufe der Zeit zeigen.

Richtig testen, mal gucken, ne?

Beim ersten Pentest hoffentlich.

Ja, ja, ja.

Oder beim ersten Pentest, der ungefragt ist und ungefähr auswartet.

Ja, ja.

Ja, aber was ich vor allen Dingen blöd finde bei diesen ganzen OpenIDO aus Geschichten auch, ist halt, dass man dann halt alles an so bestimmte User-Accounts hängt.

Weiß ich nicht, ob das jetzt GitHub, Twitter oder schlimmer noch vielleicht Facebook ist oder so.

Und dann passiert irgendwas Blödes und dann verliert man halt den Account und dann verliert man gleichzeitig den Zugang zu ganz vielen anderen Sachen.

Das ist ja auch irgendwie nicht so schön.

Ja gut, aber dadurch, also dadurch braucht der Blödsinn nur noch ein Kennwort und Facebook kann halt sehr, sehr viel bessere Sachen, bessere Authentifizierung durchführen, als du es machen könntest.

Also die schauen halt auf deine IP-Adresse, auf deinen Browser, die haben noch ein Session-Token, die haben vielleicht auch eine Mehrfachauthentifizierung, dass du sagst, Mehrfach-Authentifizierung, dass du noch irgendwie auf dem Handy was bestätigen musst.

Und das übergibst dir dann eine Partei, das musst du nicht alles selber implementieren.

Wenn du es selber implementierst, hast.

Ja, also gibt es wirklich dann einige Firmen, die das dann wohl doch dann ernster nehmen, als man manchmal so denkt.

Ich war zum Beispiel, ich bin mich einmal irgendwo ausgeflogen, als man das noch durfte irgendwie.

Und hab eine relativ hohe Überweisung angefordert, irgendwie, da durchgeführt.

Und auf einmal bekam ich dann so einen Anruf auf meiner Telefon von der Bank, die meinte so, ja, hallo, Herr, wollen Sie das wirklich tun?

Oder warten Sie das?

Ja, das war ich.

Ja, das ist ja alles gut.

Ja, aber das war schon mal nett, dass sie nochmal nachgefragt haben, anstatt dass sie einfach eine hohe Summe irgendwo hin überweisen, ne?

Oder von irgendwo.

Das war schon gar nicht so unrichtig, dass dann vielleicht dann ein Mensch ja nochmal nachguckt.

Also dass dann solche Alerts irgendwie in das System rausgehen, die dann mal gucken, wenn irgendwas ist.

Genau, das kann halt deine Anwendung ja nicht leisten.

Das möchtest du ja normalerweise nicht machen.

Du möchtest dich anfangen, dann also SMS zu verschicken oder was auch immer.

Oder solche Überprüfungen zu machen.

Und ich glaube, das ist einfacher, wenn man sowas zentralisiert.

Und wenn es halt, wenn du ein Passwort, also viele Leute verwenden halt einen Passwortmanager, aber auch die, glaube ich, die große Masse an Leute verwendet immer noch in 2020 keinen Passwortmanager.

Sondern haben ein Standardpasswort, was die dabei verwenden.

Und wenn dann halt irgendein Katzenforum gehackt wird, dann bist du plötzlich dran und dann rufen deine Kunden an, warum wurde hier meine Bankseite oder was auch immer, welche Seite du anbietest.

Warum wurde die gehackt?

Und dann sagst du, ja, du hast das gleiche Passwort in deinem Katzenforum verwendet.

Und die haben halt, wir haben die besten Sicherheitsstandards, aber das Katzenforum, das ist halt nur irgendeine Kiste, die irgendwo läuft.

Und die ist halt eh, da reichen sich die Hacker die virtuelle Türklinke.

Drücken sich die Hand, weil da halt so viele Hacker drauf sind, dass die sich gegenseitig schon stören mit ihren ganzen Exploits auf dem Katzenforum.

Und das ist halt ein Problem, was du mit dem ThingSign-On direkt an andere Leute verschiebst.

Dann muss sich Facebook oder Google oder wer auch immer oder dein eigener Single-On-Service muss sich dann darum kümmern.

Ja.

Ja, ja.

Ja, wir haben noch so ein paar Sachen, glaube ich, vergessen.

Also was wäre mit Security jetzt so ganz groß aufmachen?

Müsste man ja eigentlich noch über Social Engineering reden und ganz andere Geschichten.

Also ein paar USB-Sticks auf dem Parkplatz fallen lassen oder sowas und ob man Corporate sicher bekommt und wie das halt ist, so mit, wie man die Leute auditen kann und da gibt es ja so Experimente zu.

Also zum Beispiel bei einzigen Konzerne verschicken ja dann so Test-E-Mails oder Trainings-E-Mails regelmäßig, um zu gucken, klicken die Leute auf alles, was da so ins Mailfach flattert.

Und dann die Antwort, ja, das tun sie.

Und dann kann man die halt ein bisschen erziehen oder sowas und dass man die Quote davon reduziert und das ist eine ganz spannende.

Ja, aber da würde ich jetzt auch spontan sagen, naja gut, aber ich meine, dafür sind doch die Sachen dafür da, dass man da drauf klickt.

Also ich meine, das ist ja, das kann es ja eigentlich nicht sein, dass man irgendwie die Leute dazu erzieht, irgendwie sich an komische Regeln zu halten, damit die Software bleiben darf.

Das ist ja irgendwie.

Ja gut, da gibt es ja ein ganz wichtiges Sicherheitskonzept, was wir noch gar nicht so richtig.

Wir haben es Schweizer Käse genannt oder Defense in Depth, dass ich sage, okay, sorge dafür, dass auch wenn, also dem Chef der Firma, der schon 60 ist und der noch ein bisschen mit der Schreibmaschine arbeitet und der auf alles klickt, was bunt blinkt, dem gebe ich vielleicht keinen Ruhzugriff.

Auch wenn er sagt, ich bin der Chef, ich möchte auf die ganze Firma überall Zugriff haben, da sage ich, okay, du kriegst deinen eigenen Rechner und von deinem Rechner darfst du nirgendwo rein und darfst vielleicht noch einmal rein.

Du bist dann der Admin, der bei dir vor der Tür steht und das dann mit dir gemeinsam macht.

Ja.

Ja, aber du kannst halt also dafür sorgen, dass du halt Netze separierst oder jetzt im Zeiten des Homeoffice, dass du halt Systeme separierst und sagst, okay, jedes System muss eigentlich davon ausgehen, dass alle anderen Systeme gehackt sind.

Also auch im internen Netzwerk, dass ich muss davon ausgehen, ich kann keinem aufgrund nur aufgrund der IP-Adresse vertrauen, nur weil er mit mir kommunizieren kann.

So und das System muss halt ordentliche Singles-Son-on-Tokens überprüfen.

Oder was auch sehr beliebt ist für Service-to-Service-Kommunikation, sind halt Client-Seite-TLS-Zertifikate.

Dass ich sage, ich verwende das TLS nicht, wie man es normalerweise verwendet, dass ich einen Server habe, sondern ich habe auch ein Client.

Du hast ja eben schon eine Yubi-Key angesprochen, den man genauso einsetzen kann, wenn er ein Mensch ist.

Aber auch zwischen Systemen ist das, glaube ich, so der goldene Standard, dass man sagt, okay, ich habe ein Client-Side-TLS-Zertifikate, ich habe einen Server-Side-TLS-Zertifikat.

Vielleicht gleich nochmal ganz, ganz kurz da, einmal kurz das Low-Level auf.

Also TLS ist irgendwie Transport Layer Security.

Genau.

Auch bekannt als SSL.

SSL ist der Funkstandard.

Und das macht sowas sicher wie eine Verbindung zu einem anderen Rechner, dass sie irgendwie verschlüsselt übertragen, dass man sich nicht in die Mitte setzen kann, um das abzuhören.

Ja, nicht eine Verbindung zu einem anderen Rechner, sondern also auch, aber von einer Anwendung zu einer anderen.

Also auch auf dem lokalen Weg.

Ja, genau.

Ja, okay.

Ja, das sind halt irgendwie so genästete Sicherheitslevel, die irgendwie so ineinander stecken und das ist dann, wird dann irgendwann alles relativ komplex dann mit den ganzen.

Ja, ja, du brauchst halt da allein, also für sowas wie eben so eine stinknorale, ich weiß nicht, so eine Anwendung wie, du bist auf deiner Bankseite und machst da irgendeine Transaktion, müssen halt viele Dinge gewährleistet sein.

Also der TLS-Teil macht halt die Vertraulichkeit, beziehungsweise Integrität, ich weiß jetzt jetzt gar nicht genau, was man da macht, aber was du halt auch noch.

Beides, genau.

Was du halt auch noch brauchst, ist halt Authentifizierung.

Also du musst dich halt irgendwie gegenüber der Bank ausweisen, damit die Bank weiß, wer du bist und überprüfen kann.

Und das ist dann der dritte Teil, ob du auch autorisiert bist, das zu tun, was du da tun willst.

Das ist halt nochmal getrennt davon, weil es kann ja sein, selbst du hast dich zwar eingeloggt, aber du darfst irgendetwas nicht machen.

Und Autorisierung ist halt auch nochmal so ein Riesenthema.

Wie kriegt man das eigentlich ordentlich hin?

Der coole Trick bei TLS ist halt, dass du sagen kannst, ich, äh, also du kannst erstmal sowieso asymmetrisch arbeiten.

Das heißt, der private Schlüssel verlässt nie die Box.

Du hast also einen Client, also einen Service, der einen anderen Dienst was sendet und der hat einen privaten Schlüssel und der andere Dienst kennt nur den öffentlichen Schlüssel.

Und das kannst du noch weiter treiben, indem du halt sagst, ich verwende nicht, der andere Dienst muss doch nichtmals den öffentlichen Schlüssel kennen, sondern es gibt noch eine dritte Partei, die das irgendwie signiert.

Und das verwendest du ja, wenn du auf eine normale Webseite gehst und hast eine normale HTTPS-Seite, dann ist die halt oben grün, weil halt dieses Zertifikat von jemandem signiert wurde.

Und das kannst du aber auch kleinseitig verwenden, dass du sagst, okay, ich zertifiziere nicht nur, dass derjenige, der die Anfrage entgegennimmt, richtig ist, sondern auch der, der die Anfrage sendet.

Das ist tatsächlich wieder interessant, weil das irgendwie das nächste Thema ist, was irgendwie eigentlich zur Security natürlich dazu gehört und das wäre Kryptografie oder Verschlüsselung, ohne dass man ja wahrscheinlich nicht auskommt.

Und da gab es ja irgendwie Algorithmen, mit denen man bestimmte Dinge verschlüsselt oder hasht oder wie auch immer und die man dann mehr oder weniger schnell entschlüsseln konnte oder sowas.

Oder man konnte sogar so Angriffe verfahren wie, ich glaube, Rainbow Table nennt sich das oder sowas, dass man halt Passwort-Hashes einfach in eine Tabelle schmeißt und guckt, wie ist denn das Ergebnis von dem Hash, also was ist denn da der umgekehrte Wert von oder so.

Und ja, wenn man solche Sachen halt irgendwie vermeiden möchte, dann müsste man aber, glaube ich, schon gucken, welchen Algorithmus man zum Schlüsseln, Entschlüsseln seiner Schlüssel nimmt.

Ach, und das sind zwei verschiedene Sachen.

Verschlüsseln und, also mein Passwort möchte ich eigentlich nicht verschlüsseln, weil dann muss ich ja den Schlüssel irgendwo auf dem Server speichern.

Ja.

Oder also das Passwort eines Nutzers

möchte ich.

Ich meine jetzt also so SSH-Keys oder sowas, also das meine ich mit Schlüssel.

Ah, okay.

Die dann bestimmten Algorithmus benutzen irgendwie.

Okay, ja, ja.

Dass man halt da, also das müsst ihr vielleicht nochmal erklären, also wie man halt da von einem einen, ich sag mal, nicht so guten Algorithmus den Schlüssel berechnen kann aus dem Public Key oder sowas, ja, bei asymmetrischer Verschlüsselung.

Du bist ja den Schlüssel selber musst du eigentlich nicht berechnen.

Du kannst ein Zertifikat berechnen, das ist der Schlüssel nochmal in Kurs, aber du könntest eigentlich auch immer den Schlüssel an sich verwenden, den Öffnens-Schlüssel zumindest.

Nur weil der Öffentliche Schlüssel ist halt bei dieser Kryptografie sehr lang, das muss halt eine sehr lange Zahl sein.

Und die kannst du halt eindampfen auf eine kürzere Zahl, die man aus verschiedenen Gründen dann verwendet, die auch immer gleich ist, egal wie lang der Schlüssel ist.

Und das ist das Hash-Verfahren.

Das verwenden wir auch bei Passwörtern und auch an vielen anderen Stellen.

Kann ich auch verwenden, um zum Beispiel zu überprüfen, wenn ich Software runterlade, dass die in Ordnung ist.

Haben wir eben schon mal angesprochen, dass wenn ich das mit Python mache, dann habe ich zum Beispiel bei Pipenv, oder bei Pip habe ich einen Pip-File und ein Pipfile.lock und in Pipfile.lock stehen halt die ganzen Hashes drin.

Und was ein Hash macht, ist halt genau, eine lange Eingabe zu nehmen, egal welche Länge, und sie auf eine Zahl zu reduzieren, die eine relativ kurze Länge hat und die auch immer die gleiche Länge hat.

Das sind dann halt nachher so 32 Buchstaben oder sowas.

Und das ist halt kryptografische Magie.

Und es gibt halt Mathematiker darum gekümmert, dass es nicht möglich ist, das rückwärts zu rechnen.

Das heißt, wenn ich einen Hash habe, kann ich nicht das Original rechnen und ich kann gegeben einen Hash kann ich nicht überhaupt nicht ein Original finden.

Das heißt, wenn du mir dein Hash gibst, dann kann ich eigentlich sicher sein, dass die Originaldatei genau unverändert ist.

Und genau dafür kann ich die halt einsetzen.

Ja.

Okay, das Rückrechnen ist dann bei unsicheren Hash-Verfahren dann vielleicht doch möglich oder sowas?

Oder dauert dann so lange?

Ja, oder man kann halt Kollisionen finden und dann kann man eben beispielsweise Dokumente dadurch fälschen, dass man, wenn man hinten Leerzeichen anfügt oder wegnimmt, kann man ja beliebig viele Kombinationen erzeugen.

Wenn man weiß, wie man die Kollisionen erzeugen kann, dann kann man halt quasi beliebige Texte mit einem bestimmten Hash erzeugen und das ist natürlich ganz schlecht.

Genau, dann habe ich halt deinen Schlüssel und dann kann halt jemanden anders einen anderen Schlüssel generieren und die haben plötzlich den gleichen Hash.

Dann kann er sich mit seinem eigenen Schlüssel, der so tut, als wäre dein Schlüssel damit authentifizieren.

Also um Sicherheit von Kryptografie oder sowas in der Hinsicht noch?

Ja, aber ich glaube, ich weiß gar nicht, ob man sich als jetzt so Endanwender oder so da so wahnsinnig viel mit beschäftigen muss, weil ich glaube, wenn man da anfängt, sich für zu interessieren und dann irgendwelche Entscheidungen zu treffen, dann liegt man wahrscheinlich eher, ist sie wahrscheinlich halt hoch, dass man falsch liegt.

Ich könnte quasi diese Wahl auch gar nicht mehr treffen, welche kryptografischen Algorithmen man zum Verschlüsseln entschlüsseln benutzt.

Doch, ja.

Also wenn du zum Beispiel hasht, dann musst du der Preis ein Hash-Li, musst du sagen, okay, ich möchte diesen Hash haben.

Dann sagst du zum Beispiel, ich möchte Sha1 haben oder ich möchte MD5 haben.

Und wenn da da die falsche Wahl trifft, dann hast du durchaus ein Problem.

Also Shar1 oder MD5 sollte man nicht nehmen, sondern SHA 256, oder?

Genau, SHA256 oder eine SH3-Variante oder was anderes.

Aber eigentlich willst du gar nicht, dass der Entwickler sich drum Gedanken machen soll.

Der Entwickler soll ja gar nicht sagen, okay, ich nehme Sha1, sondern der Entwickler soll eigentlich sagen, okay, ich nehme eine fertige Bibliothek.

Und dafür gibt es dann in Python zum Beispiel die neue Passwortbibliothek oder es gibt B-Crypt.

Und da muss ich mich halt gar nicht drum kümmern.

Ich weiß gar nicht, die Passwortbibliothek heißt, glaube ich, Secret.

Secrets.

Secrets, ja, genau.

Und da muss ich halt nicht mehr drum kümmern.

Also da wird halt die Wahl für dich getroffen.

Und das macht es für den Entwickler natürlich besser, weil der Entwickler keine Entscheidung treffen muss.

Wenn du ein System groß zertifizieren musst, dann musst du wahrscheinlich trotzdem irgendwo eine Entscheidung treffen, weil da andere Leute drüber schauen wollen.

Aber für so die Weit- und Wiesen-Anwendung, die einfach mal so von vielleicht einem kleinen Team entwickelt wird, ist das sicherlich eine bessere Option, wenn die keine kryptografischen Entscheidungen treffen, also noch nicht mal die Entscheidung treffen, welche Algorithmen sie verwenden, sondern vielleicht nur noch sagen, ich möchte ein bestimmtes Sicherheitslevel haben.

Das ist ja auch immer ein Trade-Off, dass ich sage, okay, weil ich kann ja zum Beispiel mehrfach hintereinander hashen und dann kann man das halt bei dem Passwort, dauert es auch länger, dass das rauszufinden, weil ich halt, wenn ich ein Testpasswort habe, muss ich das ganz oft hashen, um das Zielpasswort zu finden.

Aber das ist halt auch ein Problem, was auf deiner Seite, weil wenn du das halt jetzt sehr oft hasht, dann dauert es natürlich bei dir länger.

Und du möchtest ja nicht, dass dein Service plötzlich eine Minute braucht, wenn sich ein Benutzer einloggt, weil der halt dein Passwort irgendwie eine Million Mal hasht oder sowas.

Das ist bei uns auch mal so ein schönes Ding bei Tests, wo man halt irgendwie Zeit sparen kann.

Und da liegt man halt, die Passwort-Hash-Funktionen sind ja genau die, die sind ja genauso gestaltet, dass sie möglichst langsam sind.

Und genau, da will man dann vielleicht doch mal MD5 verwenden oder sowas in der Art, weil das ist halt dann deutlich schneller.

Und man legt ja, wenn man jetzt einen Test-Suite durchlaufen lässt, oft irgendwie ganz viele Nutzer an und ja, dann das kann Dinge deutlich beschleunigen.

Ja.

Sehr, sehr interessant.

Da fallen mir ja ganz viele Sachen, glaube ich, noch zu ein, was man da so macht mit Vulnerabilities und Disclosure und all so Dinge.

Ja, Picks tatsächlich.

Und die Frage, wollen wir ein Standard-Lib-Modul vorstellen?

Ich fälsche dir mit Sequitz vorstellen.

Ja, muss ich sagen, kannst du dich mit Sequitz auch aus?

Nicht im Detail.

Okay.

Schade.

Ich dachte, er hat gedacht, ich kann ja die Verantwortung von mir schieben.

Ja, aber wenn du dich damit beschäftigt hast, dann mach das doch.

Was ich?

Nein, nein, nein, nein.

Nein.

Also.

Was wäre denn euer Weg tatsächlich?

Ja, also meiner wäre jetzt tatsächlich YouTube.dL.

Wie kommst du da drauf?

Ja, ich habe damit in letzter Zeit, im letzten Jahr viel gemacht.

Ich habe das so, also ich habe es früher vielleicht ab und zu mal benutzt, um irgendwie mal Videos runterzuladen, die ich gerne auf der Platte hätte.

Also da genau, dafür ist es ja da, aber letzten Jahr habe ich das auch viel sozusagen in Projekten verwendet, weil es darum ging, wie man da Videos irgendwie automatisch verarbeiten kann und sowas.

Ja, und ja, es ist ein sehr, sehr schönes Tool.

Es ist halt, genau.

Ja, aber ich glaube, Philipp kann das deutlich besser erklären, was das eigentlich so tut und was so ein bisschen

vielleicht ist.

Und es zeigt, aber es gab auch so einen kleinen politischen Vorfall beim YouTube.

Das müssen wir auch noch natürlich als erzählen.

Also der Name von YouTube.

Also es hat angefangen als ein Download-Tool nur für YouTube.

Und als ich das damals übernommen habe, da wurden, glaube ich, noch Vimeo unterstützt und noch ein, zwei andere Seiten.

Aber als ich das abgegeben habe, also mittlerweile entwickel ich auch schon länger nicht mehr dran, oder entwickel schon ein bisschen dran, aber bin halt nicht mehr der Chef-Mantainer oder Wappen-Maintainer.

Und mittlerweile unterstützt es über 1000 Dienste.

Das heißt, du kannst es auch auf irgendeine komische Anime-Seite laufen lassen oder auf die ARD-Audiothek oder auf archive.org oder die CCC-Kongress-Seite und es wird dir halt immer ein ordentliches Video zurückliefern.

Du kannst natürlich auch sagen, ich möchte verschiedene Konfigurationen, also möchtest, weiß ich, das Video sortieren oder möchtest du direkt eine Playlist runterladen.

Und YouTube DL ist komplett in Python geschrieben.

Das ist vielleicht auch ein bisschen besonders, weil es eine Python-Anwendung ist, die gar keine Dependencies hat.

YouTube DL verlangt nur die Standardbibliothek und das auch sehr, sehr, sehr flexibel.

Also bis vor kurzem noch konnten wir zwischen Python 2.6 gingen noch bis Python 3.8, wo er alles unterstützt.

Hat sehr, sehr viele Benutzer und ja, ist halt hoffentlich ein super flexibles Tool, das man auch sowohl programmatisch als auch als Kommandozeil-Anwendung verwenden kann, um schnell was runterzuladen.

Viele grafische oder serverseitige Programme verwenden auch intern YouTube.dL, um halt Videos runterzuladen aus verschiedensten Quellen.

Typischerweise, also oft YouTube, aber kann auch was ganz anderes sein.

Und der Vorfall, der halt passiert war, ist, also vor dem öffentlichen Vorfall bin ich und ein Hostar angeschrieben worden von einer deutschen Anwaltskanzlei, die rasch heißt die, die sind, wenn man nach denen googelt, dann, also ich habe sie erst natürlich nach denen gegoogelt, als ich das Schreiben bekommen habe, sieht man, okay, die verschicken normalerweise Abnahmen wegen Tauschbörsenvorfällen oder sowas.

Irgendwie bekannt wurde der Name, ja.

Und die haben halt da einen typischen Re- also ich kann das jetzt nicht so beurteilen, ich bin kein Jurist, aber die haben halt ein sehr langes Papier geschrieben, wo sehr große Drogen drin standen, was für mich eigentlich jetzt irrelevant ist, weil ich bin ja nicht mehr in dem Projekt involviert, auch schon, also ich habe noch gelegentlich Contributions geleistet, aber auch nichts mehr zu YouTube, sondern nur noch zu ganz anderen Seiten.

Und dann haben die wohl aber mitbekommen, dass YouTube-DL auf GitHub gehostet ist.

Und dann an die amerikanischen, ja, richtig technisch drauf waren sie nicht, aber gut, sie sind auch recht anwendig, sind keine Programmierer, haben halt nur so ein bisschen was gefunden und haben auch viele Sachen nicht richtig verstanden.

Also, das ist halt, äh, ja, kann man halt nicht machen.

Und dann sind sie halt zu den Amerikanern gegangen und die, äh, die AIA.

Und die hat dann halt GitHub eine Notiz geschickt, äh, äh, das, eine, die, ähm, DMCL-Notiz, dass sie halt die YouTube DL sperren sollen.

Und davon haben die meisten Leute erst mitbekommen, dass irgendwas nicht stimmt.

Also diese Vorgeschichte, das war schon Wochen davor in Deutschland und auch andere Sachen waren Wochen davor, aber was die Öffentlichkeit mitbekommen hat, ist, war, okay, GitHub ist gesperrt.

Und GitHub ist freundlicherweise für das YouTube DL-Projekt, das hostet die Downloads.

Das YouTube DL muss relativ häufig aktualisiert werden, also wird so alle zwei, drei Tage aktualisiert.

Klar, bei irgendeiner Webseite ändert immer was oder irgendjemand fügt etwas hinzu.

Und es ist halt auch ein sehr, sehr aktives Open Source-Projekt.

Also da laufen pro Tag 10 PS rein.

Und dadurch stehen halt große, hohe Downloadzahlen und dann ging halt erstmal gar nichts, weil GitHub was nicht gemacht hat.

Das Projekt ist direkt umgeschwenkt und ich hatte schon befürchtet, dass es daran endet, dass das Projekt nur noch YouTube-Musik runterladen kann.

Also der Stein des Anstoßes war nicht die normale YouTube-Downloads, sondern die YouTube-Musikvideos.

Das war das Problem, was die Rechtsanwälte bemängelt hatten.

Und was jetzt aber passiert ist, dass glücklicherweise die IFF, die Electronic Frontier Foundation, eine USA die Verteidigung übernommen hat von YouTube DL und da eine Gegennotiz geschickt hat und jetzt auf GitHub wieder alles da ist und GitHub das wieder hostet und das Projekt wahrscheinlich jetzt ganz normal weiterläuft und es alles wieder klappt.

Ich war da auch gar nicht so viel involviert, ich bin halt nur von zig Leuten angeschrieben worden, hab einige Interviews gegeben und ich bin halt natürlich rechtlich, musste ich, habe ich mit einem Rechtsanwalt gesprochen.

Damals hatte ich dann nicht den richtigen Überblick, habe dann auch eine Unterlastungserklärung abgegeben, dass ich nicht mehr daran teilnehme an YouTube.dl.

Sehr traurig.

Aber das Projekt sieht jetzt gut aus und scheint überhaupt kein Problem zu sein.

Und ich bin sehr froh, dass die IFS sich darum gekümmert hat.

Und auch über die Unterstützung von GitHub.

Und zuletzt sollte man vielleicht auch erwähnt, es gibt einen deutschen Hostar, der daran beteiligt ist.

Das ist Uberspace.

Da kann man super leicht seinen eigenen Dienst hosten.

Und die sind auch rechtlich angeschrieben worden, auch von den Rechtsanwälten rasch.

Und die haben sich auf eigene Kosten ihre eigene Verteidigung organisiert.

Die hosten halt nur die Webseite, die hosten nicht das Programm selber.

Aber auch das fanden die Rechtsanwälte verwerflich.

Glücklicherweise ist jetzt, glaube ich, alles gut und ich glaube, YouTube.

wird jetzt genutzt.

Glaube ich, völlig unbestritten, dass das absolut legitim ist.

Es haben sich nach der Sperrung auch sehr, sehr viele Museen oder Archivare oder Bibliotheken gemeldet, die gesagt haben, okay, wir verwenden das und wir haben sogar rechtlich das Anrecht darauf, selbst Musikvideos runterzuladen, weil das genau steht.

Und irgendwie muss es halt passieren und YouTube DL ist genau das Werkzeug, um sowas zu machen.

Und ich glaube, der Nutzen von YouTube DL überwiegt bei weitem das jegliche Probleme, dass man da ein Musikvideo in malerweise relativ schlechter Qualität von YouTube runterladen kann, was man ja auf Spotify oder überall beim Amazon oder bei Apple als MP3-Datei oder als FLAG-Datei in deutlich besserer Qualität kaufen kann.

Ich glaube, das ist viel besser für die Gesellschaft, dass YouTube.dL für alle verfügbar ist.

Das ist auch super praktisch.

Spitzwinniger Winkel-Advokat, da kann man sich ja nochmal überlegen, ob man nicht noch einen kleinen Pfeilstrick herbeizaubern kann.

Ja.

Aber ja, also ich glaube auch eher, dass es der, also sagen wir so, das hat dem Projekt wahrscheinlich doch eher stark genützt.

Das hat jetzt nochmal sehr viel Aufmerksamkeit bekommen und hat der Streisand-Effekt voll zugeschlagen.

Ja, ja, auf jeden Fall.

Also ich bin tatsächlich froh, dass das mittlerweile soweit ist, dass solche Sachen nicht mehr einfach so dann weggeblockt werden, sondern dass die Leute sich anfangen, mit solchen Dingen auch juristisch dann auszukennen und dass diese komischen Kanzleien oder jemand auch immer das da nennen soll, langsam aber sicher gegen die Wände rennen.

Ja, ist halt schwierig, als Open Source-Programmierer.

Ich bin halt nur eine Person.

Ich habe da kein, ich habe keine große juristische Know-how.

Also ich kann das halt technisch beurteilen, was im Gesetz steht.

Aber offensichtlich gibt es auch einige Gerichte, die das sehr flexibel ausgelegt haben, was da im Gesetz steht.

Also das Landgericht Hamburg hat gesagt, okay, im Wesentlichen, da steht, dass es technisch eine technisch durchsetzbare Verschlüsselung oder Verschleierung geben muss.

Und das hat dann einfach interpretiert als, ja, das hört sich aber komisch an, das interpretieren wir jetzt anders.

Und jetzt haben wir es gesagt, in dem Urteil, eigentlich alles, was ein normaler Benutzer nicht machen kann, ist verboten.

Das heißt, alles, was gab ein vergleichbares Urteil und da hatte jemand argumentiert, okay, das kann man aber auch in den Browser-Tools machen.

Und dann hat das Landgericht Hamburg gesagt, nee, das ist aber kein normaler Benutzer nicht, weil das ist nicht im Internet-Explorer drin oder so.

Und das ist halt eine sehr fragwürdige Argumentation.

Ja, da hat der Jurist das ja selber ausprobiert und dann festgestellt, nee, er kann das nicht.

Ja, genau, genau.

Genau.

Und YouTube DLS funktioniert eigentlich wie ein normaler Browser.

Nicht unterschiedlich, nicht grundsätzlich unterschiedlich wie Chrome, es hat auch eine eigene JavaScript-Engine in Python geschrieben.

Ach, okay.

Und tatsächlich, ah, naja, stimmt, wenn es keine externen Abhängigkeiten gibt.

Oh, das wusste ich nicht.

Das hätte ich jetzt auch gedacht, dass das vielleicht irgendein Headless Browser-Engine noch mit dabei ist oder so.

Nee, komplett.

Also gar keine Python-Abhängigkeiten.

Klar, wenn ich eine normale, jetzt eine normale Python-Anwendung schreibe, dann verwende ich Abhängigkeiten.

Die haben ja eben gerade besprochen, dass es eigentlich gut ist, wenn ich fertige Bibliotheken verwende.

Aber YouTube DL muss halt auf ganz unterschiedlichen Systemen laufen.

Da gibt es halt Leute, die kommen an mit Red Hat und haben halt, weiß ich, haben halt Python 2.6 oder bis vor kurzem noch Python oder vor allem jetzt halt noch Python 2.5 haben die noch drauf oder Python 2.4, keine Ahnung.

Und da kannst du halt nicht darauf vertrauen, dass die auch überhaupt irgendwas installieren können.

Die sind halt froh, wenn die ein Binary bekommen.

Und das geht ja in Python relativ gut.

Man kann die Details einfach als ZIP verpacken und dann ist es ausführbar.

Und man kann es auch mit, ich glaube mittlerweile verwendet YouTube.

CX Freeze, um halt auch eine Excel für Windows zu erzeugen.

Und das läuft dann wirklich überall, ohne dass man es installieren muss.

Und ich glaube, das ist auch ein Grund für den Erfolg dieser Software, dass man das halt einfach so laufen lassen kann, dass man sich keine Gedanken machen muss, auch wenn das System komplett zerschossen ist als Python-Entwickler, das klappt immer.

YouTube DL Klappe braucht eine schande Politik.

Ja, ja.

Sehr gut,

sehr gut.

Ja, es klingt sehr spannend.

Ja, ja, mir war das auch gar nicht so klar, dass man da tatsächlich irgendwie die meisten Seiten mit bedienen kann.

Und dann, ja, das, ich dachte, er hatte früher auch mal gedacht, das wäre eigentlich für YouTube, aber ja, es ist wirklich sehr, sehr praktisch.

Es sind einem auch viele ab.

Also ich benutze das jetzt halt immer so quasi, um halt automatisiert von allen möglichen Seiten Dinge runterzuladen und das halt sozusagen die Schnittstelle, die YouTube-TL ist sozusagen meine API zu seiten, die Videos haben, um das Video da rauszukriegen.

Genau.

Ohne, ja, ja.

Ja, Picks.

Also ich würde diesmal Python Date-Tutil picken, weil irgendwie das ein schöner Rapper ist, über wie man Datumsangaben irgendwie machen kann.

Verschiedene Zeitkalendern mit Deltas.

Ich wollte mal erwähnt haben, das stand irgendwo noch auf meiner Liste, hat jetzt nicht mit dem Topic gar nichts mehr so viel zu tun, aber.

Ja, Date Utils ist tatsächlich auch sehr nett.

Also ich, das Date-Tutil Pass, das passt erstaunlich viel.

Also dem kann man irgendwelche Strings geben, die so, also man hat ja oft irgendwie, sieht man dann irgendwo so einen String mit Datums und Zeitangaben drin und dann denkt man sich so, oh, wie waren jetzt nochmal die Formatstring, Dinger, wie hießen die nochmal alle?

Und dann nimmt man Da Tutal Pass und dann passt das das automatisch, aber dann muss man irgendwie noch, ich glaube, das geht aber auch irgendwie, man kriegt auch aus dem Day Tutal Pass dann raus, wie der Formatstring eigentlich sein müsste.

Und andere Kalender und andere.

Genau, weil Day Tutal Pass sollte man nicht über größere Datenmengen irgendwie aufrufen, weil das wird dann halt sehr langsam, wenn man das innerhalb schleife verwendet.

Aber um rauszukriegen, wie man das denn jetzt eigentlich aufpasst und dann halt an den Formatstring zu kommen, mit dem, den man dann letztlich verwendet, für Strip Time oder so, das ist super.

Und dein Pick Jochen?

Hatte ich da schon.

Gott schon, ja?

Ja, YouTube-DL.

Ach, verdammt.

Ja, richtig.

Ich dachte jetzt, das wäre Philips-Pick gewesen, aber ne.

Ja, gut.

Naja, aber du bist da ausnahmsweise wegen dem YouTube-DL da rumgekommen.

Es sei denn, du hast noch einen, Exa.

Nee, sage ich das nicht vorbereitet.

Ich habe mich auf meinem Secrets gerade völlig vertauscht.

Das ist gar nicht die Bibliothek, die den fertigen Algorithmus nimmt, sondern die generiert dir ja erstmal nur den Zufall darunter.

Und generiert erstmal nur zufällige Werte.

Die richtige Bibliothek, um halt Passwörter zu herrschen, wäre sowas wie B-Crypt.

Da haben wir das auch noch eingepackt.

Ja, schön, dass ihr alle dabei.

Danke, Philipp, dass du Zeit gefunden hast für uns.

Ja, voll gut.

Eine sehr interessante Episode.

Ja, auch finde ich sehr interessant.

Ja, vielen Dank, dass ich dabei sein dürfte.

Ja, ich auch doch.

Wenn ich noch einmal ganz kurz Werbung machen darf, bei Boxine suchen wir immer Python-Entwickler.

Oder was ist immer, aber aktuell suchen wir auf jeden Fall Python-Entwickler oder auch Leute, die mit Java oder mit JavaScript arbeiten, speziell mit React.

Also wenn ihr ein guter Entwickler seid, vielleicht sogar im Raum Düsseldorf oder auch nur ganz grob in NRW irgendwo, dann meldet euch bei Boxine, die Tonibox zu programmieren, macht wirklich, äh, oder die Dienste rund um die Tonibox zu programmieren, macht sehr viel Spaß, ist total toll zu wissen, okay.

Jede Nacht gehen tausende oder Millionen Kinder mittlerweile mit der Tonibox in Schlaf und wir machen gute Dienste, die hoffentlich den Eltern das Leben einfach machen und dafür sorgen, dass die Kinder gute Geschichten hören.

Danke.

Das war die erste Werbeanzeige im Python-Procast.

Ja, ne, aber also ich kann nicht nur, also finde ich ja.

Könnt ihr rausschneiden.

Nein, nein, nein, das finde ich super.

Also Tony Box ist eine gute Sache.

Ist ein schönes Projekt hier aus der Gegend.

Ja.

Ja.

Ja, alles klar, dann würde ich sagen.

Ja, vielen Dank, Philipp.

Und bleibt uns gewogen.

Egal wann ihr uns hört.

Schaltet wieder ein.

Morgens, mittags, abends, tags, nachts und zum Einschlafen ist auch immer super.

Ja, liebe Grüße und bis zum nächsten Mal.

Ciao.

Ja, tschüss.