Wie gefährlich sind veraltete Hashalgorithmen?

Hashing Algorithmen oder Hashalgorithmen sind so designed, dass sie eigentlich Einweg Verschlüsselungen ohne Schlüssel sind. Normalerweise benötigen Verschlüsselungsalgorithmen wie AES oder RSA immer einen Schlüssel einer festgelegten Länge (irgendeine 2-er Potenz). Hashalgorithmen hingegen, nehmen einen beliebigen Text oder beliebige Daten an und erzeugen einen zufälligen Zahlen-Buchstaben-Salat, der immer gleich lang ist.

Anhand eines Beispieles lässt sich vieles besser erklären. Betrachten wir den MD5 Algorithmus. Er ist seit 1991 in Verwendung und erzeugt einen 128 Bit langen Hashwert, gleichgültig, wie lange die Eingabe ist.

Eingabestring: Thisisatest Ausgabe (MD5 Hash): 0480aa34aa3db358b37cde2ab6b65326

Eingabestring: https://tools.ietf.org/rfc/rfc1918.txt (Text des RFC 1918, der die privaten IPv4 LAN Adressen definiert) Ausgabe (MD5 Hash): f4e30cb52586d7838bed6f2b17c508cb

Letztlich steckt hinter einem Hashalgorithmus die sogenannte kryptographische Hashfunktion. Diese definiert sich durch zwei Funktionen:

Welche Gefahren gibt es?

Eine der größten Gefahren ist die Kollisionsresistenz. Diese wird niemals auf 100% steigen können, da die Anzahl der möglichen Hashes begrenzt ist. Je kürzer der resultierende Hash, umso wahrscheinlicher ist eine Kollision, denn die Anzahl der möglichen Eingabedaten ist unbegrenzt (MD5 ist mit 128 Bit gegenüber SHA256 mit 256 Bit wesentlich anfälliger für Kollisionen)

Nehmen wir den hypothetischen Hashingalgorithmus HASH1 an und gehen davon aus, dass er nur 128 Bit lange Hashes erzeugt. Je nach Qualität der darin enthaltenen Funktionen könnten Kollisionen erscheinen. Beispielsweise würden diese so aussehen:

Eingabe: DieserTextErzeugtEineKollision1234567890!Ӥ$%&/()=? Ausgabe: 1651e457d93d8d24cd0bfc23b8622581

Eingabe: AuchDieserTextErzeugtEineKollision?! Ausgabe: 1651e457d93d8d24cd0bfc23b8622581

In der Praxis sind solche Kollisionen, aber eher unwahrscheinlich. Auf preshin.com findet man eine schöne Tabelle:

Das heißt im Endeffekt: Bei der Verwendung eines 160 Bit Hashes, steigt die Wahrscheinlichkeit, dass wir eine Kollision finden mit der Anzahl der erzeugten Hashes. Erst bei 1,42 * 10 hoch 24 Hashes, ist jeder 2. Hash eine Kollision. Wieso ist das so? Wir näheren uns langsam dem Ende aller Möglichkeiten bei 160 Bit.

Interessant ist jedoch die Wahrscheinlichkeit bei kleineren Zahlen. Bei 1,71 * 10 hoch 15 erzeugten Hashes ist die Wahrscheinlichkeit für eine Kollision 1 zu 10 hoch 18. Also äußerst unwahrscheinlich, bei so einer großen Anzahl an Hashes.

Welche Gefahren lauern in der Praxis?

In der Praxis sind Kollisionen tatsächlich ein Problem, denn Hashes kommen überall da zum Einsatz, an denen bestimmte Dinge durch eine Partei geheim gehalten werden sollen. Ein beliebter Einsatz sind Loginportale mit Passwörtern. Hier werden entgegengenommene Passwörter durch das Portal als Hash in der Datenbank des Dienstleisters gespeichert. Dadurch weiß der Dienstleister nicht, welches Passwort der Benutzer verwendet, sobald er aber das Passwort beim Loginportal eingibt und dieses erneut gehasht wird, kann der Dienstleister beide Werte vergleichen und stellt fest: „Das war wohl das Passwort”, und lässt den User somit in sein System.

Bei Passwörtern ist eine Kollision durchaus problematisch, denn wählen beispielsweise zwei Benutzer, zwei unterschiedliche Kennwörter, die denselben Hash als Ausgabe haben, so können sich beide User im jeweils anderen Konto anmelden.

Telefonnummern

Telefonnummern sind standardisiert. Vor allem durch Definitionen wie E.164 ( https://en.wikipedia.org/wiki/E.164) wird die Anzahl der Möglichkeiten bei der Eingabe stark begrenzt im Vergleich zur unbeschränkten Eingabe.

Das heißt unsere Vorlage ist: +XXX XXXXXXXXXXXX

Wobei jedes X für eine Zahl zwischen 0 und 9 steht.

Die große Frage, bevor man das Risiko der Kollisionen einschätzen kann ist, was ist der Scope des Hashes? Nehmen wir an es geht dabei um die Anonymisierung der Telefonnummern bei einem Dienstleister. Laut DSGVO sind Telefonnummern, nämlich personenbezogene Daten. Achtung, wir rutschen jetzt ein wenig in das Risk Assessment ab, aber das rundet die Sache schließlich ab.

Eine Kollision würde bei unterschiedlichen Telefonnummern, zwei gleiche Hashwerte generieren. Dadurch würden die Statistiken des Dienstleisters verfälscht und alles was passieren kann ist, dass 2 eigentlich unterschiedliche Anrufer, als einer identifiziert werden.

Das ist gelinde gesagt sehr harmlos und kein Vergleich zum vorherigen Passwortszenario, bei dem ein Identitätsdiebstahl möglich ist. Ein Identitätsdiebstahl im Telefonszenario ist nicht möglich, denn eine Zurückberechnung des Hashes ist nicht möglich, um etwa dadurch die Telefonnummer wieder zu erhalten.

Fazit

Aus Compliancegründen ist natürlich die Auswahl von Hashfunktionen gänzlich anders zu betrachten, als über Logik & Fakten. Doch sollten Compliancevorgaben eben genau diese Logiken & Fakten genau überprüfen, bevor eine Entscheidung in diese Richtung überhaupt getroffen werden kann.

Ich persönlich sehe beispielsweise Algorithmen wie MD5 nicht immer kritisch. Im Szenario der Passwortverwaltung eines Dienstes sind Threats durchaus möglich und die Folge (Identitätsdiebstahl) ist sehr gefährlich für die Benutzer. Von daher ist es ratsam lieber SHA256 zu verwenden, oder sogar noch neuere und sichere Verfahren.

Letztlich kommt es auf den Scope an, in welchem man Hashfunktionen einsetzt, denn Kollisionen haben nicht immer per se ein schwerwiegendes Problem als Folge. Siehe dazu das Szenario mit den Telefonnummern.

Aber!

Trotz aller Risikobetrachterei wäre es allerdings fahrlässig einen veralteten Algorithmus zu nehmen, sobald eine Neuentwicklung stattfindet. Software, die momentan entsteht, sollte trotzdem mindestens mit SHA256 arbeiten. Wir wissen nie, welche weiteren Probleme noch hinter älteren Hashfunktionen stecken. Wobei dies auch für die neueren gilt. Irgendjemand findet Lücken, sei es bei Hashverfahren, oder Verschlüsselungen wie AES oder RSA.

Beitragsbild Locky Ransomware Sourcecode (verändert) von Christiaan Colen Creative Commons CC-BY SA 2.0

Andre Fritsche — IT Sicherheit

Ein Blog und eine Meinung zu vielen Themen der IT Sicherheit

Andre Fritsche

Written by

Software Developer & Security Specialist

Andre Fritsche — IT Sicherheit

Ein Blog und eine Meinung zu vielen Themen der IT Sicherheit