Kritische Terminologieentwickler müssen sie kennen

In einer zunehmend datengetriebenen Welt ist der sichere Umgang mit Nutzerdaten von entscheidender Bedeutung.

Die Aufgaben von Entwicklern sind anspruchsvoll genug: Wir jonglieren mit komplexen Systemen voller möglicher Fehlerquellen und setzen gleichzeitig die oft flüchtigen Wünsche der Nutzer in Benutzeroberflächen und Backends um. Hinzu kommt nun eine neue, essenzielle Komponente: Datensicherheit. Dies ist aus gutem Grund wichtig, denn als Kunden sind wir verärgert, wenn unsere Daten missbraucht werden (daher ist es nur fair, unseren Nutzern ein sicheres und angenehmes Erlebnis zu bieten). Zudem fordern Regierungen und Unternehmen dies, um Vorschriften einzuhalten.

Datensicherheit als Verantwortungsdiffusion

Erschwerend kommt hinzu, dass Sicherheit vielschichtig ist und leicht zu einem Fall von „alle sind verantwortlich, also ist niemand wirklich zuständig“ werden kann. In modernen Cloud-Teams haben mehrere Gruppen direkten Einfluss auf den Datenfluss: Entwickler, Datenbankadministratoren, Systemadministratoren (DevOps-Experten), privilegierte Backoffice-Benutzer und andere. Diese Rollen/Teams neigen dazu, die Augen zu verschließen und Datensicherheit als Problem der anderen zu betrachten. Die Realität sieht jedoch anders aus: Jeder muss sich um seine eigene „Welt“ kümmern, da ein Datenbankadministrator die Anwendungsseitige Sicherheit nicht kontrollieren kann, ein DevOps-Spezialist nichts gegen den Backoffice-Zugriff tun kann und so weiter.

Entwickler und Datensicherheit

Trotzdem haben Entwickler die größte Angriffsfläche, wenn es um Daten geht: Sie entwickeln jeden Teil der App, verbinden sich mit diversen Backend-Diensten, schleusen Zugriffstoken hin und her, haben uneingeschränkten Lese-/Schreibzugriff auf Datenbanken und ihre Anwendungen haben umfassende Zugriffsrechte auf alle Systembereiche. So kann beispielsweise eine Django-App in der Produktionsumgebung die gesamte S3-Sammlung der letzten zehn Jahre löschen. Daher ist die größte Wahrscheinlichkeit für Sicherheitslücken auf der Ebene des Quellcodes gegeben und fällt direkt in die Verantwortung der Entwickler.

Datensicherheit ist ein weites Feld und es ist unmöglich, dieses Thema in einem einzigen Beitrag umfassend zu behandeln. Ich möchte jedoch die grundlegenden Begriffe erläutern, die Entwickler kennen müssen, um ihre Anwendungen sicher zu gestalten. Betrachten Sie dies als „App Data Security 101“.

Legen wir los!

Hashing

Eine sehr präzise Definition finden Sie bei Wikipedia, aber einfach ausgedrückt ist Hashing der Prozess, Daten in eine andere, nicht lesbare Form zu konvertieren. Nehmen wir beispielsweise das bekannte (und unsichere) Verfahren der Base64-Codierung: Der Satz „Ist mein Geheimnis bei dir sicher?“ kann in „SXMgbXkgc2VjcmV0IHNhZmUgd2l0aCB5b3U/“ umgewandelt werden („gehasht“). Wenn Sie also beispielsweise anfangen, Ihr persönliches Tagebuch im Base64-Format zu schreiben, kann Ihre Familie Ihre Geheimnisse nicht lesen (es sei denn, sie wissen, wie man Base64 entschlüsselt)!

Dieses Prinzip der Datenverschlüsselung wird bei der Speicherung von Passwörtern, Kreditkartennummern usw. in Webanwendungen (eigentlich sollte es in allen Arten von Apps verwendet werden) angewendet. Die Idee dahinter ist, dass ein Angreifer im Falle einer Datenpanne nicht in der Lage sein sollte, Passwörter und Kreditkartennummern zu nutzen, um Schaden anzurichten. Für dieses Hashing werden hochrobuste und ausgefeilte Algorithmen eingesetzt. Base64 ist dabei ein Witz und wird von jedem Angreifer sofort geknackt.

Passwort-Hashing verwendet eine kryptografische Technik, die als Einweg-Hashing bekannt ist, was bedeutet, dass Daten zwar verschlüsselt, aber nicht entschlüsselt werden können. Woher weiß die App dann, dass es Ihr Passwort ist, wenn Sie sich anmelden? Sie verwendet denselben Prozess und vergleicht die verschlüsselte Form dessen, was Sie gerade als Passwort eingegeben haben, mit der verschlüsselten Form, die in der Datenbank gespeichert ist; stimmen diese überein, können Sie sich anmelden!

Wo wir gerade beim Thema Hashes sind, hier ist etwas Interessantes: Wenn Sie jemals Software oder Dateien aus dem Internet heruntergeladen haben, wurden Sie möglicherweise aufgefordert, die Dateien vor der Verwendung zu überprüfen. Wenn Sie beispielsweise das Ubuntu Linux ISO herunterladen, zeigt Ihnen die Downloadseite eine Option zur Überprüfung des Downloads. Wenn Sie darauf klicken, öffnet sich ein Popup:

Das Popup fordert Sie auf, einen Befehl auszuführen, der im Wesentlichen die gesamte heruntergeladene Datei hasht und das Ergebnis mit der Hash-Zeichenfolge vergleicht, die Sie auf der Downloadseite sehen: 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5. Diese Konvertierung wird mit dem SHA256-Algorithmus durchgeführt, dessen Erwähnung Sie im Befehl sehen: shasum -a 256 –check.

Die Idee ist, dass, wenn der durch Ihre Überprüfung erzeugte Hash anders ist, jemand Ihre Datei manipuliert und Ihnen eine kompromittierte Version bereitgestellt hat.

Einige bekannte Namen im Bereich des Passwort-Hashings sind MD5 (unsicher und nicht mehr verwendet), SHA-1 und SHA-2 (Algorithmenfamilien, zu denen SHA-256 und SHA-512 gehören). Weitere sind SCRYPT, BCRYPT usw.

Salting

Sicherheit ist ein ständiges Katz-und-Maus-Spiel: Die Angreifer lernen das aktuelle System kennen und entwickeln neue Angriffsmethoden. Diese werden entdeckt und die Entwickler verbessern ihre Verteidigung. Die Kryptografie ist da keine Ausnahme. Obwohl es unmöglich ist, Hashes wieder in Passwörter umzuwandeln, haben Angreifer im Laufe der Zeit ausgeklügelte Techniken entwickelt, die intelligentes Raten mit schierer Rechenleistung kombinieren. Dadurch können sie das richtige Passwort vorhersagen, wenn sie den Hash haben.

„Herr Rumpelstilzchen, nehme ich an?!“

Als Gegenmaßnahme wurde die Technik des „Saltings“ entwickelt. Das bedeutet, dass die Hash-Berechnung eines Passworts (oder anderer Daten) auf einer Kombination aus zwei Dingen basiert: den Daten selbst und einer zufälligen Zeichenfolge, die der Angreifer nicht erraten kann. Wenn wir also beim Salting das Passwort „superman009“ hashen wollen, wählen wir zuerst eine zufällige Zeichenfolge als „Salt“, z.B. „bCQC6Z2LlbAsqj77“, und führen dann die Hash-Berechnung für „superman009-bCQC6Z2LlbAsqj77“ durch. Der resultierende Hash weicht von den üblichen Strukturen des Algorithmus ab, was die Wahrscheinlichkeit für Reverse Engineering oder Vermutungen erheblich einschränkt.

Hashing und Salting sind komplexe Bereiche, die sich ständig weiterentwickeln. Als Anwendungsentwickler müssen wir uns nicht direkt damit befassen. Dennoch ist es hilfreich, diese Konzepte zu kennen, um bessere Entscheidungen treffen zu können. Wenn Sie beispielsweise ein altes PHP-Framework pflegen und feststellen, dass es MD5-Hashes für Passwörter verwendet, sollten Sie wissen, dass es an der Zeit ist, eine moderne Passwortbibliothek zu integrieren.

Schlüssel

Der Begriff „Schlüssel“ begegnet Ihnen häufig im Zusammenhang mit Verschlüsselung. Bisher haben wir uns mit Passwort-Hashing oder Einweg-Verschlüsselung beschäftigt, bei der wir Daten irreversibel konvertieren und die ursprüngliche Form zerstören. Für die alltägliche Praxis ist das nicht geeignet – ein Dokument, das so sicher geschrieben und per E-Mail versendet wird, dass es niemals gelesen werden kann, ist nutzlos! Wir wollen Daten so verschlüsseln, dass die Information für Sender und Empfänger zugänglich ist, aber während der Übertragung oder Speicherung nicht lesbar sein darf.

Hier kommt das Konzept des „Schlüssels“ ins Spiel. Es ist genau das, was der Name vermuten lässt: der Schlüssel zu einem Schloss. Die Person, der die Informationen gehören, verschlüsselt sie mit einem Geheimnis, das als Schlüssel bezeichnet wird. Solange der Empfänger/Angreifer diesen Schlüssel nicht hat, ist es unmöglich, die Daten zu entschlüsseln, egal wie ausgefeilt die Algorithmen sein mögen.

Schlüsselrotation

Obwohl Schlüssel die Verschlüsselung ermöglichen, bergen sie ähnliche Risiken wie Passwörter: Sobald jemand den Schlüssel kennt, ist es vorbei. Stellen Sie sich vor, jemand hackt einen Dienst wie GitHub (auch nur für ein paar Sekunden) und gelangt an 20 Jahre alten Code. Im Code findet er die kryptografischen Schlüssel, die zur Verschlüsselung der Unternehmensdaten verwendet werden (eine schlechte Praxis, Schlüssel zusammen mit dem Quellcode zu speichern, aber es kommt häufiger vor, als man denkt!). Wenn das Unternehmen die Schlüssel nicht regelmäßig ändert, kann derselbe Schlüssel für Unheil genutzt werden.

Daher hat sich die Praxis der häufigen Schlüsseländerung entwickelt. Dies wird als Schlüsselrotation bezeichnet, und ein seriöser Cloud-PaaS-Anbieter sollte dies als automatisierten Dienst anbieten.

Bildnachweis: AWS

AWS bietet hierfür beispielsweise den AWS Key Management Service (KMS) an. Ein automatisierter Dienst erspart das mühsame Ändern und Verteilen von Schlüsseln auf alle Server und ist heutzutage bei großen Implementierungen unerlässlich.

Public-Key-Kryptografie

Wenn das bisherige Gerede über Verschlüsselung und Schlüssel umständlich klingt, haben Sie Recht. Schlüssel sicher aufzubewahren und so weiterzugeben, dass nur der Empfänger die Daten sieht, führt zu logistischen Problemen, die die heutige sichere Kommunikation unmöglich machen würden. Aber dank der Public-Key-Kryptografie können wir sicher kommunizieren oder online einkaufen.

Diese Art der Kryptografie war ein großer mathematischer Durchbruch, und das ist der Hauptgrund, warum das Internet nicht von Angst und Misstrauen gelähmt ist. Die Details des Algorithmus sind komplex und hochgradig mathematisch. Daher kann ich sie hier nur konzeptionell erläutern.

Bildnachweis: The Electronic Frontier Foundation

Public-Key-Kryptografie basiert auf der Verwendung von zwei Schlüsseln zur Verarbeitung von Informationen. Einer der Schlüssel wird als Private Key bezeichnet und muss privat gehalten und niemals weitergegeben werden. Der andere wird als Public Key bezeichnet (daher der Name der Methode) und soll öffentlich veröffentlicht werden. Wenn ich Ihnen Daten sende, muss ich zuerst Ihren öffentlichen Schlüssel abrufen und die Daten verschlüsseln und an Sie senden. Sie können die Daten dann mit Ihrer Kombination aus privatem und öffentlichem Schlüssel entschlüsseln. Solange Sie Ihren privaten Schlüssel nicht versehentlich preisgeben, kann ich Ihnen verschlüsselte Daten senden, die nur Sie öffnen können.

Das Schöne an dem System ist, dass ich Ihren privaten Schlüssel nicht kennen muss und jeder, der die Nachricht abfängt, nichts tun kann, um sie zu lesen, obwohl er Ihren öffentlichen Schlüssel hat. Wenn Sie sich fragen, wie das möglich ist, lautet die kürzeste und nicht-technische Antwort: Es liegt an der Schwierigkeit, große Primzahlen zu faktorisieren:

Für Computer ist es schwierig, große Primzahlen zu faktorisieren. Wenn der ursprüngliche Schlüssel sehr groß ist, können Sie also sicher sein, dass die Nachricht auch in Tausenden von Jahren nicht entschlüsselt werden kann.

Transport Layer Security (TLS)

Sie wissen jetzt, wie Public-Key-Kryptografie funktioniert. Dieser Mechanismus (den öffentlichen Schlüssel des Empfängers kennen und ihm verschlüsselte Daten senden) ist der Grund für die Popularität von HTTPS und dafür, dass Chrome anzeigt: „Diese Website ist sicher“. Was passiert, ist, dass der Server und der Browser den HTTP-Verkehr (Webseiten sind lange Textfolgen, die Browser interpretieren) mit den öffentlichen Schlüsseln des jeweils anderen verschlüsseln, was zu Secure HTTP (HTTPS) führt.

Bildnachweis: Mozilla. Interessanterweise findet die Verschlüsselung nicht in der Transportschicht selbst statt; das OSI-Modell sagt nichts über die Verschlüsselung von Daten. Es ist nur so, dass Daten von der Anwendung (in diesem Fall dem Browser) verschlüsselt werden, bevor sie an die Transportschicht übergeben werden, die sie dann an ihrem Ziel abliefert, wo sie entschlüsselt werden. Der Prozess umfasst aber die Transportschicht, und am Ende führt alles zu einem sicheren Datentransport, daher der lose Begriff „Sicherheit der Transportschicht“.

Manchmal stoßen Sie auch auf den Begriff Secure Socket Layer (SSL). Es ist dasselbe Konzept wie TLS, nur dass SSL früher entstanden ist und nun von TLS abgelöst wird.

Vollständige Festplattenverschlüsselung

Manchmal sind die Sicherheitsanforderungen so hoch, dass nichts dem Zufall überlassen werden kann. Beispielsweise können Regierungsserver, auf denen die biometrischen Daten eines Landes gespeichert sind, nicht wie normale Anwendungsserver bereitgestellt werden, da das Risiko zu hoch ist. Für diese Anforderungen reicht es nicht aus, dass Daten nur während der Übertragung verschlüsselt werden; sie müssen auch im Ruhezustand verschlüsselt sein. Aus diesem Grund wird die vollständige Festplattenverschlüsselung verwendet, um die gesamte Festplatte zu verschlüsseln und sicherzustellen, dass die Daten auch bei einem physischen Angriff sicher sind.

Es ist wichtig zu beachten, dass die vollständige Festplattenverschlüsselung auf Hardwareebene erfolgen muss. Denn wenn wir die gesamte Festplatte verschlüsseln, wird auch das Betriebssystem verschlüsselt und kann nicht ausgeführt werden, wenn der Rechner gestartet wird. Die Hardware muss also erkennen, dass der Festplatteninhalt verschlüsselt ist, und die Entschlüsselung im laufenden Betrieb durchführen, wenn sie die angeforderten Festplattenblöcke an das Betriebssystem übergibt. Aufgrund dieses zusätzlichen Aufwands führt Full Disk Encryption zu langsameren Lese-/Schreibvorgängen, was Entwickler solcher Systeme berücksichtigen müssen.

Ende-zu-Ende-Verschlüsselung

Angesichts der anhaltenden Datenschutz- und Sicherheitsbedenken großer sozialer Netzwerke ist der Begriff „Ende-zu-Ende-Verschlüsselung“ heutzutage vielen bekannt, auch wenn sie nicht im Bereich der App-Entwicklung tätig sind.

Wie wir gesehen haben, bietet Full Disk Encryption die ultimative Sicherheit, ist aber für den normalen Benutzer unpraktisch. Stellen Sie sich vor, Facebook möchte die auf Ihrem Telefon gespeicherten Daten sichern, kann aber nicht Ihr gesamtes Telefon verschlüsseln und alles andere dabei sperren.

Daher setzen diese Unternehmen auf die Ende-zu-Ende-Verschlüsselung, was bedeutet, dass Daten verschlüsselt werden, wenn sie von der App erstellt, gespeichert oder übertragen werden. Selbst wenn die Daten den Empfänger erreichen, sind sie vollständig verschlüsselt und nur über das Telefon des Empfängers zugänglich.

Bildnachweis: Google

Beachten Sie, dass die End-to-End-Verschlüsselung (E2E) keine mathematischen Garantien wie die Public-Key-Kryptografie bietet. Sie ist lediglich eine Standardverschlüsselung, bei der der Schlüssel vom Unternehmen gespeichert wird, und die Sicherheit Ihrer Nachrichten hängt von der Sicherheitspolicy des Unternehmens ab.

Fazit 👩‍🏫

Die meisten dieser Begriffe dürften Ihnen bereits bekannt sein, vielleicht sogar alle. In diesem Fall möchte ich Sie ermutigen, Ihr Verständnis dieser Konzepte zu überprüfen und zu bewerten, wie ernst Sie sie nehmen. Denken Sie daran, dass die Sicherheit von App-Daten ein fortlaufender Kampf ist, den Sie immer wieder gewinnen müssen, da bereits ein einziger Verstoß ganze Branchen, Karrieren und sogar Leben zerstören kann!