1991-1996: Studium der Naturwissenschaftlichen Informatik an der Universität Bielefeld. Abschluss mit der Diplomarbeit zum Thema 'Analyse von ein- und mehrdimensionalen Zeitreihen mit der Karhunen-Loève- und Wavelet Transformation'
||
1996-1997: Wissenschaftlicher Mitarbeiter am Lehrstuhl Prof. A. Knoll in der Technischen Fakultät der Universität Bielefeld im Projekt 'LANeCo: Local Area Net Configuration'
||
1998- 2018: Tätigkeit im BIS - Bielefelder Informationssystem an der Universität Bielefeld
||
Seit Oktober 2018: Leitung der Abteilung Informationssysteme und Prozessunterstützung im BITS
ANTRL – ANother Tool for Language Recognition – ist ein leistungsfähiges Werkzeug um Lexer und Parser aus einer Grammatik zu generieren, mit denen sich dann die so definierte Sprache verarbeiten lässt. ANTLR kann den Parsercode in verschiedenen Zielsprachen generieren, ist aber selbst in Java geschrieben. Es sollte sich daher direkt in ein Java Projekt mit Maven Build integrieren lassen.
Da es mich dann doch einige Zeit mit Google und ChatGPT gekostet und am Ende noch einen Blick in den Quellcode erfordert hat um herauszufinden, wie das genau funktioniert, will ich das hier einmal aufschreiben. Aber zunächst zwei Video Empfehlungen:
Es soll ein JAR aus dem Projekt herausfallen, welches als Abhängigkeit in einem größeren Projekt genutzt wird. Ziel ist es dabei, den aus der Grammatik erzeugten Parser direkt mit Code zu verknüpfen, der ihn konkret einsetzt. Also muss der ANTLR Code im Idealfall im Verzeichnis liegen, welches Maven für die Quellcodes verwendet. Das Projekt hat grundsätzlich eine Standardstruktur mit separaten Verzeichnissen für die ANTLR Bestandteile:
Der Begriff ‚aappro‘ kommt aus dem konkreten Anwendungsfall, der mit der Approbationsordnung für Ärzte (ÄApprO) zu tun hat.
Anlage der Grammatik
Für die Grammatikdatei legt man unter main/ einfach den Ordner antlr/ an und darin AApprOAusdruck.g4:
...
└ antlr/
└ AApprOAusdruck.g4
...
Wenn man in seiner IDE ein Tool wie den ANTLR4 language support for Visual Studio Code hat legt dieses ggf. dann schon los und erzeugt an einer Stelle außerhalb des CLASSPATH generierte Dateien, die man zur Vorschau verwenden kann.
ANTLR Maven Plugin ergänzen
Um den Maven Prozess nutzen zu können, wird in der pom.xml eine Konfiguration in der hier gezeigten Art ergänzt. Zusammen mit den Abhängigkeiten erhält man z. B. das:
Wenn man nun maven compile aufruft wird gleich die Generierung der Klassen aus der Grammatik durchgeführt. Aber hier tritt das erste Problem auf: Die Klassen werden per Default im /target-Verzeichnis abgelegt, wo sie VS Code zumindest nicht ohne weitere Konfiguration für die Entwicklung von darauf aufbauendem Code im Projekt erkennt.
Den Pfad für die generierten Dateien anpassen
Um den Defaultpfad zu ändern muss im plugin-Abschnitt eine configuration ergänzt werden:
Damit wird das gewünschte outputDirectory spezifiziert und nun werden die generierten Quellcodes dort abgelegt, wo sie die IDE – und auch Maven weiterhin – findet. Aber in einem eigenen Package, damit sie sich ggf. einfach auf einen Schlag löschen lassen. Das ist manchmal der schnellste Weg, wenn sich die Toolchain verknotet hat.
Das fehlende Package im Java Code
Nun tritt aber das nächste Problem auf: Die generierten Java Klassen haben keine package-Definition und der Compiler beschwert sich darüber zurecht. Ein Irrweg zur Lösung waren die header-Definitionen, die man in der Grammatikdatei einfügen kann:
Damit bringt man zwar die Paketdefinition in die Klassen, die zu Lexer und Parser gehören, aber nicht in die Listener- und Visitorklassen. Das hat früher mal so funktioniert, wurde aber in Zuge eines Bugfixes abgestellt.
Generell hat es mich überrascht, wie kompliziert es schien diese doch eigentlich generell übliche Vorgehensweise – wer legt schon seine Java Klassen ganz an die Spitze seiner Pakethierarchie!? – umzusetzen. Der entscheidende Hinweis war dann, dass sich in der Kommandozeilenversion des Tools ein -package-Parameter befindet, der genau diese umfassende Wirkung hat.
Was ich dann erst mit Blick in den Quellcode – zum Glück möglich bei Open Source Software – verstanden habe ist, wie man in Maven diesen Parameter setzt. Und zwar so:
Das entscheidende ist hier der arguments-Parameter und das man hier -package und den Paketnamen nicht per Leerzeichen wie auf der Kommandozeile, sondern per Komma trennen muss. Dann funktioniert es perfekt. Die beiden anderen Optionen steuern nun noch die Generierung der Listener-Klassen (hier unterdrückt) der Visitor-Klassen (hier gewünscht).
Und damit läuft es dann endlich rund: Nach jeder Änderung der Grammatik erzeugt ein Maven Lauf die neuen, generierten Klassen und die lassen sich nahtlos im selbst erstellten Code verwenden.
TL;DR: Dieser Post setzt auf den vorherigen Post zu Lastpass auf und betrachtet die Fragen, die man sich als IT Betrieb dazu stellen sollte, wie man Passworte – generell Logindaten/Credentials – sicher ablegen kann: Welche Verfahren gibt es, welche sind zeitgemäß, und wie lange würde es heute wohl dauern bis Angreifer, die die komplette Logindatenbank stehlen konnten, die Daten entschlüsseln und für sich nutzbar machen können.
Wie legt man als IT Betrieb die Passworte der eigenen Nutzer*innen so in den Systemen ab, dass sie möglichst (lange) sicher sind?Selbst im Falle eines Einbruchs in der Art, wie ihn Lastpass erfahren hat?
Es geht hier also um ein Szenario, bei dem Angreifer die gesamten Passworte bzw. Logincredentials abgreifen können, sei es aus den produktiven Systemen, oder wie bei Lastpass aus Backups. Und dann mit allen ihnen zur Verfügung stehenden Ressourcen versuchen können diese zu entschlüsseln.
Warum den Angreifern überhaupt Stolpersteine in den Weg legen?
Wenn Angreifer schon so tief in die Systeme vorgedrungen sind: Was macht es dann noch für einen Sinn sich Gedanken darüber zu machen, ob Passworte mehr oder weniger einfach zugänglich irgendwo herumliegen? Dafür gibt es mehrere Gründe:
In Szenarien wie bei Lastpass, bei denen die Daten aus Backups geholt wurden, sind die Angreifer nicht in die produktive Infrastruktur vorgedrungen (zumindest hofft man das). Gut gesicherte Passworte bringen hier die Angreifer zunächst nicht viel weiter
Selbst wenn Angreifer tiefer in die Systeme vorgedrungen sind haben sie vielleicht noch nicht die Zugänge, die sie brauchen um noch größeren Schaden anzurichten. Auch hier schützen nicht einfach zugängliche Passworte davor, dass es Angreifer zu leicht haben
Schließlich ist dies auch ein Schutz nach innen: Wenn es auch der IT Abteilung selbst nicht möglich ist Passworte im Klartext zu ermitteln kommt man gar nicht erst in die Versuchung risikoreiche ‚Abkürzungen‘ zu nehmen (‚Moment, ich suche Ihnen gerade Ihr vergessenes Passwort raus‘, ‚Wir können uns doch mal als meyer37 anmelden um zu prüfen, was genau bei dem Kollegen nicht funktioniert, dass machen wir immer so.‘, …)
Die Gründe, warum eine IT Abteilung manchmal gerne Passworte im Klartext hätte – z. B. um schwache Passworte zu finden, oder um sie in neu gegründete Systeme überführen zu können – müssen hier letztlich als nachrangig eingestuft werden.
Verschlüsseln oder hashen
Um Passworte nicht im Klartext abzulegen, aber vielleicht doch die Option zu behalten diesen Klartext verfügbar zu machen, könnte man die Passworte verschlüsseln, z. B. mit einem symmetrischen Verfahren wie AES. Im Fall eines Einbruchs in die eigenen IT Systeme besteht allerdings das Risiko, dass dann auch der oder die Schlüssel mit entwendet werden. Bei so einer Vorgehensweise müsste schon ein durchaus wesentlicher Aufwand betrieben werden um die Verschlüsselung selbst wieder sicher zu machen. So ist es den Angreifern beim Lastpass Hack gelungen die Schlüssel zu dem eigentlich verschlüsselten Backup zu erhalten.
Seit langen ist daher die Ablage von Passworten in Form eines Hashes Standard. Hier wird das Passwort unter Verwendung eines Hashfunktion in ein Format – den Hashwert – überführt, welches sich durch diese Eigenschaften auszeichnet:
Aus dem Hashwert lässt sich der Originalwert – hier das Passwort – nur sehr schwer wieder ermitteln, im Idealfall nicht viel schneller als durch Durchprobieren aller möglichen Eingaben
Der Hashwert hat immer ein identisches Format z. B. mit der gleiche Länge, unabhängig davon wie der Eingabewert war
Zwei klassische Hashfunktionen sind MD5 und SHA-1. Das sind Beispiele für Hashwerte:
Eingabewert
MD5 Hash
SHA-1 Hash
abc
900150983cd24fb0d6963f7d28e17f72
a9993e364706816aba3e25717850c26c9cd0d89d
Der Hashwert hat immer ein identischen Format wie die gleiche Länge, unabhängig davon wie lang der Eingabewert war
78eb98ec466e8b9dfd1ffcac23ccd690
b5447826036922409c4f77f50ead0432fb5da892
Beispiele für Hashing
Bei einem Loginvorgang werden dann die von Nutzer*innen eingegebenen Passworte erneut durch die Hashfunktion geschickt und dann dieses Ergebnis mit dem beim Setzen des Passwortes erzeugten Hash verglichen. Bei so einer Vorgehensweise braucht es keine geheimen Schlüssel oder dergleichen, der Hash an sich ist ’sicher‘ genug. Wenn er denn richtig gewählt wird und um das schon vorweg zu nehmen: MD5 und SHA-1 sind heute nicht mehr sicher genug! Aber dazu kommen wir gleich, zuerst noch zwei Kochzutaten:
Den Regenbogen versalzen (und pfeffern)
Die Eigenschaft von Hashfunktionen, für die gleiche Eingabe immer zum gleichen Hashwert zu führen, hat bei der Verwendung zur Passwortsicherung zwei Nachteile
Es ist für einen Angreifer, der eine große Menge von gehashten Passworten erhalten hat, direkt erkennbar welche Nutzer*innen identische Passworte nutzen. Hier kann man also mit einem erfolgreich entschlüsselten Passwort gleich mehrere Konten übernehmen
Die Arbeit des Passwortbrechens kann schon vor dem Angriff geleistet werden, in dem man lange im Voraus für riesige Mengen von möglichen Passworten die Hashwerte berechnet und dann nur noch in einer Tabelle – für die sogar eine besonders effiziente Struktur mit dem Namen Rainbow Table entwickelt wurde – nachsehen, welcher Hashwert zu welchem Passwort gehört
Es gibt aber ein einfaches Mittel um Angreifern zumindest diese Abkürzungen zu vermiesen: Bevor das Passwort in die Hashfunktion gesteckt wird vermischt man es noch mit einem zufälligen Wert, der für jedes Passwort individuell erzeugt wird. Erst die Kombination aus diesem Zufallswert – für den sich der Name Salt eingebürgert hat – und dem Passwort wird in die Hashfunktion gesteckt. In der Passwortverwaltung speichert man dann das Salt zusammen mit dem Hashwert, da es für die Überprüfung eines beim nächsten Login eingegebenen Passworts benötigt wird.
Der Angreifer muss dann die Hashwerte für das jeweilige Salt berechnen und wenn dies groß genug ist lohnt sich kein Rainbow Table, da dieser die Kombinationen von allen Salts – wirklich allen, wenn es ein echter Zufallswert ist – und möglichen bzw. wahrscheinlichen Passworten enthalten müsste. Jedes Passwort muss also einzeln und mit entsprechendem Rechenaufwand ermittelt werden.
Eine weitere Ergänzung kann dann ein Pepper-Wert sein: Dieser funktioniert ähnlich wie das Salt, er ist also ein zufälliger Wert, der mit dem Passwort vermengt wird, er wird aber nicht zusammen mit dem Passworthash abgelegt, sondern zum Beispiel in der Konfiguration des Servers, der die Loginvorgänge abwickelt. Er ist also für alle Passworte identisch.
Wann bringt dies einen Schutz? Wenn ausschließlich die Datenbank mit den hashten (und gesalzenen) Passworten abhanden gekommen ist, aber nicht die Serverkonfiguration mit dem Pepper, dann kann ein Angreifer mit diesen Daten nichts mehr anfangen, da ihm ein entscheidendes Geheimnis fehlt um zu überprüfen, ob er ein Passwort richtig geraten hat.
Falls hingegen die Daten der kompletten IT Landschaft gestohlen wurden ist es nur eine Frage der Komplexität dieser Landschaft, ob es Angreifern gelingt zu verstehen wie das Ganze funktioniert und wo der Pfeffer wächst.
Gutes Hashen, schlechtes Hashen
Es gibt eine große Anzahl von Hashfunktionen und nicht alle sind gleich gut geeignet für die Erzeugung von Passworthashes. Tatsächlich sind die oben genannten Funktionen MD5 und SHA-1 nach heutigem Stand überhaupt nicht mehr geeignet, wie sich später in den Abschätzungen für die Entschlüsselungsdauern zeigen wird.
Warum sind sie nicht geeignet? Dieses Hashes wurden für andere Zwecke entwickelt und zwar zur Prüfung ob Dokumente bzw. Datenpakete unverändert sind. In dem ich ein PDF oder ein Softwarepaket durch so eine Hashfunktion schicke kann ich den erhaltenen Wert zur Prüfung mitgeben, ob das Dokument noch so ist, wie es ursprünglich einmal erzeugt oder verschickt wurde. Alle großen Softwarepakete – hoffe ich jedenfalls – bieten auf ihren Downloadseiten auch die Prüfsummen (Hashwerte) an – die der Hersteller selbst ermittelt hat. Wer es ganz genau nimmt erzeugt diese Prüfsumme nach dem Download auf seinem Rechner dann selbst und vergleicht. Nur wenn die Werte Zeichen für Zeichen übereinstimmen kann man sicher sein, dass die Datei noch so ist, wie sie vom Ersteller einmal produziert wurde.
Bei diesen Nutzungen von Hashfunktionen kommt es auf zwei Dinge an: Es muss sehr schwer sein für eine gegebene Prüfsumme ein anderes – gefälschtes – Dokument zu erzeugen, welches die gleiche Prüfsumme ergibt. Und zweitens: Performance. Diese klassischen Hashverfahren sollen möglich wenig Rechenzeit verbrauchen, damit sie auch bei hohen Durchsatzraten einsetzbar sind.
Performance ist genau das, was wir bei Passworthashes nicht wollen!
Die Möglichkeit eine Hashfunktion schnell auszuführen spielt beim Loginvorgang nur eine begrenzte Rolle, ob unsere Nutzer*innen bei diesem Schritt eine Sekunde warten müssen oder nicht werden sie kaum bemerken bzw. es bei diesem seltenen Vorgang akzeptieren. Für einen Angreifer, der Milliarden von Passworthashes erzeugen muss, macht es hingegen einen riesigen Unterschied, ob ein Hash sich in einer Microsekunde berechnen lässt, oder in einer Millisekunde.
Es gibt dabei die grundlegende Schwierigkeit, dass unsere eigenen Server, die die Logins verarbeiten und den Passworthash dabei erzeugen müssen, nicht so performant sein werden wie die spezialisierte Hardware, die Angreifer ggf. ins Feld führen können. Wir müssen also generell in Kauf nehmen, dass Angreifer in der Lage sein werden viel schneller Hashes zu erzeugen als wir selbst. Die Frage ist nur, wie viel schneller?
Die klassischen, performanten Hashfunktionen wie die SHA-2 Familie lassen sich eigentlich nur auf eine Weise für Passworthashes einsetzen: Durch Erhöhung der Rundenzahl. Damit ist gemeint, dass man den aus dem Passwort (und Salt und Pepper) berechneten Hash erneut in die Hashfunktion steckt. In dem Post zu Lastpass steckt dieser Aspekt in der Frage wie viele Runden im PBKDF2-Verfahren gemacht werden sollten. Hier geht es also ggf. um Millionen von Runden, bei denen der Hashwert immer wieder neu berechnet wird. Für ein produktives Loginsystem sind dabei vermutlich noch viel höhere Werte möglich, da man im Gegensatz zu einem Passwortmanager keine Rücksicht auf ggf. leistungsschwächere Smartphoneprozessoren nehmen muss.
Trotzdem bleibt hier das Grundproblem, dass eine Funktion verwendet wird, die letztlich performant sein soll. Aber es gibt heute Alternativen:
Unperformante Hashfunktionen: Bcyrpt, scrypt und Argon2
Das Design einer Hashfunktion, die eine ’schlechte‘ Performance zeigen soll, hat ihre eigene Komplexität und hier hat es immer neue Entwicklungen gegeben. Diese Funktionen sollen generell solche Eigenschaften haben:
Sie müssen natürlich die gleichen Eigenschaften einer Hashfunktion haben, die zuvor genannt wurden
Es soll auch mit spezialisierter Hardware nicht dramatisch viel einfacher sein diese Funktionen auszuführen als mit Standardhardware
Im Algorithmus sind ‚Stellschrauben‘ vorhanden, die es erlauben den Rechenaufwand und bei neueren Funktionen auch den Speicherbedarf einzustellen. Je nach Verfahren in Abhängigkeit voneinander oder auch nicht
Seitenkanalattacken sollen möglichst schwierig sein. Also Wege, bei denen sich z. B. über die Laufzeit des Algorithmus oder den Stromverbrauch der Hardware Informationen über das verarbeitete Passwort gewinnen lassen
Das sind die heute relevantesten Verfahren in der chronologischen Reihenfolge:
bcrypt
Diese Funktion wurde schon 1999 vorgestellt und verbessert die Passwortsicherheit im Vergleich zu den schnellen Hashes bereits deutlich. Sie verfügt über einen einstellbaren Kostenfaktor, den man an die Leistungsfähigkeit der eigenen Loginserver anpassen kann, um so einen Mittelweg zwischen der Wartezeite für die eigenen Nutzer*innen zu finden und dem Aufwand für Angreifer.
Bcrypt hat aus heutiger Sicht das Ziel nicht vollständig erreicht auch mit spezieller Hardware nicht deutlich schneller ausgeführt werden zu können: Gerade der eher geringe Speicherbedarf ermöglicht eine massive Parallelisierung der Hashwertberechnungen.
scrypt
Diese ca. 10 Jahre nach bcrypt vorgestellte Funktion ist bewusst mit einem ‚hohen‘, nicht reduzierbarem Speicherbedarf konzipiert worden. Dies verhindert den Einsatz von günstiger Hardware für massenhafte Berechnungen deutlich, während die eigenen Server damit normalerweise kein Problem haben.
Es kann sowohl der Rechnenzeit- wie auch der Speicherbedarf eingestellt werden, allerdings nicht unabhängig voneinander. Trotzdem gibt es Untersuchungen, bei denen scrypt in bestimmten Parametersetzungen schlechter – also effizienter ausführbar – abschneidet, als bcrypt. Auch gilt es aus kryptographischer Sicht immer noch als ‚junges‘ Verfahren und löst daher manchmal die Sorge aus, dass es vielleicht noch nicht erkannte Probleme hat.
Argon2
Dieses erstmals in 2014 vorgestellt Verfahren, welches dann noch Weiterentwicklungen erfahren hat, gewann in 2015 die sogn. Password Hashing Competition. Generell ist es damit das aktuellste der drei hier genannten Verfahren, mit den Vor- und Nachteilen, die das mit sich bringt:
Argon2 ist am flexibelsten bei den Einstellungen für Rechenzeit und Speicherbedarf und in Kenntnis der durch spezialisierte Hardware verfügbaren Rechenleistung entwickelt worden. Auf der anderen Seite in kryptographischer Sicht noch jünger und damit potentiell angreifbarer.
Es gibt Videos wie dieses, in dem man sich anschauen kann wie man hashcat, ein beliebtes ‚password recovery‘ Tool, einfach an den Start bringt. Aber die Rechenleistung des eigenen Rechners vermittelt einem nur ein ungenügendes Bild davon, was Angreifern potentiell zur Verfügung steht. Interessanter ist da der jährliche Password Table von Hive Systems (nicht zu verwechseln mit der Hive Ransomware Gruppe). Die folgenden Graphiken und Zahlen stammen aus dem Bericht 2022.
Hive Systems hat jeweils ermittelt wie viele Hashes in unterschiedlichen Hashverfahren mit damals verfügbaren Graphikkarten pro Sekunde berechnet werden können und auf dieser Basis geschätzt, wie lange es dauern würde die Hashes für alle denkbaren Passworte einer bestimmten Länge und Zusammensetzung zu berechnen. Und sie haben auch gleich verglichen welche Rechenleistung in der Cloud verfügbar wäre! Es gibt z. B. von Amazon kleine GPU Cluster, die man für überschaubare Kosten mieten kann.
Diese Graphik zeigt die Crackingdauern für Passworte im MD5 Hash mit dem größten damals in der Amazon Cloud verfügbaren Cluster mit 8 GPUs. Während die getestete Graphikkarte auf ca. 70 Milliarden MD5 Hashes pro Sekunde kommt, ist der Cluster in der Cloud in der Lage mehr als 500 Milliarden Hashes zu berechnen. Damit kommt Hive auf diese Tabelle:
Dauer zum Cracken von MD5 gehashten Passworten in der Amazon Cloud. Quelle: Hive Systems
Ein 8 Zeichen langes Passwort – wohlgemerkt jedes 8 Zeichen lange Passwort! – kann also in der Cloud in weniger als einer Stunde errechnet werden. Wenn man bedenkt, dass die meisten von uns keine wirklich zufälligen Passworte verwenden mit Groß- und Kleinschreibung und Zahlen und weiteren Zeichen, wird es meist noch viel schneller gehen. Daher sind auch Passworte mit mindestens 12 Zeichen, wie sie das BSI aktuell empfiehlt, nicht lange sicher, wenn sie als MD5 Hash gespeichert werden.
Der Artikel von Hive vergleicht dabei die in 2022 aktuellen Zahlen mit der vorherigen Auswertung in 2020. Und kann deutliche Rechenleistungssteigerungen zeigen. Ein Passwort, dass heute noch 5 Jahre zur Ermittlung brauchen würde, ist daher in einem Jahr vielleicht schon in der Hälfte der Zeit knackbar.
Und letztlich sind diese Zahlen bzw. die hier eingesetzte Hardware keine Obergrenze: Es gibt spezielle Hardware mit deutlich mehr Leistung und Software wie die von Elcomsoft, die in der Lage ist die Arbeit auf zehntausende von Rechnern zu verteilen.
In den weiteren Auswertungen zeigt sich dann der Vorteil von bcrypt. Diese Graphik basiert auf dem gleichen Hardwareszenario, nur dieses Mal mit bcrypt Hashes:
Dauer zum Cracken von bcrypt gehashten Passworten in der Amazon Cloud. Quelle: Hive Systems
Mit bcrypt ist die Anzahl der Hashes pro Sekunde im Amazon GPU Cluster auf eine Million zurückgefallen. Es geht aus dem Artikel leider nicht hervor, mit welchem Kostenfaktor die Hashes erzeugt wurden. Da die Erhöhung des Kostenfaktors um 1 die Rechenzeit für einen Hash in etwa verdoppelt ist es ein deutlicher Unterschied, ob der Faktor 1 oder 15 war.
In dieser Konstellation müssen Angreiferdeutlich mehr Hardware einsetzen, oder gut darin sein den Suchraum einzugrenzen, um in vernünftiger Zeit zu einem Erfolg zu kommen. Auch wenn bcrypt heute nicht mehr als das modernste Verfahren gilt, ist es weiterhin in der Lage Angriffe auf Passworthashes deutlich zu verlangsamen.
Und trotzdem: Es kommt weiterhin auf die Passwortqualität an
Man sieht an den Auswertungen deutlich, welche Verantwortung als IT Betrieb man bei der sicheren Ablage von Logindaten hat. Aber man sieht auch: Wenn die verwendeten Passworte schlecht sind – zu kurz, zu einfach, in vielen anderen Diensten verwendet – nutzt auch das beste Hashverfahren nichts.
Eine Absicherung der Infrastruktur muss also auf allen Ebenen zugleich erfolgen, damit sie auch in dem hier beschriebenen Szenario wirksam werden kann. Und eine 2-Faktor-Authentifizierung kann helfen den unmittelbaren Schaden eines Verlusts der Passworte zu begrenzen. Sofern die dafür notwendigen Geheimnisse nicht gleich mit gestohlen wurden.
TL;DR: In diesem Text geht es um meinen Wechsel des Passwortmanagers, nachdem sich Lastpass als zu unzuverlässig erwiesen hat. Vorangestellt werden ein paar Überlegungen dazu, warum man eigentlich einen Passwortmanager braucht und wie man ihn sicher nutzt. Abschließend geht es um die Frage, wie mit dem Datenverlust bei Lastpass umzugehen ist: Muss ich jetzt alle meine Passworte ändern?
Eine der wesentlichen Regeln der Passwortsicherheit ist die Verwendung von individuellen Logins für jeden Dienst und Zweck. Angesichts immer wiederkehrender Verluste von Logindaten bei erfolgreichen Angriffen auf Webdienste kann man nur so den Schaden auf den jeweiligen Dienst begrenzt halten. Es nutzt nichts ein einzelnes, super sicheres Passwort zu haben, welches man immer verwendet. Denn schon ein erfolgreicher Einbruch bei einem einzigen der Dienste, bei denen man das Passwort verwendet, wird dazu führen, dass die Angreifer danach auch die anderen Dienste mit den so gewonnenen Logindaten erfolgreich angreifen. Diese Art des Angriffs ist so häufig, dass sie einen eigenen Namen bekommen hat: Credential stuffing
Auch 2-Faktor-Authentifizierungen ändern daran erst einmal nicht grundsätzlich etwas, und bis wir überall Passkeys einsetzen und keine Passworte mehr brauchen wird es noch etwas dauern.
Ein Passwortmanager ist unverzichtbar
Zwar kann man so eine Vorgehensweise auch ohne digitale Unterstützung umsetzen, entweder mit einem Notizbuch für die Passworte, oder durch Schemata, bei denen man ein komplexes Grundpasswort nach eigenen Regeln jeweils individualisiert, aber die Verwendung eines Passwortmanagers macht diese Vorgehensweise erst in einer Weise handhabbar, die den digitalen Lebenswandel und Arbeitsalltag nicht so sehr erschwert, dass es nicht mehr praktikabel ist.
Auch bieten die gängigen Passwortmanager einige Vorteile im Vergleich zu manuellen Lösungen:
Generierung von Passworten: Es gibt üblicherweise Funktionen, um sich lange und zufällige Passworte mit vielen Zeichenvariationen mit einem Klick zu erzeugen. Zufällig generierte Passworte bieten den höchsten Schutz gegen Passwortrateversuche, selbst wenn Angreifer dabei sehr viel Zeit und sehr viel Rechenleistung zur Verfügung steht
Umgang mit sehr langen Passworten: Der Passwortmanager nimmt einem eventuell noch vorhandene Hemmungen sehr lange Passworte zu verwenden. Also Passworte mit Längen jenseits von 30 Zeichen, die man bei einer manuellen Handhabung wohl eher scheut
Schutz vor homographischen Angriffen: Wenn der Passwortmanager verwendet wird zum automatischen Ausfüllen von Logins in Webseiten kann man auf diese Art von Angriffen – bei denen sehr ähnliche oder gar völlig identisch aussehende Webadressen verwendet werden – nicht hereinfallen. Bzw. muss dann als Nutzer*in selbst aktiv die Logindaten eingeben und könnte sich bei der Gelegenheit wundern, warum der Passwortmanager das nicht tut
Aber es gibt natürlich auch Nachteile, gerade wenn es um die ganz besonders bequemen Passwortmanager mit einer Synchronisierung über die Cloud geht. Da heute nahezu jede*r mindestens 2 Geräte haben wird, auf denen man sich irgendwo einloggen will, muss man in der Lage sein die Inhalte des Passwortmanagers – nennen wir ihn den ‚Tresor‘ – sicher zwischen diesen Geräte zu transportieren.
Das kann man selbst machen, aber das ist mit einem gewissen Aufwand verbunden und braucht eine hohe Sorgfalt, damit keine Fehler beim Umgang mit diesen kritischen Daten passieren. Es gibt aber inzwischen eine Reihe von Anbietern, die die Passwortmanagerinhalte über die Cloud synchronisieren und dabei vor allem dies versprechen:
Zero Knowledge Architekturen
Mit dem ‚Null Wissen‘ ist dabei gemeint, dass der Anbieter des Passwortmanagers zwar die Inhalte in der Cloud speichert und so zwischen den Geräten synchronisieren kann, aber nicht in der Lage ist die Inhalte selbst zu sehen bzw. zu entschlüsseln. Das ist durch eine entsprechende Programmierung der Passwortmanagersoftware möglich, da die Entschlüsselung letztlich nur auf den Geräten der Nutzer*innen – also lokal und nicht in der Cloud – stattfinden muss.
Auf diese Weise lassen sich zwei Probleme lösen:
Wie viel Vertrauen brauche ich in meinen Passwortmanageranbieter? Je weniger der Anbieter von meinen Daten sehen kann, desto weniger Vertrauen muss ich zu ihm haben. Ganz ohne Vertrauen geht es natürlich nicht: Da meist die Passwortmanagersoftware vom gleichen Anbieter kommt wie die Cloudsoftware, die die Daten synchronisiert, muss ich darauf vertrauen, dass die Software nicht doch mein Passwort direkt in die Cloud schickt. Oder die Inhalte meines Passworttresors im Klartext
Was passiert, wenn meine ganzer Passwortschatz abhanden kommt? Da der Passwortmanager, wenn er richtig genutzt wird, der Schlüssel zum gesamten digitalen Leben ist, kann er in den falschen Händen maximalen Schaden anrichten. Dabei kann er sowohl vom eigenen Gerät entwendet werden, wie auch aus der Infrastruktur des Anbieters. Erfolgreiche Angriffe auf Clouddienste sind keine Seltenheit, dabei trifft es alle Ebenen: Vom grundlegenden Cloudserviceanbieter (Beispiel Rackspace) über die Softwareentwicklungsinfrastruktur (Beispiel Circle CI) bis hin zum IT Sicherheitsdienstleister selbst (Beispiel Okta). Im Idealfall könnte ich meinen verschlüsselten Passworttresor auch frei ins Internet stellen und niemand könnte mit einem vernünftigen Ressourceneinsatz meine Passworte daraus extrahieren, so dass ich mir selbst im Fall eines erfolgreichen Angriffs auf meinen Dienstleister keine (großen) Sorgen machen muss
‚Das letzte Passwort, das Sie jemals brauchen werden‘
Der Schutz des Passworttresors und seiner wichtigen Inhalte hängt nun von einer einzige Sache ab: Dem Passwort, welches man für den Passwortmanager verwendet. Dieses Passwort wird verwendet um den Tresor zu verschlüsseln und dann auch wieder zu ‚öffnen‘. Wer es besitzt hat damit die komplette Kontrolle über alle im Tresor gespeicherten Logindaten.
Im Idealfall ist es dann das ‚letzte‘ Passwort, welches man in dem Sinne braucht, dass man es sich merken und manuell eintragen muss. Produkte wie Lastpass oder 1Password verdanken dieser Idee ihre Namen. Oft wird dieses Passwort als das Masterpasswort bezeichnet
Da man dieses Passwort häufig benötigt um den Tresor zu entsperren ist es praktisch es sich merken zu können und so kann man ausgerechnet beim wichtigsten Passwort von allen kaum auf ein langes, zufällig generiertes Passwort setzen. Sondern muss sich für eine Vorgehensweise entscheiden um ein Passwort zu finden, welches auch in dem Fall, dass der damit verschlüsselte Tresor Angreifern in die Hände fällt, für eine ‚vernünftige‘ Zeit vermutlich nicht knackbar ist.
Die Ratschläge wechseln dabei mit der Zeit, die Vorgehensweise oben im Comic scheint heute immer noch aktuell, nur sind 4 Worte wohl nicht mehr genug. Hier ein paar Links dazu:
Tipps vom BSI – Wobei die Aussage, dass ein ‚gutes Passwort‘ mehr als 8 Zeichen haben sollte, für ein Masterpasswort viel zu schwach ist. Hier sollte man schon etwas jenseits von 15 Zeichen haben, besser noch mehr
Bitwardens Passwortstärkeprüfung: Diese Seite gibt einem ein Feedback dazu, wie sicher ein Passwort vermutlich ist. Hier kann man ein Gefühl dafür bekommen, wie Länge und verwendete Zeichenarten die Komplexität beeinflussen, und die steht wiederum im direkten Verhältnis zum Aufwand, den potentielle Angreifer zum Erraten betreiben müssen
Password Haystack von GRC: Diese etwas nerdige Seite von Steve Gibson (vom Security Now Podcast) kann einem ebenfalls ein Gefühl dafür geben, wie komplex ein Passwort ist und wie sich die Länge und weitere Zeichenklassen (Groß- und Kleinschreibung, Zahlen, …) auf die Anzahl der Passwortkombinationen auswirken, die ein Angreifer durchtesten müsste. Das ist kein völlig korrektes Maß für die sogenannte Entropie eines Passworts und die Zeiten, die dort prognostiziert werden um ein Passwort zu brechen, sind nicht mehr realistisch angesichts heute verfügbarer Hardware. Trotzdem vermittelt es einem ein Bild davon, wie sich Komplexität erzeugen lässt. So ist ein Passwort, in dem man irgendwo zehn ‚.‘ oder ähnliches eingefügt hat und welches dadurch auf eine enorme Länge kommt durchaus für Angreifer, die davon nichts ahnen, sehr schwer zu erraten
Have i been pwnd: Hier kann man prüfen, ob ein Passwort schon einmal in gehackten Konten vorkam. So ein Passwort sollte man in keinem Fall mehr verwenden
Generelle Hinweise:
Das Masterpasswort sollte keins sein, welches man vorher schon irgendwo verwendet hat. Und man sollte es dann auch für keinen anderen Zweck verwenden
Es gibt keinen Grund das Passwort regelmäßig zu ändern, es sei denn man möchte es noch länger / komplexer machen
Das Masterpasswort sollte man sich ggf. aufschreiben und an einem sicheren Ort verwahren. Gerade ein kompliziertes Passwort vergisst man nach einem langen Urlaub auch schon mal
Man sollte das Masterpasswort nur auf Geräten eintragen, die vertrauenswürdig sind. Vertrauenswürdig ist zum Beispiel sicher nicht ein Internetcafé am Urlaubsort, aber ggf. auch keine Geräte von Bekannten oder Freunden. Es ist für Besitzer*innen fremder Geräte einfach zu leicht eine Tastatureingabe mitzuschneiden und so an das Passwort zu kommen
Das Versagen von Lastpass
Ich habe mich vor Jahren für Lastpass als meinen cloud-basierten Passwortmanager entschieden und eine der kostenpflichtigen Optionen gewählt. Auf dieses Produkt bin ich denke ich durch den Security Now Podcast aufmerksam geworden, der ursprüngliche Entwickler von Lastpass hat sein Produkt damals für Steve Gibson geöffnet und dieser hat einen Review des Konzepts gemacht, welches zu dieser Zeit State of the art war. In den folgenden Jahren wurde Lastpass aufgekauft und der ursprüngliche Entwickler hat das Unternehmen schon lange verlassen. Aber aus Nutzersicht war und ist es ein Produkt, welches seine Aufgabe im Webbrowser und auf Android und iOS problemlos erledigt.
Auf Grund der Zero Knowledge Architektur war dann auch die Meldung von Lastpass Anfang Dezember 2022 (inzwischen aktualisiert) über einen Sicherheitsvorfall, bei dem die verschlüsselten Passworttresore gestohlen wurden, zunächst ärgerlich, aber noch nicht sehr besorgniserregend:
The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.
Natürlich ist der Verlust der Informationen dazu, welche Webseiten ich nutze, schon ein durchaus heftiges Datenschutzproblem und eine ideale Grundlage für Phishingangriffe. Trotzdem war der Stand zunächst der, dass durch die Art und Weise, wie aus dem Masterpasswort die Verschlüsselung generiert wird, die wirklich wichtigen Daten geschützt sind. Der Blogeintrag bestärkt diesen Eindruck noch:
To further increase the security of your master password, LastPass utilizes a stronger-than-typical implementation of 100,100 iterations of the Password-Based Key Derivation Function (PBKDF2), a password-strengthening algorithm that makes it difficult to guess your master password. You can check the current number of PBKDF2 iterations for your LastPass account here.
PBKDF2 Iterationen: 5000! Der Schutz meiner von Lastpass gestohlenen Daten hängt nur daran, dass Angreifer mein Masterpasswort nicht knacken. Mein Passwort ist deutlich länger als die von Lastpass zu diesem Zeitpunkt empfohlenen 12 Zeichen. Aber Lastpass selbst kann die Sicherheit sehr einfach durch die Anzahl der Iterationen erhöhen, die beim PBKDF2 Verfahren verwendet werden. Und hier ist es eine schlichte Lüge, dass hier mehr als 100.000 Iterationen verwendet werden. Bei mir waren nur 5.000 eingestellt, da ich ein langjähriger Nutzer bin und offenbar noch die Einstellung habe, die bei meiner ersten Nutzung von Lastpass aktuell war. In der 905er Episode behandelt Steve Fälle, bei denen es gar nur 1 Iteration war! Wieso hat Lastpass uns bisher treue Altnutzer nicht automatisch umgestellt? Als ich das manuell gemacht habe musste ich mich einmal neu einloggen und ein paar Sekunden warten, dann war das erledigt. Das hätte Lastpass in den letzten Jahren einfach mal automatisch tun können
ECB verschlüsselte Passworte: In alten Versionen von Lastpass wurden Passworte nach dem ECB Verfahren verschlüsselt. Auch wenn das eine sichere Verschüsselung ist hat sie den Nachteil, dass die gleiche Eingabe immer das gleiche Ergebnis erzeugt. Es ist also in den verschlüsselten Daten einfach erkennbar, wenn jemand ein Passwort mehrfach verwendet hat. Später hat Lastpass auf das CBC Verfahren umgestellt, welches dieses Problem nicht hat. Es aber auch hier versäumt die Altdaten komplett umzustellen. In dem Lastpass Extrakt, den man sich nach dem in Folge 904 vorgestellten Verfahren herausziehen kann, finde ich zahlreiche ECB-kodierte Passworte
Kein Zwang zu guten Masterpassworten: Das Problem betrifft mich nicht, aber offenbar hat Lastpass nie seine eigene Vorgabe durchgesetzt mindestens 12 Zeichen lange Passworte zu verwenden. Sie haben ihre Nutzer*innen damit in unverantwortlicher Weise sich selbst überlassen
Herunterspielen der Menge an unverschlüsselten Daten: Es scheint, also enthalte der gestohlene Datensatz eine Menge an unverschlüsselten Informationen, die Lastpass für den Betrieb seiner Services nicht benötigt. Diese Daten sind nun direkt für die Angreifer auswertbar und helfen ihnen mindestens bei der Priorisierung welche Passworte sie ggf. zuerst angreifen sollen
Mangelhafte Kommunikation: Insgesamt macht es den Eindruck, dass es Lastpass eher darum geht den Vorfall herunterzuspielen und eventuelle Datenverluste den Kunden in die Schuhe zu schieben. Auch wenn sie es in der Hand gehabt hätten hier viel für die Sicherheit zu tun
Letztlich hat mich die Menge der Probleme und der unprofessionelle Umgang damit dazu veranlasst ähnlich wie Steve Gibson nun Abschied von Lastpass zu nehmen.
Bitwarden als neue Lösung
Trotz der Erfahrung, dass meine Passwortmanagerdaten einmal in der Cloud abhanden gekommen sind, bleibe ich beim Grundprinzip eines cloud-basierten Passwortmanagers. Alles andere ist einfach zu umständlich. Zum Glück gibt es einige Alternativen, die in Episode 904 auch kurz diskutiert werden. Von den da genannten Kandidaten Dashlane, 1Passwort und Bitwarden habe ich mich für letzteren entschieden.
Ein Grund ist, dass es sich hier um eine Open Source Lösung handelt, die aber zugleich ein Serviceangebot hat, welches man kaufen kann. So hat man zwar die Option eines selbstverantwortlichen Betriebs, aber wenn man das nicht kann oder möchte nutzt man den Service in der Cloud.
Kann man sicher sein, dass Bitwarden keine ähnlichen Probleme hat oder bekommt wie Lastpass? Letztlich nicht wirklich, allein das es sich hier um Open Source handelt ist keine Garantie dafür, dass komplexe Algorithmen korrekt implementiert sind, keine sonstigen Fehler in der Software sind und das der Betrieb der Cloudplattform kompetent erfolgt. Aber zumindest könnte man in einem vergleichbaren Fall einfach nachsehen wie die Software funktioniert, und müsste nicht herumraten, wie es bei Lastpass nun der Fall ist.
Die Migration an sich hat bei mir gut funktioniert, man nutzt entsprechend der Anleitung den Export von Lastpass und holt diese Daten dann nach Bitwarden.
Nach dem ersten Eindruck ist die Oberfläche etwas weniger gefällig, als die von Lastpass, aber nicht in einem für mich abschreckenden Maß. Etwas Feintuning kann man dann noch machen und die Anzahl der Iterationen für die Schlüsselableitung (KDF) erhöhen. Sie liegt per Voreinstellung bei 100.000, also auf dem Level, welches Lasspass bei neuen Nutzer*innen setzt. Aber man kann sie hochsetzen, und heutige Smartphones verkraften auch deutlich höhere Werte:
Bitwarden: KDF-Iterationen bearbeiten
Zur Erinnerung: Die Anzahl der Iterationen erhöht direkt den Aufwand, den Angreifer in einem Szenario wie dem Datendiebstahl bei Lastpass erbringen müssen und hier hat man neben der Komplexität des Masterpassworts noch eine weitere Stellschraube. Der Wert von mehr als einer Million scheint auf meinem Geräten keine Schwierigkeiten zu bereiten, auch auf dem alten iPad Mini als wohl leistungsschwächsten Gerät dauert das Öffnen des Tresors nur eine Sekunde.
Ich habe meinen Lastpass Account noch nicht gekündigt und werde noch ein paar Wochen beobachten, wie sich Bitwarden schlägt, aber Passwortänderungen werden nun nur noch über den neuen Passwortmanager gemacht.
Umgang mit den bisher bei Lastpass gespeicherten Passworten
Ich muss davon ausgehen, dass mein kompletter Passworttresor heute in den Händen von Kriminellen ist. Zusammen mit den Tresoren von Millionen von anderen Lastpass Nutzer*innen. Trotz der oben benannten kritischen Punkte bei der Verschlüsselung gehe ich nicht davon aus, dass meine Daten schon geknackt wurden. Aus diesen Gründen:
Ich stelle vermutlich kein speziell interessantes Ziel dar, welches besondere Aufmerksamkeit und umfangreiche Investitionen an Rechenzeit rechtfertigt
Bei einer opportunistischen Vorgehensweise der Angreifer – leichte Ziele vor schweren Zielen angehen – sind die Nutzer*innen, die eine noch kleinere Anzahl von PKDF-Iterationen hatten (vielleicht nur eine einzige!) wohl eher ‚dran‘ als ich. Allerdings gibt es keine vollständige Information darüber, in welchem Maße die schwachen Iterationszahlen vorhanden sind, wann ich nach dieser Logik als ‚dran‘ wäre
Mein Masterpasswort war nicht schwach und erfüllte die oben von mir selbst aufgestellten Massgaben
Ich habe bisher keine ungewöhnlichen Aktivitäten bei meinen diversen Konten bemerkt
Trotzdem…es wäre absurd zu glauben, dass nicht irgendwann die Daten meines Tresors zugänglich werden, sei es in ein paar Wochen, Monaten oder Jahren, die Logindaten müssen also geändert werden. Allerdings habe ich hunderte von Logins in meinem Tresor, es ist daher eine Priorisierung notwendig. Das ist meine Reihenfolge:
Priorität 1: Zentrale Mail- und Betriebssystemkonten
An wichtigsten sind die Google Konten. Nicht nur enthalten sie selbst jede Menge wichtige Daten, sie sind auch bei vielen Services als Adressen eingetragen für Passwortresets. Wer diese Konten kapert, der kann sich dann auch ohne gestohlenen Passworttresor den Zugriff auf viele Konten sichern.
In gewisser Weise gilt das auch für die Konten bei Microsoft und Apple, die den Zugriff auf die Betriebssysteme dieser Anbieter ermöglichen und ebenfalls zentrale Angriffspunkte sind.
Priorität 2: Finanzen und große Einkaufsplattformen
Danach kommen direkt die Konten bei Banken und Onlinefinanzdienstleistern. Ein Zugriff darauf kann unmittelbaren finanziellen Schaden erzeugen, auch wenn hier heute immer ein weiterer Faktor wie eine dynamische TAN benötigt wird. Auch Plattformen wie Amazon gehören für mich dazu, da hier ebenfalls das Potential zu wesentlichen finanziellen Schäden besteht.
Priorität 3: Eigene Webseiten und Social Media
Eine Übernahme meiner digitalen Identität im Netz würde über Jahre aufgebaute Repräsentationen zerstören und hat das Potential auch andere zu schädigen, falls Angreifer versuchen sollten sich auf diese Weise Vertrauen zu erschleichen.
Priorität 4: Der große Rest
Danach bleiben immer noch eine Menge von Konten, für die eine Lösung gefunden werden muss. Bei vielen wird sich eher die Frage stellen ob man sie nicht komplett aufgibt, statt das Passwort zu ändern. Denn jeder Service, der Daten von einem verwaltet, ist letztlich ein potentielles Angriffsziel, über das Daten abfließen können.
Es ist schon etwas Zeit vergangen seit der letzten Leseempfehlung hier, aber meine gerade beendete Urlaubslektüre hat sich für mich sehr gelohnt. Es ist Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon (ISBN 0-77043-617-X) von Kim Zetter. Zwar ist das Buch schon aus dem Jahr 2014 und angesichts der schnellen Entwicklungen im IT Bereich daher nicht mehr ganz up to date.
Aber es ist trotzdem lesenswert, denn die Stuxnet Schadsoftware ist bis heute (2022) ein einzigartiges Beispiel für eine digitale Waffe, die auch zum Einsatz kam bzw. deren Einsatz entdeckt wurde.
Die Autorin nimmt auf den 500 Seiten alle Aspekte in Augenschein, vielleicht manchmal schon zu umfassend, darunter diese:
Die Sicht der Sicherheitsforscher
Die Personen, die mit der Analyse der ungewöhnlich komplexen Schadsoftware befasst waren, insbesondere bei Symantec und dem deutschen Unternehmen Langner, erfahren eine umfassende Porträtierung. Und die für sie neuen Fragestellungen:
Ist es insbesondere für ein US Unternehmen wie Symantec eigentlich opportun eine von der US Regierung beauftragte Operation zu (zer)stören?
Wie ist es mit den möglichen persönlichen Risiken, denen man sich dabei im Gegensatz zur Analyse irgendeiner beliebigen Virussoftware aussetzt?
Ist man in irgendeiner Weise mitschuldig, wenn der digitale Angriff aufgedeckt wird und die Geheimdienste ihre Strategie dann offenbar auf Mordanschläge umstellen?
Die Funktion der Waffe
Es gibt ein umfangreiche Beschreibung der ‘Nutzlast’ der Schadsoftware, sozusagen des digitalen Sprengkopfs. Dieser bestand aus auf die spezielle Steuerungssoftware von Siemens, die attackiert wurde, zugeschnittenen Elementen, die so ganz anders funktionieren als der Code, den Sicherheitsforscher im Umfeld gängiger Betriebssysteme wie Windows oder Linux gewohnt sind, was die Analyse sehr erschwerte.
Das Ziel der Waffe
Die Schadsoftware richtete sich – das kann heute wohl als sicher gelten – gegen das iranische Nuklearprogramm bzw. den Teil, in dem die Urananreicherung mit tausenden von Zentrifugen erfolgt.
Und war damit ein Teil eines über Jahrzehnte – bis heute – andauernden Konflikts zwischen dem Iran, der USA, Israel, aber auch weiteren Staaten. Hier rollt das Buch die verschiedenen Parteien auf, wobei es naturgemäß schwierig ist die eigentlich Verantwortlichen zum Reden zu bringen oder auch nur zu benennen.
Ein wesentlicher Teil des Buches befasst sich auch mit der Frage ob so eine Schadsoftware ein kriegerischer Akt ist. Das ist keine unwichtige Frage, denn die Alternativen aus Sicht der USA und Israels wären eindeutige kriegerische Akte wie Luftangriffe.
Und würden die USA – wenn sie in ähnlicher Weise angegriffen würden – so eine Attacke genauso einschätzen, wie sie es damals als Angreifer getan haben?
Was braucht es sonst noch um so eine Waffe zu entwickeln
Was in der Berichterstattung über Stuxnet oft zu kurz kam ist die Frage wie es überhaupt technisch möglich war eine Software zu entwickeln, die in offenbar sehr subtiler Weise komplexe Hardware – die Zentrifugen der Urananreicherung – beschädigen und in ihrer Leistung einschränken kann.
Hier wird klar, dass solche Angriffe kaum ohne einen umfangreichen Maschinenpark und langen Vorlauf realisierbar sind.
War Stuxnet erfolgreich
Die Antwort auf diese Frage ist überraschend kompliziert und vielfältig. Da niemand der Personen, die es am besten wissen könnten, ein Interesse hat die tatsächlichen Fakten offenzulegen gibt es nur umfangreiche Indizien, die die befragten Expert*innen aber auch wieder ganz unterschiedlich auslegen.
Interessant ist auch die Frage ob die Autor*innen der Schadsoftware hätten aggressiver vorgehen sollen. Es wäre vermutlich ‘leicht’ gewesen tausende von Zentrifugen zu zerstören, aber damit hätte man die Iraner auch direkt darauf gestoßen, dass irgendetwas grundsätzlich nicht stimmt.
Der Umgang staatlicher Stellen mit Zero Day Lücken
Stuxnet nutzte eine – zumindest für damalige Verhältnisse – ungewöhnliche große Anzahl von Zero Day Lücken – also vor ihrer Entdeckung in Schadsoftware zumindest bei den jeweiligen Softwareanbietern wie Microsoft unbekannte Lücken – aus. Insgesamt waren es 4.
Hier wird der Konflikt diskutiert den staatliche Stellen haben, die auf der einen Seite die Sicherheit ihrer Bürger und der Infrastruktur sichern sollen, aber auf der anderen Seite solche Lücken für Geheimoperationen in Reserve halten möchten. Teilweise sogar die gleichen staatlichen Stellen.
Seit damals hat sich einiges getan was Bug Bounty Programme angeht, aber der Markt für solche Lücken in wichtigen Systemen ist eigentlich nur noch größer geworden und die Preise viel höher, die Unternehmen wie Apple, Google oder Microsoft bieten müssen, damit sie halbwegs sicher sein können das Fehler in ihren global eingesetzten Produkten bei ihnen gemeldet werden, und nicht bei einer der vielen Plattformen, die sie an den Meistbietenden verkaufen.
Die Büchse der Pandora – geöffnet, aber nicht genutzt?
Das Ende des Buches wird die Metapher der Büchse der Pandora verwendet: Haben die Personen, die Stuxnet auf den Iran und letztlich auf die Welt losgelassen haben damit einen Präzedenzfall geschaffen, der sich nicht mehr ungeschehen macht? Ähnlich den Detonationen der ersten Atombomben?
Dieser Argumentation kann man sich kaum verschließen, aber es ist heute – 8 Jahre nach dem Erscheinen des Buches – festzustellen, dass vergleichbare Ereignisse seitdem nicht wieder bekannt geworden sind. Auch im aktuellen Angriffskrieg Russlands gegen die Ukraine scheinen solche Mittel eher nachrangig – wenn überhaupt – zum Einsatz zu kommen.
Tatsächlich kommen heute große Infrastrukturausfälle durch digitale Angriffe vor, siehe z. B. den Angriff auf die Colonial Pipeline, der zu massiven Störungen der Energieversorgung in den USA führte. Aber diese Angriffe werden von Kriminellen ausgeführt, denen es um Geld geht, nicht von Staaten oder Geheimdiensten. Und die viel simplere Sicherheitslücken ausnutzen und auf diese Weise teilweise überraschend tief in hochwichtige Systeme eindringen.
Das liegt vielleicht daran, dass sich eine digitale Waffe oft nur einmal einsetzen lässt, danach ist ihr Wirkmechanismus bekannt und kann abgestellt werden. Und der Angegriffene bekommt mit der Schadsoftware auch eine Blaupause dafür, wie diese Waffe funktioniert, und kann sie nachbauen. Das macht den Einsatz riskant und trotz der ‘Vorteile’ – hauptsächlich wie schwer es ggf. ist nachzuweisen, wer für einen Angriff verantwortlich war – nur für wenige Szenarien attraktiv.
Empfehlung
Wer sich für IT Sicherheit interessiert, aber dabei nicht rein für die Bits und Bytes, der findet hier interessanten Lesestoff in einer Tiefe, die sich mir damals, als das Thema ganz aktuell war, so nicht erschlossen hat.
Und 8 Jahre später die Prognosen zur Ausbreitung und zum Einsatz von digitalen Waffen mit der Realität vergleichen zu können ist ebenfalls spannend.
Es gibt eine neue Version des Anti-DoS-Valves, sie bringt die zusätzliche Konfigurationsoption nonRelevantPaths, die es in bestimmten Einsatzkonstellationen erleichtert das Valve punktuell zu öffnen, ohne dabei die Konfiguration sehr kompliziert und pflegeaufwändig werden zu lassen.
Das eigentlich interessante ist aber aus meiner Sicht das: Diese Version ist komplett auf einem ChromeBook entwickelt worden. Und das ging gut und zwar so:
Welcome to the containers project where we support running arbitrary code inside of VMs in Chrome OS
auch dieses Mal wahr macht. Auch wenn es darum geht innerhalb dieses Containers wieder andere Container auszuführen.
VS Code als Entwicklungsumgebung
Microsoft hat mit Visual Studio Code vielleicht nicht die allermächtigste Entwicklungsumgebung der Welt geschaffen, aber eine, die auf nahezu allem Plattformen ausgeführt werden kann. Auch die Inbetriebnahme auf meinem aktuellen ChromeBook, einem Acer Spin 713 mit i3 Prozessor und 8GB RAM, ging problemlos von statten und die Umgebung fühlt sich – zumindest mit meinem kleine Anti-DoS-Valve-Projekt, schnell und ruckelfrei an.
Schnell hat man seinen Code von GitHub geholt und VS Code hilft einem mit Vorschlägen für Extensions weiter. Da das meine ersten Gehversuche mit der IDE waren um so hilfreicher und mit netten Überraschungen versehen wie dem Hinweis der bereits enthaltenen Snyk Extension auf veraltete / unsichere Dependencies in der Maven Konfiguration.
Java und Maven habe ich separat installiert. Zwar scheint es als bringe VS Code dafür eine Möglichkeit, aber Amazons Corretto und Maven kann man auch so schnell installieren.
Eine Moment habe ich gebraucht um zu verstehen wo die Ergebnisse der JUnit Tests landen und bis jetzt habe ich auch nicht herausgefunden, wie man es hinbekommt, dass man bei gescheiterten Tests genau in der Programmzeile landet, in welcher der Test gescheitert ist. Aber für eine kleine Erweiterungsprogrammierung war das kein Showstopper.
Docker
Mit der Version 1.3.0 des Valves hatte ich eine Containter Konfiguration mitgeliefert, die es einem erlaubt das Valve mit geringem Aufwand in einem Tomcat Server auszuführen und zu testen.
Um das nun auch wieder nutzen zu können muss zuerst Docker installiert werden in der Linux VM. Das geht mit den Anweisungen auf der Docker Webseite problemlos. Und wie es das Versprechen der Containerisierung ist laufen die docker-Kommandos, welche ich exemplarisch in der README angegeben habe, auch hier problemlos. Nur musste ich ein sudo vor die Kommandos stellen, da ich noch nicht rootless unterwegs war:
Jetzt müsste man nur noch einen größeren Bildschirm an das ChromeBook hängen und schon könnte man flüssig auch größere Projekte damit angehen.
Beschäftigt man sich regelmäßig mit IT Sicherheitsthemen – etwa in dem man jede Woche den Security Now Podcast hört – gibt es immer wieder Momente in denen man völlig davon überzeugt ist, dass das Internet nur von Kaugummi und Klebeband zusammengehalten wird. Aber oft sind es auch Themen, die tief in die unheimlich komplex gewordenen Infrastukturen und Technologien führen, mit denen wir täglich hantieren. Das sind zwei Beispiele aus den letzten Wochen, die ich besonders spannend fand:
Trojan Source – UTF-8 und Tricks mit dem bidi Encoding 🔀
Bei der Prüfung eines Programmcodes kann man nicht mehr davon ausgehen, dass der Code, den man vor sich auf dem Bildschirm sieht, der gleiche Code ist, der später vom Compiler ‚gesehen‘ und in ein Programm übersetzt wird
So wie das Trojanische Pferd auch nicht das war, was es zu sein schien…Wenn man darüber einen Moment nachdenkt zieht es einem nach und nach das Fundament unter dem Füßen weg, auf dem die Überprüfung von Softwarequalität und -sicherheit von jeher stand:
Ein Mensch schaut sich in einem Editor den Quellcode, den ein anderer Mensch – oder inzwischen auch eine Maschine – geschrieben hat, versucht ihn zu verstehen und vergleicht ihn mit der Funktion, die der Code laut Pflichtenheft oder Eigenbeschreibung oder Stack Overflow Kommentar haben soll.
Im Paper werden nun unterschiedliche Verfahren beschrieben, wie man in Quellcode, der als Unicode gespeichert ist, subtile Täuschungen einschmuggeln kann. Und dabei kommt die Komplexität moderner Zeichensatzcodierungen, die den Anspruch haben letztlich jedes relevante Schriftsystem der Welt – und möglicherweise auch extraterrestrische – korrekt darstellen zu können, uns die Quere:
Neben vergleichsweise simplen Ticks wie dem Einfügen von breitenlosen und damit unsichtbaren Leerzeichen (Zero Width Space ZWSP), die Stringvergleiche scheitern lassen können, oder der Verwendung von Homoglyphen, die etwa zur Einführung alternativer Methodenaufrufe genutzt werden können, sind es die Nutzungen der Bidirectional Commands und davon gibt es einen ganzen Block:
Die lassen sich sogar verschachteln und ähnlich wie bei einem Stack in der Programmierung gibt es POP Anweisungen um Verschachtelungen wieder zu beenden und damit eine Schachtelungsebene nach oben zu gehen:
Gerade mit dem Isolates, die komplette Gruppen von Zeichen als gemeinsames Element behandeln, und Kombinationen von BiDi Anweisungen lassen sich leicht Fälle konstruieren, bei denen etwas, dass im Quellcodeeditor so aussieht:
...
/* Wenn Sicherheitsprüfung bestanden, dann return; */
if (check == true)
return;
else
throw new Exception("Keine Berechtigung!");
für den Compiler hingegen so erscheint:
...
/* Wenn Sicherheitsprüfung bestanden, dann */ return;
if (check == true)
return;
else
throw new Exception("Keine Berechtigung!");
Hier wird also aus dem scheinbaren Kommentar am Ende eine Programmanweisung, die die Logik komplett aushebelt. Das solche subtilen Änderungen manchmal weitreichende Probleme verursachen, dafür ist der goto fail;-Bug ein gutes Beispiel, den Apple vor Jahren in seinem Betriebssystem hatte. Hier sah der fehlerhafte Abschnitt so aus:
Die dritte Zeile durfte also nicht eingerückt sein. Manchmal reicht schon ein TAB um den Unterschied zu machen und in diesem Fall gab es Vermutungen, dass vielleicht jemand dafür bezahlt worden sein könnte diesen subtilen Fehler an einer entscheidenden Stelle einzubauen. Das Risiko der Entdeckung wäre gering gewesen und man hätte sich leicht damit herausreden können, dass es sich um einen Tippfehler gehandelt hat. Mit Hilfe der BiDi-Trickserei wäre dieser Fehler nicht einmal bei einem sehr sorgfältigen Code Review sichtbar gewesen.
Da die Forscher bereits reale Beispiele für die Anwendung dieser Technik gefunden haben ist das keine rein theoretische Bedrohung. Da sich solcher Code sogar per Copy-and-Paste übernehmen lässt sind beliebte Vorgehensweisen in der modernen Softwareentwicklung ebenfalls gefährdet. Also noch mehr gefährdet, als sie es immer schon waren 🙈
Was kann man tun?
Grundsätzlich wird man wohl abwarten müssen bis die Werkzeuge wie Editoren, Compilier und vielleicht auch Linter sich dieses Problems annehmen. Bis dahin gibt es vielleicht diese Faustformeln:
Gerade in den Quellcode eingebrachte Texte wie Kommentare und Strings sind Einstiegspunkte für diese Art von Angriff
Die Auswirkung der bidi-Tricksereien enden beim nächsten Zeilenumbruch. Eine einheitliche Quellcodeformatierung, die z. B. eingebettete Kommentare nicht in der gleichen Zeile stehen lässt wie Code, kann ein paar Varianten vermutlich aushebeln
Bei der Nutzung von fremden Programmcodes muss man noch stärker als bisher schon auf deren Qualität achten. Was immer schon notwendig, und immer schon schwierig war
HTTP Request Smuggeling 🧱⛏️
Aus Security Now 846: Auch dieses Problem wird durch Komplexität verursacht, aber auf einer ganz anderen Ebene: Hier geht es darum, dass zwei oder mehr hintereinander geschaltete Webserver, die am Bedienen eines Webrequests beteiligt sind, das dabei verwendete HTTP Protokoll nicht einheitlich interpretieren.
Und im Endeffekt unterschiedliche Vorstellungen davon haben, welche Webrequests sie eigentlich gerade verarbeiten.
Dieses Problem ist kein ganz neues Problem, aber heute noch relevanter, da es inzwischen gängige Praxis ist, dass mehr als ein Server am Ausliefern einer Seite beteiligt ist:
Proxy Server werden vor den eigentlichen Applikationsserver geschaltet, um die Last zu verringern
Webserver wie Apache oder nginx liegen vor den Applikationsservern um TLS zu terminieren oder Loginfunktionen – z. B. Shibboleth – zu übernehmen
Loadbalancer sind Netzwerkkomponenten, die die Zugriffe auf nachgelagerte Server verteilen, um Lasten gleichmäßig verarbeitbar zu machen
Dienste wie Cloudflare bieten ihren Kunden durch vorschaltete Systeme Schutz vor Denial of Service Angriffen, die eigentlichen Server sind nicht mehr direkt erreichbar
Und alle denkbaren Kombinationen davon….
Für die effiziente Kommunikation zwischen diesen Servern werden verschiedene Webrequests gerne hintereinander gehängt, damit sie sich schnell über die gleiche Verbindung übertragen lassen.
Aber wie schafft man es dem einen Server etwas anderes vorzugaukeln, als dem später drankommenden Server? In dem man die zwei Optionen, die der HTTP Standard als Mittel bietet um die Länge eines Request zu definieren – und damit bei hintereinander gehängten Requests zu definieren, wo der eine aufhört und der andere beginnt – so trickreich nutzt, dass die beteiligten Server zu unterschiedlichen Ansichten darüber gelangen, wo die Grenze zwischen zwei Requests liegt. Auch wenn es laut dem Standard eigentlich klar wäre, wie vorzugehen ist:
“According to the HTTP/1.1 standards, if both Content-Length and Transfer-Encoding headers are passed, Transfer-Encoding takes precedence.”
Auf diese Weise kann es bei anfälligen Serverkombinationen – und laut diesem Paper sind das viele – gelingen einen Zugriff auf einen Backend Server abzusetzen, der eigentlich von den davor geschalteten Servern gefiltert werden sollte. Das kann insbesondere dann relevant sein, wenn die vorgeschalteten Server das Login- und Rechtemanagement übernehmen.
Für eine bestimmte Variante des Request Smugglings vulnerable Serverkombinationen laut diesem Paper
Auch hier ist es nicht leicht etwas zu tun. Wie immer muss man natürlich seine Server aktuell halten, so gibt es z. B. für Tomcat inzwischen einen Patch für CVE-2021-33037, der auch mit HTTP Request Smuggeling zu tun hat. Aber auf das Verhalten vieler Komponenten, wie z. B. Loadbalancer, hat man wenig bis keinen Zugriff.
Eine Lösung ist es vielleicht die kritischen Entscheidungen einer Applikation – also die Rechte- und Zugriffskontrolle – möglichst weit nach hinten zu verlagern, bis in die Applikationsserver. Das nimmt einem Optimierungsmöglichkeiten, aber dafür ist der Server, der am Ende die Requests verarbeitet, auch derjenige, der entscheidet welche Requests zulässig sind.
Das die Tagesschau über Software berichtet ist in einer Zeit, in der die IT die Gesellschaft allmählich völlig durchdrungen hat, nicht ungewöhnlich. Aber wenn es um eine so alte Software geht dann doch: Der Internet Explorer geht in Rente und das nach einer 25-jährigen Geschichte.
Ich kann mich nicht mehr erinnern jemals ein aktiver Nutzer des IEs gewesen zu sein und bilde mir heute ein nach ersten Schritten im WWW mit Mosaic im Studium relativ schnell auf den Netscape Navigator gewechselt zu haben, und dann ohne ‚Umweg‘ auf das freie Folgeprodukt Mozilla Firefox. Seit dem Erscheinen von Google Chrome ist dies bis heute mein Hauptwebbrowser.
Aber als Webentwickler kam man lange nicht am Internet Explorer vorbei, jedenfalls für die Zeit, in welcher der IE – insbesondere in der ‚ewigen‘ Version 6 – die absolute Dominanz im Web hatte:
Von Wereon – Image:Browser Wars.png, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1128061
Bis 2002 hatte Microsoft mit seinem Browserprodukt durch die später von Gerichten bestrafte Bündelung mit dem Windows Betriebssystem den zuvor dominierenden Netscape Browser vom Markt gedrängt, damit den ersten Browserkrieg gewonnen und danach die Weiterentwicklung faktisch eingestellt und so die Fortentwicklung des Webs quasi eingefroren. Für viele Webentwickler*innen war es daher die einfachste Lösung Webseiten zu entwickeln, die sich nur auf diese Webbrowser konzentrierten. Noch heute findet man Seiten mit diesem damals allgegenwärtigem Hinweis:
In Deutschland war die Dominanz nie ganz so stark, insbesondere nicht im Umfeld der Hochschulen, da sich hier viele Verfechter von Open Source Produkten fanden und finden, und daher Firefox teilweise bis heute der Standardwebbrowser ist. Trotzdem konnte es einem auch in den 2010er Jahren noch passieren einem Bankberater gegenüber zu sitzen, der den Kreditvertrag in seiner Bankingsoftware in einer alten Version des Internet Explorers bearbeitete, da gerade im Finanzbereich die proprietäre ActiveX Technologie, die sich nur im IE nutzen ließ, im Einsatz war.
Auch der 2. Browserkrieg ist vorbei
Mit dem Aufstieg von Chrome begann der 2. Browserkrieg, der ebenfalls schon lange beendet ist, wie ein Blick in die heutige Verteilung der Webbrowsernutzung zeigt:
By StatCounter generated image – https://gs.statcounter.com/browser-market-share#monthly-202011-202011-bar, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=96191667
Microsoft hat nach letzten, gescheiterten Versuchen mit einem eigenständigen Browserprodukt die alte Dominanz zu erhalten mit dem aktuellen Edge Browser ebenfalls auf die Chromium Basis aufgesetzt, wie es der Opera Browser bereits seit 2013 tut. Jenseits der Apple Welt sind damit die Chromium-Browser heute ähnlich dominant, wie es vor langer Zeit der IE war. Allerdings ohne den Versteinerungseffekt, nun wird das Web in 6-Wochen-Zyklen weiterentwickelt, bald sogar alle 4 Wochen.
Bei der kleinen Docker-Bastelei im Anti-DoS-Valve-Projekt wollte ich das Projekt ‚gerade mal eben‘ auf Tomcat 10 hochziehen und bin direkt über eine wesentliche Änderung gestolpert, die mir bisher entgangen war:
Was bisher
import javax.servlet.*;
war muss nun
import jakarta.servlet.*;
sein 😮 Da sich das mit meinen Gehversuchen mit Docker überschnitt hat es einen Moment gebraucht um zu verstehen, wo eigentlich das Problem lag…
Was ist der Hintergrund
Natürlich das Urheberrecht und Oracle’s Wille die mal mit dem Kauf von SUN an Java gewonnenen Rechte auf keinen Fall Preis zu geben. Die entscheidenden Weichenstellungen sind dabei schon weit vor der Niederlage gestellt worden, die Oracle letztlich Anfang April 2021 in der Auseinandersetzung mit Google über die Java Nutzung in Android erlitten hat. Hier sind ein paar Quellen:
Der Artikel der Eclipse Foundation enthält diese Passage, die das Ende der Verwendung von javax.* ankündigt:
‘..Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications.’
Selbst der Name Java darf nicht mehr in den Spezifikationen wie JPA verwendet werden, die die Eclipse Foundation weiterentwickelt. Bei der Frage wie es nach EE8 weitergehen kann deutet sich die Entwicklung schon an:
‘What happens beyond Jakarta EE 8?
The guiding principle for Jakarta EE 9 will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation. This will most likely involve two key topics: migration of some or all of the Jakarta EE specification source to a new namespace for future evolution; means to provide backwards compatibility with javax at a binary level, allowing old applications to run on Jakarta 9 implementations with some form of build or runtime tooling.
So while there will be a point in time where future versions of specifications will have to go through a source code incompatible change with respect to the previous javax based packages, this will be a straightforward transformation.’
Eine Frage war es dann ob die Migration weg von javax.* inkrementell erfolgen würde – also nur der Teile, die Veränderungen unterliegen – oder als Big Bang gemacht wird. Die Antwort liefert der vergleichende Blick in die Javadocs der Servlet 4 und 5 APIs:
Servlet API 4Servlet API 5
Der Post Jakarta EE 9 Delivers the Big Bang im Life at Eclipse Blog beschreibt das Vorgehen noch einmal zum Start von EE9. Die Logik dahinter – es wird ein klarer Schnitt gemacht – finde ich durchaus nachvollziehbar. Aber was macht man nun mit Anwendungen, die auf großen Codebasen sitzen und diverse externe Pakete verwenden, die alle noch nicht umgestellt sind?
Was tun mit den Altanwendungen (in Tomcat)
Alles was vor EE9 an Webanwendungen entwickelt wurde ist damit nun plötzlich eine migrationsbedürftige ‚Altanwendung‘. Aber selbst die Befürworter*innen des Big Bangs erkennen an, dass das JEE Ökosystem einfach zu groß ist, als das man innerhalb kürzester Zeit von allen Anbieter*innen von Servern, Anwendungen, Paketen ein Mitziehen erwarten könnte. Es sind also Übergangslösungen gefragt.
scheint das Deployment durch Kopieren der WAR-Datei in den <CATALINA_HOME>/webapps-Order zunächst wie gewohnt zu arbeiten, die Datei wird entpackt und die statische Startseite wird im Browser angezeigt. Der Aufruf des Servlets scheitert aber mit einer 404-Meldung, jedoch ohne eine Fehlermeldung in den Tomcats-Logs 🤔
Das Deployment funktioniert erst, wenn man wie in der Migrationshilfe beschrieben einen <CATALINA_HOME>/webapps-javaee-Order anlegt und die WAR Datei dort platziert. Dann passiert beim Start das hier:
Tomcat bemerkt die ‚Altanwendung‘ und migriert sie in die neue Welt. Das Ergebnis befindet sich dann im üblichen <CATALINA_HOME>/webapps-Order. Bei der Minianwendung hat das problemlos funktioniert. Die spannende Frage ist dann wie es sich mit komplexeren Anwendungen verhält.
Noch nicht klar geworden ist mir aber ob man bei der Weiterentwicklung von Altanwendungen nun erst einmal auf Tomcat Versionen <10 festgelegt ist, oder ob es auch da einen Weg gibt mit dem aktuellen Tomcat weiter zu machen.
Fazit
Das sich die Eclipse Foundation dazu entschieden hat die Verbindungen zu Oracle und den Teilen von Java, bei denen Oracle sehr viel Wert darauf legt die eigenen Urheberrechtsansprüche zu betonen, ist sicher ein richtiger Schritt. Aber es wird weltweit viel Arbeit machen die betroffenen Systeme auf allen Ebene darauf umzustellen.
Bis sich dieser Aufwand dann gelohnt haben wird, wird viel Zeit ins Land gehen. Und wer weiß ob es nicht Fälle gibt in denen dieser Aufwand das noch fehlende Argument liefert sich von Java im Backend abzuwenden.
Im /docker-Unterzeichnis des Projekts findet sich nun eine Docker-Konfiguration, mit der sich sehr einfach ein Tomcat 10 Server mit einkonfiguriertem Valve und einer Testmöglichkeit als Containerinstanz starten lässt. Entweder um das Ganze einmal schnell auszuprobieren, oder um bei eigenen Weiterentwicklungen ohne Basteleien und manuelles Hin- und Herschieben von JARs und Konfigurationen schnell die letzte Version des Valves direkt ausführen zu können.
Ich bin noch nicht so routiniert mit Docker, daher gehe ich hier einmal die Inhalte des /docker-Verzeichnisses durch und falls eine Leserin oder ein Leser dazu Verbesserungsvorschläge hat freue ich mich:
Dockerfile
Es ist nahezu leer:
FROM tomcat:10-jdk16-corretto
Nur das Tomcat 10 Image von Dockerhub wird referenziert. Ich hätte hier schon die angepasste server.xml oder das Valve Jar in das Image bringen können, aber gerade für Entwicklungszwecke erschien es mir zu umständlich jedes Mal ein neues Image zu bauen. Tatsächlich hätte es das Dockerfile im Moment gar nicht gebraucht, es hilft in der jetzigen Form nur die unten beschriebenen Kommandozeilen von späteren Änderungen des verwendeten Tomcat Images zu isolieren.
Falls man aber ein Tomcat Image für produktive Zwecke bauen möchte, in dem das Valve schon enthalten ist, wäre es sicher eine gute Idee die Valve Anpassungen bereits hier zu integrieren und mindestens das Jar schon in das Image aufzunehmen.
README.md
Hier sind die Kommandos enthalten, die es braucht um den Tomcat samt Valve zu starten. Interessant ist dabei eigentlich nur dieses Kommando:
In den drei mount-Anweisungen werden drei Dateien/Order aus dem Host-System in den Container abgebildet und überdecken dabei die schon vorhandenen Dateien im Container:
JAR: Das Jar, welches sich eins höher im /target-Verzeichnis befindet, wird in das /lib-Verzeichnis des Tomcats im Container gebracht und steht dem Server damit zur Verfügung. Das Jar muss natürlich vorher schon gebaut worden sein
server.xml: Hier wird eine angepasste Version der server.xml, die sich im Tomcat Image befindet, in den Container gesetzt. Dadurch werden die Valve Konfigurationen wirksam
/advdemo: Dieser Ordner enthält eine JSP – siehe unten – und wird als Webapp eingebracht, die der Tomcat klaglos ausführt
Alle mounts werden als readonly deklariert, damit in keinem Fall der Server im Container etwas zurückschreiben kann. mounts benötigen absolute Pfad, damit die Anweisung trotzdem immer funktioniert wird der aktuelle Pfad eingesetzt. Hier für Windows, für Linux sind entsprechende Anpassungen notwendig.
Es wird ein Portmapping gemacht, dabei wird nicht der sonst übliche Port 8080 verwendet, um nicht in Konflikt mit anderen auf dem Host laufenden Servern zu kommen.
Schließlich wird ein Name vergeben, unter dem sich der Container ansprechen lässt. Das verhindert, dass man einen beendeten Container einfach erneut starten kann und ihn erst entfernen muss. Ich bin mir noch nicht sicher, ob ich das wirklich praktisch finde.
server.xml
Die server.xml Datei, mit der Tomcat 10 Distribution mitgeliefert wird, um 2 Valve Konfigurationen ergänzt. Wenn man alternative Konfigurationen ausprobieren will kann kann man einfach die Datei bearbeiten und den Container neu starten.
/advdemo-Ordner
Hier ist nur eine JSP enthalten, die für die Demonstration des Marking Modes des Valves benötigt wird. Sie wird als eigene Webapp in den Tomcat gebracht und ist dann dort ausführbar.
Schnelle Iterationen
Durch die Containerlösung, die sich in Sekunden hochfährt, ist es einfach neue Versionen des Valves, der server.xml oder auch der JSP auszutesten, deutlich schneller als mir das bisher mit einer separaten Tomcat Instanz möglich war. Auch der rasche Wechsel zwischen unterschiedlichen server.xml Dateien ist einfach, man muss sich nur eine alternative Kommandozeile zurechtlegen. Und dafür ist keine ‚Magic‘ mit in Eclipse und Co. integrierten Tomcats notwendig, alles sind einfache Kommandozeilen, die sich schnell ausführen und und anpassen lassen.
Die Vorbesitzer*innen meines aktuellen ASUS C443T Chromebooks haben wohl häufig Chips beim Streaming gegessen, jedenfalls waren einige Tasten sehr schwergängig. Obwohl man unzählige Videos zu Tastaturreparaturen im Netz findet ist mir keins untergekommen, welches die (De)Montage genau dieses Modells zeigt. Daher hier mein Beitrag zum großen Wissensspeicher:
Die Tasten verhalten sich etwas unterschiedlich:
Die normalgroßen Tasten sind am oberen Rand eingeklickt, man zieht sie also dort hoch bis sie ausrasten. Das kleine Gerüst darunter ist mit 4 Haken am Grund befestigt, ich konnte es beschädigungslos lösen in dem ich auch am oberen Rand ansetzte
Bei den schmalen Tasten am oberen Rand der Tastatur ist es genau umgekehrt, aber das Prinzip identisch
Die Leertaste hat eine etwas andere Konstruktion mit zwei Drähten, an denen die Taste eingeklemmt ist. Hier scheint es egal zu sein, von welcher Seite man zieht, aber vielleicht gibt es hier auch spezielles Werkzeug mit dem man weniger den Eindruck hat gleich etwas zu zerbrechen
Auch andere große Tasten wie Shift haben zusätzliche Drähte, hier sind weitere Bauformen zu finden
Ich habe hier Hilfsmittel verwendet, die sonst für den Tausch von Handydisplays verwendet werden, also einen kleinen Schraubendreher und ein Plektrum.
Beim Einbauen geht man umgekehrt vor, hängt also die Tasten zuerst auf der Seite ein, in der sie nicht einklicken. Beim Andrücken der kleinen Gerüste muss man etwas darauf achten die Metallhaken nicht zu verbiegen.
