Ashley: Wir kommen uns der nächsten Ausgabe des Taktsoft Campus Podcast. Schön, dass ihr wieder dabei seid. Im Podcast Folge 6 sprach ich mit Ben Fuhrmannek über eine praktische Einführung in die Web Security. Wir haben viele Themen wie Angriffsarten und sicherheitsrelevante Bereiche diskutiert. Damals haben wir beide gesagt, dass wir nur die Spitze vom Eisberg angerissen haben, und bevor eine weitere Podcast aufzunehmen. Ich freue mich, dass wir dies heute tun. Wir wollen das Thema Code, Analyse und Sicherheit diskutieren. Ich freue mich auf das Gespräch. Ja. 
Ben: Hallo, schön, dass ich noch mal da sein darf! 
Ashley: Würde ich gerade sagen. In so in so einem letzten Podcast haben wir beide zum Schluss gesagt, da gibt's genug Themen, die wir ansprechen können, und eine Folge zwei wäre interessant, und jetzt treffen wir uns, und wir machen die Folge zwei genau so in der ersten Folge. Wir hatten, ich sag mal so, die Einführung von Web Security angerissen. Wir haben dann über verschiedene Sachen gesprochen. Kannst du vielleicht kurz kurz ein Recap machen? Aber wir haben auch beide gesagt, ein Mann, das ist dann nur der Spitze von Eisberg, das, was wir angesprochen haben, und es gibt sicherlich viele andere Themen, die wir vertiefen können, ja vielleicht dann zum Anfang. Magst du mal kurz so zusammenfassen. Ich sage so diese Hauptpunkte, die wir im ersten Podcast angesprochen haben. 
Ben: Ja, sehr gerne, es geht erstmal um die Sicherheit in Webanwendungen, also es geht darum, wie bekomme ich meine Webanwendung sicher, beziehungsweise der lustige, spannende Teil, den ich normalerweise übernehme? Wie kann ich diese Schwachstelle finden? Wie kann ich herausfinden, ob die Anwendung eigentlich noch mehr kann, als sie eigentlich soll, nämlich wie findet man die Schwachstellen? Ja, wer bin ich denn überhaupt? Ich bin bin Furmanek, ich mache das hauptberuflich, ich suche Schwachstellen, und ich habe schon ein bisschen davon erzählt. Im ersten Teil des Podcasts, der war am vier Dezember, wurde der, glaube ich, veröffentlicht. Das ist Folge sechs. Wer das nochmal nachher möchte, dass der Zeitpunkt, kurz auf die Pause Taste zu drücken, und zu sagen sechs, die kenne ich noch gar nicht einmal anhören, das dauert nur eine halbe Stunde, und dann kann man genau an dem Punkt wieder anknüpfen. Das lohnt sich wirklich. Ich habe dann selbst zur Vorbereitung gerade auch noch einmal gehört, und ich habe mich prächtig amüsiert. Was haben wir da besprochen? Wir haben erstmal besprochen, wie sieht denn eigentlich eine Anwendung aus? Was, was kann man denn? Wie kann man sich das vorstellen? In Web browser? Man hat eine Serverseite, dazwischen laufen Daten, und dann haben wir den Angreifer. Der Angreifer sitzt im schlechtesten, also im besten Fall für mich, aber im schlechtesten Fall für den Anwendungsentwickler, sitzt ja genau dazwischen zwischen dem Webbrowser und der Anwendung oder zwischen der Anwendung und einem anderen Kommunikations Endpunkt von der Anwendung zum Beispiel, was ich, irgendwie ein Dienstleister, wie auch immer, so dass man die Kommunikation abfangen, abhören kann, modifizieren kann. Das ist der schlechteste Fall, und den möchte der Angreifer ausnutzen. Dann haben wir bisschen darüber gesprochen, wie man das denn machen würde, beziehungsweise wir haben darüber gesprochen und wie ich das machen würde, wenn ich beauftragt werde, von einer Firma ein Antest durchzuführen. Also ich tue so was, ob ich ein Angreifer wäre, und dann dann geht es los, und das ist natürlich nur die halbe Arbeit, die die andere Hälfte wäre gewesen, dass ich mit dem Kraut ankomme. 
Ashley: Ja, das ist natürlich ein Thema, die Code auszugeben, auszugeben. Aber ich denke, wenn ein Unternehmen wirklich Interesse daran hat, alle diese Analyse zu machen, sind die natürlich mit den entsprechenden Dis gerne bereit. Das machen wir. Zum Schluss bekommen die auch ein Mehrwert durch diese. Durch diese Analyse gehen wir dann davon aus, ich habe die unterschrieben, ich habe mal eine schöne Anwendung oder was auch geschrieben. Wie geht man dann an so eine Quellcode Analyse? Auch für mich? Es gibt verschiedene Programmiersprachen. Wie kann man dann so eine Quellcode Analyse dann machen? 
Ben: Hm, ja, das ist die spannende Frage. Das erste, was ich mache, ist, ich starte meine Entwicklungsumgebung, genau das, was auch der Entwickler tun würde. Ich starte meine Entwicklungs, lade den Code rein und gucke, was passiert, und und in den meisten Fällen sagt mir die Entwicklungsumgebung selbst schon, an diesen und folgenden stellen müsste man mal auf den Gucken. Das sieht nicht so aus, als ob das richtig wäre, so, und das müsste der Entwickler an der Teller auch sehen. Ich bin ja nicht der einzige, der die Meldung sieht. 
Ashley: Genau das wollte ich gerade sagen. Muss der Entwickler nicht selbst das sehen, bevor er dann sagt, okay, ich bin mit meiner Entwicklung jetzt fertig? 
Ben: Ja, also wie das, wie das manchmal so ist, aber das denke ich mir dann auch, das ist jedenfalls also false well, wo es so aussieht, und das ist schon relativ häufig der Fall. Dann ist das ein sehr, sehr guter Anhaltspunkt. Dann fange ich genau an den Stellen an und sage, okay, was sagt mir denn die Idee, die sagt, oh, das darf kein Trading haben, oder hier ist irgendwie eine Eingabe, die es ungesichert, oder diese und jene Kommentare müsste man rauslöschen, auch sehr schön sind das du das, und das muss noch gemacht werden, dann weiß ich, dass es fehlt, wenn es eine Sicherheitsmaßnahme ist oder lustige Kommentare im wie. Das sollte man eigentlich anders machen, oder der Praktikant hat das mal eben geschrieben. Aber es läuft halt, und was man alles! 
Ashley: Und das sind, das sind tatsächlich Sachen, die du mit deiner Erfahrung gesehen hast. 
Ben: Solche Beispiele, ja, es geht noch weiter. Also das geht bis dahin, dass man gar keine Kommentare braucht und sofort sieht, wo das Problem ist. Ich hoffe natürlich immer heimlich, dass es besonders schöner, hübscher Code ist, und dann ist es für mich besonders schwierig, also besonders einfach, den zu lesen, aber besonders schwierig, Sicherheitslücken zu finden, ähm, ja, das ist, das ist auch schön. Aber besonders schön ist es natürlich, wenn ich auch welche finde, mit denen der der Entwickler nicht gerechnet hätte. Genau und genau die Idee ist eine Sache. Angenommen, der Entwickler hält sich nun an die Vorgaben der Idee, und dann dann geht es also, dann hat man einige als einen hübschen: Sag ich mal, dann geht es nur noch um die Architektur, was ich, was ich speziell für die Sicherheitsanalyse mache. Ich gucke mir erst mal an, wo kommt denn Daten rein? Wo ist die Eingabe in die Anwendung des? Das sind meistens Eingabefelder, wenn es um Webanwendung geht, aber es könnten beliebige Eingaben sein, also was ich hochgeladene Dateien auf beliebige Art und weise, nicht nur. Oder? Vielleicht werden Daten verarbeitet, die per Server hochgeladen werden. Vielleicht ist es eine Anwendung, die Telefonanrufe entgegennimmt, dann gibt es eine Schnittstelle zur Telefonie. Da sind Benutzereingaben. Der Benutzer kann definieren, wie ist denn seine eigene Telefonnummer mit der Anruf? Das ist eine Benutzereingaben. Aber alle diese Eingaben nehme ich und gucke erst mal, was passiert. Damit gibt es eine Eingabe, Validierung, das hatten wir letztes mal schon so ähnlich. Da sollte man beim Pentest überlegen, ist es denn sinnvoll, was ist? Ich gebe sie, Alter, ein Minus, 83 ergibt keinen Sinn. Genau diesen muss ich natürlich finden. Da muss irgendwo eine Zeile sein. Alter wird jetzt geprüft nach Länge, Wertebereich und so weiter, Zeichenvorgaben, das erst mal nicht zu finden ist, oder wenn es nicht da ist, oder wenn es offensichtlich da steht, dieser Teil fehlt noch, du du, naja, dann weiß ich, der Fehlt. Dann kann ich gucken, ob da ne Fachstelle sich ergibt. Das muss so nicht sein. Es kann auch sein, dass es keine Schwachstelle ist, aber das ist schon mal ein ganz guter Anhaltspunkt. Und dann im zweiten Schritt überlege ich mir ja, was passiert denn nach der ganzen Business Logik? Was passiert nach der Verarbeitung? Die Daten werden ausgegeben, so entweder da werden die zum Benutzer ausgegeben, oder die werden in eine Datenbank geschrieben, oder die werden in irgendwelche als eingebaut und weggeschickt, oder die werden abgespeichert in Dateien oder wo auch immer. So je nachdem, welche Ausgabe das ist, müssen die Daten dann entsprechend behandelt werden. Das muss ich im Quillt natürlich sehen. Das ist sehr, sehr einfach zu sehen. Man guckt einfach, da sind die Daten. Wie werden die gespeichert? Was passiert vorher damit? Das müsste der Entwickler eigentlich auch sehen. 
Ashley: Ja, aber wenn ich kurz mal eine Frage stellen darf, so ich bin kein Entwickler, aber ich sag mal so, das sind nicht zehn Zeilen, das sind nicht Hunde, Zahlen, das sind Tausende von Zeilen von Quellcode, und ich stelle mir einfach mal die Frage, und auch komplex war, das sind komplexe Anwendung, die gebaut werden, und ich stelle mir einfach die Frage, wie kannst du aus? Du bist zwar Entwickler, hast du aber dieses Ode nicht entwickelt, das heißt, du bist mit diesem nicht vertraut? Wie lange brauchst du dann überhaupt, dann dich, ich sag mal so, reinzudenken, reinzulesen und überhaupt die Stellen zu finden? Klar, wenn es gut kommentiert, ist ein hohes, wie du das, wie du gerade gesagt hast. Es ist vielleicht ein bisschen bisschen in Anführungsstrichen einfacher, aber wie lange brauchst du, um überhaupt überhaupt reinzukommen, um erst mal diese Stellen zu finden, Eingabe, Ausgabe, Datenbank weg schreiben und so weiter, um überhaupt diese Sachen zu finden? Das stelle ich mir als erst nicht Entwickler wirklich schwierig vor. 
Ben: Ja, danke für die Frage. Also als als nicht Entwickler kann man, kann man sich das vielleicht auch vorstellen. Gibt es nämlich eine eine Suchfunktion in dem Text Edit, dann sucht man einfach danach, also viel schwieriger. Das ist tatsächlich auch nicht schwieriger. Also, es gibt einfach Funktions, Funktions, Namen. Die heißen dann genauso wie das, was ich gerade suche. 
Ashley: Also okay, das ist dann wirklich dann zu sagen, du suchst eine Eingabe oder Validierung oder Prüfung oder solche Sachen verschlüsseln, und anhand von dieser Schlüsselworte findest du dann die entsprechenden Zahlen, wo du dann wirklich tiefe reinschauen. 
Ben: Das ist, das ist tatsächlich die Vorgehensweise. Es verliert natürlich nach der Größe. Also wenn ich eine Einwendung habe, die einigermaßen klein ist, dann gucke ich mir den kompletten Code an, dann kann ich natürlich auch die Suchfunktion verwenden, aber es ist nicht mehr unbedingt erforderlich. Ich kann einfach den kompletten Code lesen. Die meisten kleineren Anwendungen sind übersichtlich genug, um einfach den den ganzen zu sehen. Es kommt vor, dass große Konzerne große Basen haben, und dann dann muss ich mir eine andere Strategie überlegen. Der Kunde kann schließlich nicht, sage ich mal, 100 Tage bezahlen, dann dann mache ich ein Stichproben Audit. Also ich suche mir genau die Teile raus, von denen ich meine, dass die wahrscheinlich relevant oder brisant sind oder sicherheitsrelevant, und die Gucke ich mir an, sage dann dem Kunden, das war nur Stichproben da. Der hat unter Umständen noch mehr Probleme der Art. Aber hier ist ein kleines Beispiel, und so kann er das finden, und so kann er das beheben. Das ist meistens ganz okay. Was ich tatsächlich mache, ist, ich gucke mir den Kurs selbst an. Also es gibt, es gibt Tools, mit denen man analysieren kann: statische Code, Analyse tools, die Kosten, auch unendlich viel Geld. Wenn es große Konzerne sind, die wir als Kunden haben, dann kommt es durchaus vor, dass die Kunden selbst solche Tools haben und die Tools schon drüber liefen, über den als Ergebnis kommen dann weiß ich nicht 200 Seiten pdf raus. Die spannende Aufgabe ist es dann herauszufinden, welcher dieser Findings aus dem statischen Analyse Tool relevant sind. Das heißt, meistens bekomme ich dann auch den Bericht. Dann kann ich sagen, ja, irgendwie diese drei Teile von den 200, die, die könnten schon relevant sein, dann gucke ich mir das nochmal genauer an. So als als grobe Regel kann man sagen, je nach Programmiersprache natürlich, aber so 10000 Zeilen pro pro Tag lassen sich schon angucken. Das variiert immer je nachdem, wie der Schreibstil ist, von dem Entwickler, je nachdem, wie die, wie die Regeln sind, wie schön man den guten schreibt, und das hängt an ganz vielen Faktoren. Angenommen, es ist ein komplexer Algorithmus, den kann man auch in 20 Zeilen sehr komplex schreiben. Aber so ganz grob für Webanwendung sage ich ganz grob, 10000 Zeilen, das ist schon machbar, wenn man etwas sportlich drauf ist. Ja, das heißt, wenn man, was ich 50000 zeilen hat, ohne Kommentare natürlich und ohne Leerzeilen, dann schafft man das schon an fünf Tagen zu analysieren. Das ist, das ist ganz grob, und wenn es mehr ist, dann muss man eine Stichprobe machen. 
Ashley: Nee, das ist aber gut. Es gibt so ein bisschen Gefühl, für wie viel aufwand man reinstecken muss, um diese Analyse zu machen. Das war aber meine Frage ist. 
Ben: Wurde ja, gelegentlich kommt es auch vor, dass wir uns auf uns kommen und sagen, eigentlich möchte ich die Sicherheit gar nicht analysieren, sondern ich möchte nur wissen, ob der Code hübsch ist. Dann dann machen wir eine Qualitätsanalyse. Das kam jetzt zwei, dreimal vor. Das ist meistens der Fall, wenn eine Firma eine andere Firma kauft oder wenn eine Firma ein Produkt einer anderen Firma übernehmen möchte, und die wollen natürlich nicht die Katze im Sack kaufen, sondern die wollen, dass man dritte draufguckt, der sagt, eigentlich benutzt man doch strukturierte Programmierung, und zwar nach nach folgenden Messwerten haben wir das analysiert, und dann dann mache ich das natürlich auch. Das ist auch mal sehr schön, vor allem, wenn es nicht eingehalten wird. Wurde aber na ja, es wird besser, zum Glück wird es besser, sage ich mal. Ich beschäftige mich eigentlich lieber mit Themen, die besonders knifflig sind, als mit mit Themen, die ein Tool auswerten kann. 
Ashley: Ja, dann lass uns dann wieder nicht die Qualitätsthemen, oder sonst springen wir wieder den Rahmen und gebe mal zurück: Okay, dann dieses Thema Analyse, wie du vorhin gesagt hast, dann dann suchst du, und du analysierst dann bestimmte Bereiche im, wie das halt geschrieben ist. 
Ben: Ja, ja, was, was ich speziell analysiere, sind Sachen wie Eingabe, Behandlung, Ausgabe, Behandlung. Natürlich, bei der Eingabe Behandlung kann man sofort sagen, wenn an einer Stelle steht, die ist die Eingabe, Behandlung für die kompletten Daten, und es werden, was ich, alle Zeichen ausgefüllt hat, dann kann ich schon von vorne rein sagen, da hat sich jemand das Leben zu einfach gemacht. Das ist wahrscheinlich ein Fehler. Oder wenn, wenn jemand sagt: Okay, folgende Zeichenketten sind wahrscheinlich problematisch, und die werden herausgefiltert. Das ist der black listing Ansatz, würde ich erst mal sagen. Moment, ich kenne noch eine weitere Zeichenkette, die auch problematisch ist, so dass dieser Ansatz wahrscheinlich nicht funktioniert. Also, das ist auch, wenn ich, wenn ich Schulung halte, ist das so die die erste Erkenntnis, die ich versuche zu übermitteln blacklist Weise. Wie ist also, der Ansatz ist eigentlich immer der der richtige? Man sagt: Okay, die Eingabe und die Eingaben sind erlaubt, dann prüft man, ob es oder ist, und man prüft nicht, ob es alle anderen Eingaben sind. Das ergibt erst mal keine sein. Es ist meistens nicht so furchtbar einfach, wie ich das jetzt ausdrücke, aber im Detail kann das schon sehr einfach gemacht werden. 
Ashley: Aber das ist dann wirklich, ich sage mal so, wirklich eine spezifische Punkte, die die Zuhörer da mitnehmen sollen, wie Last anstatt Blatt lässt. 
Ben: Ja, ich, ich mache mir natürlich im Podcast das Leben ein bisschen einfacher. Die, die Details, die Details muss man auch noch mal angucken. Ja, es, es gibt einen Punkt, den ich mir im Pentest weniger angucken kann, aber im Quellcode einfach sehe, und das ist die ganze Thematik und Passwörter. 
Ashley: Immer ein heißes Thema. 
Ben: Ja, also letztes mal hatten wir schon die die übliche Koffer Kombination eins, zwei, drei, vier, das ist die Frage, die also bei Passwörtern stellen sich mehrere fragen, da gucke ich mal auf meine Aufzeichnungen. Natürlich braucht man eigentlich Passwörter, und wie werden die egentlich generiert? Wer gibt die ein? Wie spricht man die? Wie überträgt man die? Das ist, das ist eigentlich, wenn man sich, wenn man sich das überlegt und überlegt und einfach hemmt, ärmlich sagt: Okay, ähm, ich denke mir mal irgendwas aus und mach das. Dann ist es wahrscheinlich schon fast richtig. Man kann es sich aber nochmal genauer überlegen. Also, die Frage, braucht man eigentlich? Passwörter? Haben also moderne Firmen der Web Industrie inzwischen beantwortet mit ja, aus traditionellen Gründen. Nehmen wir mal, benutzen ein Passwort als Schema, um den Benutzer zu authentifizieren, aber es wäre doch schön, wenn er noch einen zweiten Faktor hätte, sowas wie ein Telefon oder bestätigt. Ja, ich will mich wirklich einloggen oder ein, irgendeine Art Hardware oder ein USB Dongel oder irgendetwas, wo man dann sagt, ja, ich möchte mich wirklich einladen, ich bin das wirklich, dass es nicht nur nur am Passwort hängt, Passwort alleine, aber meistens ja nicht, dass es nicht. 
Ashley: Tatsächlich, ja, ich sag mal so, meine Erfahrung ist auch, ich sag mal so, online Banking gibt es immer factor authentication oder auch, wenn ich mich einlogge, in bestimmten Firmen Netze gibt die, die generiert werden. Das scheint jetzt, ich sag mal so gang und gebe zu sein heute, dass man nicht nur auf auf dem Passwort sich drauf verlassen verlassen kann. 
Ben: Ja, genau, es gibt auch. Es gibt auch so lustige Schemata. Wie klicken sie ihre Freunde an? Ich glaube, Facebook hat, als wenn man sein Passwort vergessen hat, und wenn jemand also gründe hat, die er identifizieren kann, dann kann ja auch seine Freunde klicken. Wenn jemand Öl, ich Fremdes versucht, diese Funktionen zu nutzen, dann kennt er natürlich nicht die Gesichter und kann nicht darauf klicken. Das ist die Idee, warum nicht? Das kann man machen, oder Schema mit Sms oder mit e Mail, das ist natürlich nur so und so sicher, aber es ist besser, als nichts zu haben. 
Ashley: Mhm, ja. 
Ben: Ja, genau das sehe ich jedenfalls im Feld kurz. Sehr, sehr gut. Was, was haben die denn? Haben die nur einen Faktor? Gibt es nur ein Passwort? Gibt es mehrere Passwörter, die man irgendwie haben muss? Dann dann gucke ich erstmal, wie werden denn wir, werden, den ich, Passwörter eingegeben, und man kennt das von von neuen Accounts, die man irgendwo erstellt. Ja, geben sie jetzt ihren Benutzernamen, das ist inzwischen meistens die E Mail Adresse, ein, und dann geben sie noch irgendein Passwort ein. Das ist nicht selbstverständlich. Es gibt auch Systeme, die einfach ein Passwort generieren. Dann muss man sich überlegen, wie, wie werden denn die Passwörter generiert? Kann der kann der Angreifer vielleicht auch ein Passwort generieren, dass genau dasselbe Passwort ist, weil er irgendeine Zusatzinformation hat, nämlich wie die Passwörter generiert werden? Das ist ein Co, den ich einfach nachschlagen kann im Quellen. 
Ashley: Wie kommt? Wie kommt dann der Herr dran, dass er weiß, wie die Passworte generiert werden? In diesem Beispiel, was du gerade gemacht hast, woher weiß er das denn? 
Ben: Ja, das ist die große Frage. Woher weiß der Hacker, was er tun muss, um um das Passwort zu generieren? Und ein ein großer Vorteil ist, es wird ganz viel Open Source verwendet. Man kann einfach in der Bibliothek, im Framework nachgucken, wie der Algorithmus ist. Es würde auch der Sicherheit nicht helfen, wenn der Angreifer diese Zusatzinformation nicht hätte. Das wäre dann Security bei Obscurity. Der könnte raten oder könnte mal ein Praktikum bei der Firma gemacht haben, dann wüsste er es. Also, das ist eine Information, die eigentlich öffentlich sein könnte. Was hilft es, wenn man besonders sicheren Zufall hat? Man kann sich vorstellen, wenn man Passwörter zufällig generieren möchte, dann braucht man einen Zufall, der nicht erraten werden kann. Bei Computern hat man meistens einen Pseudo Zufall mit einem Pseudo Zufallszahlen Generator. Ja, der Pseudo Zufallszahlen Generator wird initialisiert mit einer Zahl. Das heißt, wenn ich meine, zum Beispiel der ist oder irgendein Algorithmus, wenn ich den investiere mit sagen wir der fünf, und ich generiere drei Zufallszahlen, und dann initialisiert ich dir noch mal mit der fünf, dann bekomme ich bei den nächsten drei Zahlen wieder dieselben drei Zahlen wie vorher. Das ist eben kein echter Zufall, dass es ein Pseudozufall, der an dem Startwert liegt. 
Ashley: Mhm. 
Ben: Genau wenn also der Angreifer diesen Startwert kennt, dann kennt er damit automatisch alle Passwörter, die generiert werden, und das ist gar nicht so unwahrscheinlich. Da gab es in der Vergangenheit sehr, sehr viel Software, die genau diesen Fehler gemacht hat. Also der Fehler war, es wurde ein Pseudo Zufallszahlen Generator genommen. Der wurde initiiert mit einem Wert, den der Angreifer kannte, zum Beispiel die aktuelle Uhrzeit. Der Angreifer weiß, wann er auf den Knopf klickt, wie viel Uhr es da war, oder er kann erraten, wann beispielsweise die Anwendung gestartet wurde. Wenn das nicht so furchtbar unwahrscheinlich ist, dann wurden die Accounts rein Weise übernommen. Unter Umständen bekamen dann die eigentlichen echten Benutzer eine E Mail, ihr Passwort wurde zurückgesetzt, aber die konnten sich dann trotzdem nicht mehr einloggen, weil der Angreifer schon Naja das Passwort hatte und sich eingelassen. Also das war dann schon zu spät. 
Ashley: Mhm. 
Ben: Das, das sollte man beachten, und das kann ich im Kurs sehr, sehr gut sehen und dann sagen, ja, könnte man vielleicht so oder so anders machen. 
Ashley: Mhm. 
Ben: Ja, dann ja. Wenn, wenn der Benutzer das Passwort eingibt, dann gibt es so übliche Ampelschema, dass man sagt, ja, das Passwort wird erst mal als sicher erachtet oder nicht. Da gibt's auch ne, ja Bliothek, die man einfach einläd, oder mehrere. Das ist natürlich nur ein ein Anhaltspunkt. Eine Bibliothek kann nicht sagen, ob das Passwort sicher ist. Es könnte zum Beispiel der Name der Katze sein und irgendwelche zahlen, und dann sagt das System ja, sieht sicher aus. Aber trotzdem könnte es sein, dass der Angreifer das Passwort kennt. 
Ashley: Ich habe neulich gesehen, dass war, glaube ich, ein Poster auf Facebook, wo es dann immer die Fragen gibt: Mädchen, deiner Mutter, bist du geboren? Und die Polizei hat sogar auf diese Post geantwortet und hat einfach geschrieben: Stopp, gibt nicht solche Informationen, einfach mal so her! Weil es hört sich an wie so ein lustiges Spiel. Man gibt die Information, aber das sind genau diese Sicherheitsfragen. Wenn du so ein paar machen würdest, dann hast, das weiß ich, aus zehn fragen wird man fünf, fünf aus ja, wo bist du geboren? Wie gesagt, Mädchen, Namen der Mutter, und dass das jemand so über so eine soziale Netzwerk auch solche eigentlich sicherheitsrelevante Informationen sammeln kann. 
Ben: Ja, das ist eine schöne Anekdote. Darum verwende ich gerne zufällige, werte das. Das macht sich besonders gut, wenn die telefonisch übertragen werden müssen. Also, da hatte ich mal vor ein paar Jahren einen Kollegen, der wollte sein Passwort zurücksetzen, auch zufällige Werte genommen. Dann meinte die Person am anderen Ende ja, sagen sie doch mal ihr, was ich, ihre Geburtsstadt, was haben sie denn eingegeben, und dann soll man eben 32 Zeichen oder 64 oder wie viel auch immer zufällige Zeichen durchgeben, eins, drei, Punkt, minus 13 und so weiter. Das funktioniert natürlich übers Telefon nicht so furchtbar gut. Das hat dann die Frau auch eingesehen und trotzdem das Passwort zurückgesetzt. Damit war der komplette Mechanismus hinfällig. Ja! 
Ashley: Eine gute Anekdote, ja! 
Ben: Ja, also, so passiert das manchmal. Naja, ich, ich hatte auch ähnliche Ereignisse. Bei bei einem Kunden gab es eine Festplatten Verschlüsselung für den für den Laptop der Firma. Als ich den frisch bekam, wusste ich nicht, wie man diese Festplatten Verschlüsselung Naja aufmacht. Mit meinem Passwort, das ich noch nicht hatte, konnte ich das nicht tun. Dann gab es noch Hotline. Bei der Hotel habe ich angerufen und gesagt, ja, ich möchte bitte, ich bin der legitime Benutzer. Ich möchte das jetzt bitte benutzen. Dann muste ich ne lange Zeichenkette durchgeben. Die haben wir eine lange Zeichenkette zurückgegeben. Dann konnte ich den Laptop benutzen. Das war die Festplattenverschlüsselung, und als Authentifizierung musste ich sagen, ja, ich darf das ja. 
Ashley: Es ist immer wieder sehr schön, immer wieder der Faktor Mensch. Wir hatten auch in einer Podcastfolge von Hausen gesprochen, und eigentlich in diesem Podcast ging es genau um solche Themen. Das, Sicherheit ist nicht nur eine technische Aufgabe, sondern auch der Faktor Mensch. Man kann das total System, das sie das System bauen, aber wenn Menschen nicht richtig damit umgehen, ist das ganze Thema Sicherheit dann wirklich wirklich gefährdet. Das ist im Prinzip auch, was du in deinem deinem Beispiel gesagt hast, ja, für mich immer noch ein Wahnsinns zierte Vorgehensweise, nicht Entwickler. Aber ich glaube dir, dass die fünf Tage, die du vorhin gesagt, dass sie auf jeden Fall machbar sind. Aber diese ganzen Sachen, die du gerade angesprochen hast, auch mit dem Thema werte und so weiter, gibt es dann irgendwie, ich sag mal so, Hauptpunkte oder Empfehlungen, wo du sagst, wenn du Code schreibst und dieses sicher sein soll, achtet darauf ab. Gibt es dann so ein paar paar Themen, wo du sagst, das sind wirklich die muss, wo einem Wickler sich darauf konzentrieren soll, mhm. 
Ben: Ja, die Frage ist schön provokativ gestellt. Wenn es darauf eine Antwort gäbe, dann hätte ich keinen Job mehr. Das, das wäre also die perfekte Antwort. Das ist deswegen deswegen. Das ist eigentlich auch der Plan für meine berufliche Zukunft, dass ich meinen eigenen Job abschaffe, indem alle Softwareentwickler Sicheren schreiben. So bisher ist das nicht passiert, und selbst dann finde ich mit Sicherheit spannende Themen aus der it security. Aber bisher bleibt es spannend. Das heißt, die, die Empfehlung an die ganz grobe Empfehlung ist, natürlich, soll man halt sicher entwickeln. Also man soll immer Eingabe, Validierung verwenden, Ausgabe, Behandlung, und vor allem, man muss sich weiterbilden ohne Ende. Also, es gibt, es gibt jeden Tag bekannte Schwachstellen, also Schwachstellen, die bekannt werden an dem jeweiligen Tag zu beliebiger Software. Natürlich kann man das nicht alles überblicken. Ist reicht. Die Software, die man gerade verwendet, sollte man im Auge haben. Wenn es neue Versionen gibt, warum gibt es da eine neue? Es sind, gibt es da nur Features, oder gab es da auch Probleme? Sind die Probleme vielleicht sicherheitsrelevant? Manchmal steht da auch nicht dran, da steht ja nur, da wurde irgendwie einen Punkt oder ein Komma vergessen. In Wirklichkeit war das ein Sicherheitsproblem. Also, teilweise muss man da ein bisschen zwischen den Zeilen lesen und sagen, moment, wenn das so ein dringliches Abda ist, und dann steht in der Beschreibung nicht drin, warum das so dringlich ist. Da muss man doch noch mal genauer hingucken und sich auf die Weise weiterbilden und sagen, okay, ich spiele das mal ein. Aber ich merke mir mal, das ich in zwei Wochen nochmal nachgucken, ob es vieleicht eine bessere Beschreibung gibt oder ob es nicht was gibt, um, um diese Schachstelle auszunutzen. Das, das ist schon wichtig. Ja, man muss immer viel lesen. Was man sowieso als Entwickler liest, sind natürlich die üblichen ins, nehme ich an, sowas wie his Spiegel, Netzwelt oder von mir aus selbst Twitter, twitter streams oder die Zeit hat auch so eine Rubrik Haus, was man alles findet. Es gibt eigentlich keine schlechten Ressourcen im Internet, es gibt nur gute Ressourcen. Sobald es Informationen gibt, kann man sehr, sehr einfach feststellen, ob die Informationen sinnvoll sind oder nicht, und dann kann man sagen, okay, das war eine sinnvolle Information, mit der kann ich irgendwas anfangen. Das geht. 
Ashley: Ja, das heißt, es ist wirklich ein ständiges, ein ständiges Prozess. Nicht, man macht es einmal, und dann bin ich sicher oder was sicher? Sozusagen. Aber, wie du sagst, ständige Weiterbildung, und wenn es dann irgendwie neue Libs, Bibliotheken, die zu Verfügung stehen, nicht einfach mal so die Dinge nehmen, aber wirklich dann zu überlegen, okay, wie prüfe ich denn noch, dass das, dass die Sicherheit dann nicht beeinträchtigt wurde? Ich glaube, ich glaube, du weißt, was meine letzten oder meinen nächsten Satz sein wird, also der der erste erste Volker, ich sag mal so, eher hauptsächlich das Thema Pentest Penetrationstesting. Dieses Mal haben wir uns das Thema croce Analysen, auch, wie du sagtest, auch das Thema oder Thema Passwörter mal tiefer angesprochen. Ich glaube, es wird eine Folge drei geben, oder ich würde mich freuen. Und was, was würdest du dann aus dieser dieser Reihe von Themen, die man insgesamt hat, für eine Vorge dreimal vorschlagen? Was wäre dann der nächste Punkt nach Pentesting, nach Kurorte Analyse? Was wäre dann der nächste, interessante sicherheitsrelevante Bereich für den Webentwickler mal anzuschauen? 
Ben: Ja, das ist natürlich eine Frage, die jeder für sich beantworten muss. Was interessiert mich eigentlich gerade im Moment? Angenommen, jemand entwickelt gerade sehr viel, sagen wir react framework, und dann kommt jemand und sagt ja, ich spreche aber Passwörter sicher. Das passt nicht so richtig zusammen. Aber es gibt, es gibt ein Thema, das generell auf Sicherheitsfragen die Antwort gibt. Das ist praktisch die Antwort, die ich eigentlich geben wollte auf die vorherige Frage. Was, was macht man, was ist denn eigentlich die eine Sache, die man jetzt eigentlich machen muss? Da gibt es tatsächlich eine, ich sage mal ein bisschen knie Flieger, Antwort, und ich hoffe, dass wir nochmal zusammenkommen, um diese Frage genauer zu betrachten. Und zwar gibt es den Security Development life, sie so heißt. Das ist die Frage, die Microsoft sich gestellt hat im Jahr 2002, was also, wie kann man denn jetzt die Software sicherer schreiben? Also Microsoft, diese große us amerikanische Konzern, der bekannt dafür war, blue screens auf Windows zu erzeugen, wenn man gleiche Geräte per USB einsteckt? Und überhaupt war eigentlich die komplette Software verschrieben, sage ich mal, wurde aber doch viel gekauft und viel verwendet. Das heißt, es gab viel Geld, und das Geld durfte man ausgeben. Das ist genau das, das ist so das Szenario, und ich hoffe, dass wir beim nächsten Podcast die Gelegenheit haben, das Thema genauer zu betrachten. 
Ashley: Das hat sich gut an. Ich würde mich sehr freuen, wenn wir das organisieren können. Ich gehe davon aus, dass wir das hinkriegen werden. Super! Vielen Herzlichen dank! Wieder einen super spannenden Podcast, und ich glaube, vor drei, vor ungefähr vor fünf könnten wir mal machen, weil die Systeme so so ein breites Spektrum abdeckt. Aber jetzt sage ich herzlichen Dank für die Zeit, und ich freue mich auf Folge drei! Vielen dank. 
Ashley: Taktsoft Campus Podcast! Der Podcast für Software und IT Professionals. Im Taktsoft Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxis fragen zu Technologie, aber genauso fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass ihr dabei wart. Euer Taktsoft Campus Podcast Team!