Du hast etwas Zeit über und magst lange Texte? Sicherheit in der IT ist genau Dein Ding? Dann lies Dir mal bitte folgende zwei Fallbeispiele durch und entscheide für Dich selbst wie funktionierende Sicherheit hier jeweils aussehen müsste.

Die Idee ist doch super. Und sicher ist das auch. Ich erkläre mal das Verfahren: Ich erstelle ein zufälliges Passwort welches ich jemand Drittem übertragen muss. Nun melde ich mich an der Webseite eines Cloud-Dienstes an. Das Formularfeld mit dem Passwort wird allerdings bevor es an die Cloud geschickt wird noch entsprechend verschlüsselt. Per Javasript in meinem Webbrowser. Was da also übertragen wird ist ein bereits verschlüsseltes Passwort. Dazu kommt, dass die Seite per https geöffnet ist. Also nochmals verschlüsselt. Das so verschlüsselt übertragene verschlüsselte Passwort wird in der Passwort-Austausch-Cloud abgelegt. Nun muss die Cloud-Plattform dem Empfänger noch mitteilen, dass es hier ein Passwort für ihn gibt. Zum Beispiel per Mail. Also erhält der Empfänger einen Download-Link, kann via https das verschlüsselte Passwort verschlüsselt übertragen und in seinem Webbrowser per JavaScript wieder entschlüsseln. Voila, schon sieht er das von mir erstellte Passwort im Klartext.

Doch Moment, das Ganze hat doch irgendwo einen Haken. Eine Plattform, welche jemand Drittes darüber informiert, dass ein Passwort da ist. Eine Plattform in der Cloud. Die wird wohl via Email benachrichtigen. Könnte ich, anstatt eine zusätzliche Plattform zu verwenden, hier nicht direkt eine Email an den Empfänger senden? Ja, klar – das könnte ich tun. Das würde die Cloud-Plattform einsparen. An der Sicherheit des Verfahrens hätte sich so noch nichts geändert: Ich verschlüssele das Passwort bevor ich es übertrage, übertrage es irgendwie, der Empfänger entschlüsselt das Passwort. Das „übertrage es irgendwie“: Ist doch egal ob Cloud-Plattform oder Email?

Doch schon wieder stopp, halt. Die Cloud-Plattform könnte den Download auf einmal beschränken. Ok, da seh ich jetzt gedanklich zwei Dinge über die man mal nachdenken könnte:

• Es gibt Virenscanner die aus Sicherheitsgründen von zu herunter ladenden Inhalten einen Prefetch machen. Der erste Downloadversuch könnte also bereits beim Scanner scheitern. Zugegeben selten, habe ich aber schon mehrfach erlebt.
• Das hier finde ich ist der spannendere Punkt: Was macht der Empfänger mit diesem einmaligen Download? Er speichert ihn. Damit er ihn öfters lesen kann. Einmal übertragen, aber beliebig oft lesen. Das kann ich nicht beeinflussen. Richtig? Richtig. Dann hätte es auch eine Mail getan: Einmal übertragen, aber beliebig oft lesen. Finde den Unterschied.

Ihr seht schon, es braucht vom Grundsatz her keine Passwort-Austausch-Cloud-Plattform. Email kann das auch. Doch schon wieder Moment, stopp: Da ist doch noch was anderes? Einen ganz wichtigen Punkt habe ich noch gar nicht angesprochen: Ich verschlüssele das Passwort im Browser bzw. für die Mail und übertrage… Ja mit was hab ich den das Passwort verschlüsselt? Mit einem Passwort? Ach, spannend. Und wie übertrage ich dies? Per Email? Ja klar, mit dem Link zum Download bzw. dem verschlüsselten Passwort… Ach nein, Selbstironie Ende. Ich versuche dem gegenüber das Passwort via Telefon zu übertragen. 64 Zeichen: Groß- und Kleinbuchstaben. Dazu noch Ziffern. Schlimmer sind die Sonderzeichen. Da sind einige dabei wo ich nicht mal weiß wie die heißen. Kann Dir nicht passieren? Ok, wie heißen den die beiden hier `und ´? Oder diese beiden hier: ° und µ? Vor allem letzterer: Zeichen wie µ gibt es viele. Bei mir auf meiner Tastatur ist sogar das hier drauf ». Nur weil keine Taste damit beschriftet ist, ist es trotzdem da und kann verwendet werden. Was jetzt?

Nein, Telefon macht hier wenig Spaß. Dann lieber eine Textdatei an eine Email angefügt: 50 nummeriere Zeilen mit möglichen Passwörtern. Dazu geht der Telefonanruf an den Empfänger mit dem Hinweis Zeile 12, allerdings alle „a“ durch „@“ ersetzen, das gleiche für „3“ welches zum „Ä“ wird usw.

Diese Variante braucht einen Telefonanruf und eine Email. Wer will kann die vermeintliche Sicherheit noch zusätzlich erhöhen in dem er die Datei per einmaligem Downloadlink anbietet. Das können inzwischen viele der Dateiplattformen für die Cloud. Bevor wir jetzt an der Stelle ebenfalls wieder ausschweifen mal eine Zusammenfassung der bisherigen Situation.

Zusammenfassung Fall 1

Ok, lasst uns mal 1:1 zusammenzählen was wir erarbeitet haben: Eine Plattform welche Passwörter verschlüsselt um diese verschlüsselt zu übertragen… Irgendwann müssen diese Daten entschlüsselt werden. Wieder per Passwort? Das hat das Problem der Klartextübertragung des Passwortes nur an eine andere Stelle verschoben. Es gibt weiterhin ein Passwort welches im Klartext vorliegt. Aber hat sich die Sicherheit dadurch verbessert? Nicht wirklich: Das Verfahren wurde komplexer, komplexere Verfahren sind anfälliger für Fehler. Und was ist wenn der Download nur einmal angeboten wird? Das würde ja bedeuten, dass es möglich ist das verschlüsselte Passwort bei der Übertragung abzufangen. Ansonsten könnte man den Download mehrfach anbieten: Es kommt doch eh nur die berechtigte Person dort hin. Oder doch nicht? Dieses Problem versuche ich zu umgehen indem ich den Download nur einmal anbiete. Es ist möglich, die Daten abzugreifen. Jetzt speichert der Empfänger die Daten irgendwo. Weil er sie nicht gleich braucht sondern erst in ein paar Tagen dazu kommt. Warum auch immer. Es ist möglich, die Daten abzugreifen. Ihr seht schon: Hat nichts an der Sicherheit geändert, nur der Ort wo ich die Daten abgreifen muss wurde geändert. Komplexität löst keine einfachen Probleme.

Und eine kritische Frage zum Schluss: Gibt es eine große, bekannte und etablierte Plattform zum Austauschen von Passwörtern die diesem Verfahren folgt? Was wäre wenn diese von einem der großen Konzernen mit fragwürdigem Ruf zum Thema Datenschutz angeboten werden würde? Na dann lieber auf den Codeplattformen git und Co gesucht. Da findet sich was. Dank opensource ist das sicher. Ach, ist das so? Den Quellcode selbst geprüft? Du vertraust der Person welche behauptet sie hätte den Quellcode geprüft? Was soll schon passieren, ist doch opensource. Ich mag opensource, das ist kein Geheimnis. Aber wenn das so wäre, wäre opensource per Defintion fehlerfrei. Das ist ein Reifegrad an Software den selbst kommerzielle Produkte wohl nie erreichen werden.

Als Lösung für dieses Thema wurde folgendes Vorgehen vorgeschlagen: Eine Weiterleitung an den extern Mailserver via SMTP ist unerwünscht. Stattdessen wäre ein abholen der Mails via IMAP gewünscht. Allerdings sollte sichergestellt werden, dass der IMAP-Server das richtige Zertifikat vorweist. Doch wann ist ein Zertifikat gültig? Die übliche Vorgehensweise ist prüfe ob der Name des Zertifikats zum  zu kontaktierenden Host passt, dass das Zertifikat im Gültigkeitszeitraum liegt und, dass der Aussteller des Zertifikats in der Liste der vertrauenswürdigen Herausgeber liegt.

Hilft das allerdings gegen Man-In-The-Middle? Nein, nur bedingt. „Gültige“ Zertifikate sind ein leichtes zu bekommen. Am sichersten wäre dies Prüfung zu erweitern: In dem man den Fingerabdruck des Zertifikats mit prüft. Allerdings muss man jetzt jedes mal den Fingerabdruck aktualisieren wenn die Gegenseite das Zertifikat verlängert. Und das kann oft der Fall sein – vor allem dann, wenn eines der kostengünstigen Zertifikate mit kurzer Laufzeit verwendet wird. Aber nein, das will der Kunde nicht. Zu aufwändig. Eine allgemeine Prüfung des Zertifikats reicht aus.

Finde den Fehler. Schon einmal darüber nachgedacht was eigentlich erreicht werden sollte? Und was tatsächlich erreicht wird? Da passt eins und eins alles andere als zusammen. Der Kunde will, dass Emails von seinem System sicher zu einem Dritten weitergeleitet werden. Erreicht wird, dass der Dritte prüft von welchem Server er die Mails abholt. Spannende Frage: Was ist wenn er das nicht prüft? Würde das der Kunde mitbekommen? Nein, tut er nicht. Nächste Frage: Der Kunde will, dass die Daten sicher zum Dritten übertragen werden. Per IMAP. Prüft der Kunde wer da gerade die Emails abholt? Also ob der wo gerade den Benutzernamen und das Passwort eingibt auch wirklich der ist den er vorgibt zu sein? Die Sicherheit ist an der Stelle reduziert auf den Benutzernamen und das Passwort. Egal wo und wie verschlüsselt wird. Benutzername und Passwort. Die kann jeder eingeben und verwenden wo diese Daten kennt. Egal ob berechtigt oder nicht.

Das kann so also nicht funktionieren und muss anders gelöst werden. Nur wie? Deswegen rasch nochmal die vier Gründe für Verschlüsselung aufgetischt:

1. Vertraulichkeit
2. Integrität
3. Authentizität
4. Verbindlichkeit

Na, das trifft es doch! Der Kunde will, dass nur der berechtigte Dritte die Daten, also die Emails, lesen darf. Seine Beweggründe sind gefunden, es sind die üblichen Verdächtigen. Nur wie werden die bei IMAP erreicht? Das Ziel, welches der Kunde will sind die 4 gezeigten Punkte. Und die erreicht man über die üblichen, verdächtigen Wege: Der IMAP-Server muss sicherstellen, dass er nur dann Emails überträgt wenn der Benutzer „ausreichend“, gemäß den 4 Punkte, authentifiziert ist. Das kann zum Beispiel dadurch passieren, dass der IMAP-Server neben seinem eigenen Zertifikat noch gleich noch für die Authentifizierung das vom IMAP-Client prüft. Nur wenn er dieses kennt, dann ist alles ok. Oder, wer den Schritt nicht mag: Den IMAP-Server hinter ein VPN gepackt. VPN bringt von sich aus ebenfalls die obigen 4 Punkte mit.

Finale

Ist das oben erklärte die ultimative Lösung für die beiden Fälle? Sicherlich nicht. Zeigt die Diskussion, dass beim Thema Sicherheit durchaus Gesprächsbedarf besteht? Sicherlich ja.

Die Schwierigkeit beim Katz- und Mausspiel ist zu wissen wer die Katze ist. Übertragen auf die beiden Beispiele: Die Schwierigkeit ist zu erkennen welches Ziel wirklich erreicht werden sollte. Sobald dieser wichtige Punkt erkannt ist, ist der Rest rasch erledigt.

Sicherheit first, Bedenken last. Mein Bedenken first wegen der Sicherheit die last endlich auf der Strecke bleibt: total out. Ich bin wohl genauso rückständig und zurückgeblieben wie die alte analoge Telefonie: Total out. Wer jetzt Parallelen zu den aktuellen Bezahlterminals für eletronic cash sucht: Total out. Aber es mag sich am Horizont ein Licht auftun: Man könnte der analogen und veralteten Telefonie einen modernen, digitalen Anstrich verpassen. Dann wäre man eventuell wieder mehr bereit einfach mal zum Telefonhörer zu greifen und nachzufragen…