Martins key.matiq-Blog

>> Zurück zum Artikelverzeichnis >>

Kompliziert, aber gelöst

Geschrieben: 27.09.2026
Stichwörter: Grundsätze, Nähkästchen

Im Bog-Artikel "Einfach" habe ich gezeigt, dass es oft viel einfachere Lösungen für Probleme gibt, als man zunächst denken mag. Umfangreiche Programmierarbeiten lassen sich meist in die Entwicklung kleinerer einfacher Komponenten teilen, die schließlich nur noch zusammenzufügen sind.1

Manchmal aber versagt dieses Prinzip, nämlich dann, wenn verschiedene Aspekte miteinander so verwoben sind, dass das Aufteilen in Einzel-Arbeiten gar nicht einfach ist.

Ein Beispiel dafür habe ich bei key.matiq bei Geheimnissen mit hochzuladenden Datei, erlebt.

Warum braucht man in einem Passwortmanager überhaupt hochgeladene Dateien?

(Die Frage ist berechtigt, denn überflüssige Features, die auch noch die Komplexität erhöhen, sollte man tunlichst vermeiden.)

Wenn man alle digitalen Geheimnisse an einem Ort hat, sind diese leichter zu schützen, als wenn man mehrere solche Stätten zu verwalten und zu sichern hat. Z. B. macht es Sinn, eine digitale Kopie eines handschriftlichen Testaments zu sichern.2

Sind geheime Dateien nicht genauso verschlüsselte Zeichenketten wie Kennwörter?

Ja, aber bei Dateien muss man mit einem anderen Umfang rechnen. Bei der Ansicht eines Geheimnisses kann man leicht alle kurzen Zeichenketten vom Server3 herunterladen und bei Änderungen auch wieder hochladen. Das unnötige Herunterladen und Hochladen von Dateien könnte aber Client, Server und Netz stark belasten. Deshalb wird dies nicht bei jeder Ansicht oder kleinen Änderung gemacht, sondern nur auf Anforderung.4

Aber das ist doch alles Standard, wo wird es denn kompliziert?

Das Problem ist, dass Dateien ja auch Malware beinhalten können. Wenn Dateien mit anderen geteilt werden, müssen sich die Empfänger*innen auch versichern können, dass ihnen nicht infizierte Files untergeschoben wurden.

Wir bieten einen Malwarescan an. Die Empfänger*innen können also empfangene Dateien scannen lassen. Aber es ist auch nötig, dass bereits die Sender*innen die Datei scannen lassen können.5

D. h. in der Bearbeitungsansicht brauchen wir für eine Datei folgende Möglichkeiten:

  • Datei zum Hochladen auswählen
  • Datei scannen
  • Hochgeladene Datei entfernen
  • Hochgeladene Datei durch andere ersetzen
  • (Hochgeladene Datei herunterladen6)

Ist die Datei in einem vom Browser anzeigbaren Format (z. B. Text, PDF, XML, Bildformate), so ist es ganz nett, wenn man sie auch direkt anzeigen lassen kann, bevor sie hoch oder heruntergeladen wird. Das ginge über:

  • Hochgeladene Datei anzeigen
  • Zum Hochladen vorgesehene Datei anzeigen

Nun besteht aber ein Geheimnis gewöhnlich aus mehreren Bausteinen und diese sollten immer zusammenpassen. Deshalb sollen die Bearbeitungsschritte nicht sofort ausgeführt werden, sondern erst, wenn auf "Speichern" geklickt oder getippt wird.7

Das heißt dann aber auch, dass man vor dem Speichern vorgenommene Aktionen wieder rückgängig machen können muss. Also sind die ebengenannten Möglichkeiten genauer wie folgt zu beschreiben

  • Datei zum Hochladen auswählen (die ggf. bereits hochgeladene Datei ersetzen soll
  • Zum Hochladen vorgesehene Datei scannen
  • Auswahl der zum Hochladen vorgesehenen Datei rückgängig machen
  • Hochgeladene Datei scannen
  • Zum Hochladen ausgewählte Datei scannen
  • Zum Hochladen vorgesehene Datei anzeigen
  • Entfernung der hochgeladene Datei vorsehen
  • Das Entfernen der hochgeladene Datei nicht mehr vorsehen
  • Hochgeladene Datei herunterladen
  • Hochgeladene Datei anzeigen

Diese Liste ist nun deutlich umfangreicher und komplizierter. Für eine Softwareentwickler*in wäre es zwar aufwändig, aber vergleichsweise einfach, diese abzuarbeiten. Für die Benutzer*in wäre sie aber völlig unübersichtlich

Ein Grund für die hohe Anzahl der Aktionen liegt darin, dass bei clientseitiger Verschlüsselung Dateien vor dem Abspeichern gescannt werden müssen.8

Ich denke, dass die Einfachheit der Benutzung wichtiger ist, als dass es sich die Entwickler*in einfach macht. Für die Benutzung kommt man nämlich im konkreten Fall mit jeweils nur ein paar Schaltflächen aus, z. B.

  • Wenn noch gar keine Datei hochgeladen ist:
    • Datei zum Hochladen auswählen
  • Wenn schon eine Datei hochgeladen ist, aber noch nichts verändert wurde:
    • Hochgeladene Datei herunterladen
    • Datei zur Ersetzung der hochgeladenen auswählen9
    • Hochgeladene Datei scannen
    • Entfernung der Datei vorsehen
    • (Nur bei bestimmten Dateitypen: Datei anzeigen)
  • Wenn schon eine Datei hochgeladen ist, aber durch eine andere ersetzt werden soll
    • Ausgewählte Datei scannen
    • (Evtl.: Ausgewählte Datei anzeigen)
    • Andere Datei zur Ersetzung der hochgeladenen auswählen
    • Auswahl der ersetzenden Datei rückgängig machen

Die obige Liste der Zustände und dann möglichen Aktionen ist nicht ganz vollständig, aber sie zeigt, dass wenn man die angebotenen Schaltflächen von dem jeweiligen Zustand abhängig macht, diese meist deutlich übersichtlicher sind.

Die Programmierung ist nun keineswegs so einfach, wie die Benutzungsschnittstelle. Zum Glück gibt es aber gute Techniken, solch komplexe Situationen in den Griff zu bekommen.10 Das beschriebene Beispiel war tatsächlich die bislang komplizierteste Einzelaufgabe in der Entwicklung von key.matiq. So etwas passiert schon mal, und man sollte sich nicht davor drücken. Wie Einstein so schon sagte: "Man sollte die Dinge so einfach machen wie möglich, aber nicht einfacher."11

 

1) Siehe Wikipedia "Teile-und-herrsche-Verfahren". Natürlich bleibt die Arbeit als solche immer noch umfangreich, aber sie lässt sich bei genügender Ausdauer bewältigen.

2) Natürlich ersetzt die digitale Kopie nicht das Original, aber mit der Kopie kann man nachweisen, dass es das das Original geben muss, d. h. es ist für Nicht-Erben nicht so einfach, letzteres verschwinden zu lassen. Digitale Dokumente kann man z. B. mit key.matiq an andere übertragen und bei Veränderung auch bei den Empfänger*innen aktuell halten. Eine versiegelte Übertragung ist ebenso möglich, so dass die Empfänger*innen erst nach dem Tod der Absender*in das Dokument einsehen können.

3) Wir haben nicht umsonst key.matiq als Web-App, also als Software as a Service (und nicht als App) implementiert:

  • Web-Apps sind sicherer als Apps, denn:
    • Sie können gar nicht auf das Gerät der Nutzer*in zugreifen. (Selbst bei Manipulation der Software wäre es viel schwerer, damit Schaden auf dem Gerät der Nutzer*in anzurichten.)
    • Sie sind immer auf dem neuesten Stand. (Updates sind nicht erforderlich.)
  • Mit Web-Apps ist die Verteilung von Geheimnissen an Mitwisser*innen über den Server recht einfach.
  • Die Wahrung des Datenschutzes ist genausogut möglich bei Web-Apps, wie bei Apps, wenn kritische Daten verschlüsselt werden und Ver- und Entschlüsselung clientseitig (d. h. im Browser per JavaScript) erfolgt.
  • Bösartige Veränderungen der Software sind gleichermaßen möglich bei Apps und Web-Apps. Allerdings lassen sie sich leichter nachweisen bei Web-Apps, da die Nutzer*in die Quellen einsehen (und auch, z. B. um Test-Prints einzufügen, verändern) können. (Bei Apps gibt es diese Chance in der Regel nicht, es sei denn sie sind in Skript-Sprachen geschrieben.

4) Manchmal sind Dateien so groß, dass sie gar nicht in eine kostengünstige key.matiq-Box passen. Für diese Fälle bieten wir die Möglichkeit an, sie mit einem Dateiverschlüsseler ver- und entschlüsseln zu lassen. D. h. die verschlüsselte Datei wird nicht auf dem Server gespeichert und direkt an Mitwisser übertragen, sondern die verschlüsselte Datei wird auf dem eigenen Rechner der Nutzer*in gehalten und kann von ihr an andere z. B. per E-Mail übertragen werden. Den Dateiverschlüsseler kann sie aber über key.matiq mit anderen teilen. (Etwas komplizierter als die direkte Übertragung der Datei, aber doch noch leicht machbar. Dieses Ausnahmeverfahren für größere Dateien ermöglicht immerhin, key.matiq-Boxen sehr viel günstiger anzubieten, als dies beim Mitbewerb der Fall ist.)

5) Wie stünde denn eine Sender*in da, wenn sie eine Datei verschickt hat, die später als virusbehaftet klassifiziert wird? Sie muss also mindestens die Möglichkeit haben, sie vorab selbst zu prüfen.

6) Diese Möglichkeit ist hier nicht unbedingt erforderlich, da es auch noch die Anzeigeansicht12 gibt, aber sie verkompliziert die Sache nicht sehr und ermöglicht der Benutzer*in, die vorhandene Datei sich vor der Veränderung noch einmal anzuschauen, ohne die Ansicht zu wechseln.

7) Wäre es nicht viel einfacher, alles doch sofort zu auszuführen? Man könnte dann das "Speichern" gar nicht erst vergessen (schließlich findet man solch ein Verhalten oft bei Ansichten in Apps)?
Bei einer Web-App wäre es nur mit viel Aufwand möglich, so etwas sicher zu implementieren, denn die Verbindung kann ja auch mal abreißen, dann wäre nur ein Teil der Änderungen erfolgt, andere vielleicht nicht. D. h. ohne eine nachträgliche Analyse und ein evtl. Rollback wäre das ungut.

8) Bei serverseitiger Verschlüsselung kann für das Scanning in der Ansicht einfach eine Checkbox (ein Kontrolkästchen / Optionsfeld) angehakt werden. Dann weiß der Server beim Speichern, dass er vor dem Verschlüsseln die Datei zu scannen hat.
Bei clientseitiger Verschlüsselung erhält der Server beim Speichern bereits die verschlüsselte Datei und ist nicht mehr in der Lage, diese zu entschlüsseln.
Um die Datei dennoch scannen zu können, muss der Client (mit Erlaubnis der Box-Besitzer*in) ausnahmsweise die Datei an den Server im Klartext schicken. (Die Übertragung läuft schon verschlüsselt, aber serverseitig kommt letztlich der Klartext an.) Die Datei wird auf eine RAM-Disk gelegt, vom Virenscanner gescannt, dann gleich wieder überschrieben und dann gelöscht (also komplett inhaltlich gelöscht), während nur das Ergebnis dem Server übergeben und schließlich dem Client mitgeteilt wird. Dieses Ergebnis findet, wenn es nicht durch weitere Änderungen (z. B. Auswählen einer anderen Datei) obsolet wird, beim letztendlichen Speichervorgang den Weg vom Client zum Server.
Es ist also schon an sich ein recht aufwändiger Vorgang, der auch noch berücksichtigen muss, dass eine Verfälschung des Scan-Ergebnisses durch den Client nicht möglich darf.13
Doch Aufwand ist eine Sache, Komplexität ist eine andere. Und die Komplexität kommt eben dadurch zustande, dass durch die Kombi von clientseitiger Verschlüsselung und der Notwendigkeit eines optionalen Malwarescans der Client viele verschiedene Zustände annehmen kann.

9) key.matiq zeigt die noch gepeicherte Datei mit an, aber mit durchgestrichenem Dateinamen. Damit wird verdeutlicht, dass die zu ersetzende Datei vorerst noch vorhanden ist. Aber solange die Ersetzung nicht rückgängig gemacht wurde, wird mit ihr auch nichts mehr gemacht. Die Tooltips der Schaltflächen machen dies unmissverständlich klar.

10) Die Lösung heißt "Finite State Machine" oder "Endlicher Automat". Damit werden die verschiedenen Zustände und Zustandsübergänge systematisch beschrieben und die nötigen Aktionen (für jeden Zustandsübergang) implementiert.

11) "Everything should be made as simple as possible. But not simpler." Siehe auch Zitate berühmter Personen.

12) Warum gibt es überhaupt noch eine Anzeigeansicht extra? Bei einem Passwortmanager geht es ja auch darum, keinesfalls Daten zu verlieren oder unbeabsichtigt zu ändern. Meist besucht man den Passwortmanager ja, um etwas nachzuschauen, viel seltener, um etwas zu verändern. Dann ist es einfach sicherer, statt der Bearbeitungsansicht, eine Anzeigeansicht zu nutzen.

13) Das Problem bei clientseitiger Verschlüsselung ist, dass ja eine Sender*in eines Geheimnisses theoretisch immer in der Lage ist, JS-Skripte zu manipulieren. Und das ist ja genau der Punkt: Wenn die Sender*in der Empfänger*in Malware unterschieben möchte, dürfte sie auch die Motivation haben, das Scan-Ergebnis zu verfälschen.
Man kann aber eine Verfälschung von Scan-Ergebnissen verhindern, indem diese kryptographisch signiert werden: Man nimmt den kryptographischen Hash des gescannten Inhalts und das Scan-Ergebnis und signiert es serverseitig. Empfangsseitig wird dann später vor der Anzeige des Scan-Ergebnisses überprüft, ob es überhaupt gültig ist: Für den Klartext-Inhalt wird wieder (diesmal auf Seiten der Empfänger*in) der kryptographische Hash ermittelt und für diesen Hash, das empfangene Scan-Ergebnis und die empfangene Signatur mit Hilfe des Servers auf Gültigkeit hin überprüft.

>> Zurück zum Artikelverzeichnis >>