Daniel Hundt - Erfahrung Technologien im Backend

Wenn sich das Verständnis für Sicherheit noch nicht entwickelt hat, werden die Daten meist "plain" übertragen oder gespeichert. Man muss sich nicht um Verschlüsselung und Entschlüsselung kümmern und alles ist super einfach. Dummerweise macht man es Angreifern damit aber auch super einfach.

Unverschlüsselte Übertragungen via HTTP (ohne HTTPS/SSL) können z.B. potentiell abgefangen und mitgelesen werden. Schneidet man z.B. den Anmeldevorgang auf einer Seite mit, kann man den Account anschließend übernehmen.

Werden Daten unverschlüsselt in der Datenbank gespeichert (z.B. Passwort) und ein Angreifer verschafft sich darauf Zugriff, kennt er ggf. die Anmeldedaten mehrerer Nutzer auch bei anderen Diensten (selbes Passwort verwendet).

Daher: Nur unwichtige Daten im Klartext übertragen und speichern.

Pseudoverschlüsslung oder Security through obscurity ist schon etwas besser als Klartext. Auf den ersten Blick ist der Inhalt der Nachricht nicht zu erkennen, jedoch kann der Klartext in wenigen Schritten auch durch Außenstehende "entschlüsselt" werden.

SGFsbG8gV2VsdA==

An den beiden Gleichheitszeichen am Ende des Strings erkennt man sehr einfach, dass es sich um einen einfachen Base64-encodierten String handelt. In wenigen Handgriffen lässt sich der Klartext entschlüsseln:

Hallo Welt

Andere Auswüchse dieser Methode sind Eigenentwicklungen. Wieso sollte man auch auf Funktionen zurückgreifen, die über mehrere Jahre von zahlreichen Personen untersucht wurden und als sicher gelten?

Daher: Pseudoverschlüsselung ist keine Lösung! Wenn man das Problem angeht, kann man es gleich richtig machen ;-)

Ein String aus mehreren zufälligen Zeichen kann als gültiger Schlüssel verwendet werden. Die Sicherheit ergibt sich daraus, dass niemand (anderes) diesen Schlüssel kennt.

Eingesetzt wird diese Methode z.B. zur Erstellung einer Session-ID oder für den DOI-Key um einen Account via Email zu aktivieren. Außerdem werden Zufallszahlen gerne als Passwort oder "Salt" für weitere Verschlüsselungsarten verwendet.

Um diese Zufallszahlenfolge zu erraten, wären bei 32 Stellen bei einem Zeichenvorrat von 62 Zeichen (a-zA-Z0-9), 62^32 (eine Zahl mit 57 Nullen!) Kombinationen möglich.

Daher: Zufallszahlenfolge dort einsetzten, wo ein neues "Passwort" erzeugt werden soll.

Eine Hash-Funktion kann man sich als eine Art "Quersumme" vorstellen. Aus einer beliebig-langen Eingabe wird ein Ergebnis mit fester Länge berechnet. Dabei nimmt man Kollissionen bewusst in Kauf: mehrere Eingaben teilen sich das selbe Ergebnis.

Hash-Funktionen werden dort eingesetzt, wo eine Eingabe schnell überprüft werden muss, z.B. ob ein Download korrekt war, der Inhalt nicht verändert wurde oder ein Passwort korrekt ist.

Speichert man nur den Hash, hat ein Angreifer im besten Fall keinen Zugriff auf den zugehörigen Klartext. Da eine Eigenschaft von Hash-Funktionen ihre Schnelligkeit ist, können aber auch Angreifer schnell viele Kombinationen versuchen.

Daher: Hash-Funktionen dort einsetzten, wo der konkrete Klartext gar nicht benötigt wird.

Bei der symmetrischen Verschlüsselung wird zum Ver- und Entschlüsseln das selbe Passwort verwendet. Ohne diesen Schlüssel ist der Klartext praktisch (!) nicht zu entschlüsseln. Im Gegensatz zur Hash-Funktion gibt es keine Kollisionen (zu einem Ergebnis gibt es jeweils nur eine Eingabe).

Daher: Symmetrische Verschlüsselung dort einsetzen, wo größere Nachrichten verschlüsselt werden sollen.

Bei der asymmetrischen Verschlüsselung wird ein Schlüsselpaar aus public (öffentlichem) und private (privatem) Schlüssel verwendet. Mit Hilfe des privaten Schlüssels kann eine Signatur erstellt werden, die durch den öffentlichen Schlüssel überprüft werden kann. Mit Hilfe des öffentlichen Schlüssels kann eine Nachricht verschlüsselt werden, die nur mit dem privaten Schlüssel entschlüsselt werden kann.

Ein Schlüsselpaar zu erzeugen und einen Nachricht damit zu verschlüsseln ist relativ aufwendig, wesshalb entsprechende Schlüsselpaar relative selten berechnet und für größere Datenmengen auf die symmetrische Verschlüsselung zurückgegriffen wird.

Da keine Geheimnisse über eine potenziell unsichere Leitung ausgetauscht werden müssen, eignet sich diese Methode zur Übertragung eines Ein-Weg-Passworts zur Nutzung mit der symmetrische Verschlüsselung.

Daher: Asymmetrische Verschlüsselung zum Signieren von Inhalten und zum Passwortaustausch auf unsicheren Kanälen verwenden.

Im Internet steht für die verschlüsselte Übertragung und zur Verifizierung der Identität SSL bzw. HTTPS zur Verfügung. Bereits ein selbst erstelltes Zertifikat erlaubt die verschlüsselte Übertragung!

Bei der Übertragung kommen asymmetrische und symmetrische Verschlüsselung zum Einsatz. Aber Achtung: GET-Parameter (die URL oben im Browser) werden unverschlüsselt übertragen!

Daher: HTTPS nach Möglichkeit durchgehend nutzen.

In eigener Sache:
Mein Hoster erlaubt in meinem Paket HTTPS bisher nur über einen SSL-Proxy, den sich alle Kunden teilen. Da es sich um eine eigene Domain handelt, können sich daraus ggf. ungewünschte Seiteneffekte (z.B. Cookie-Klau!) ergeben.