Rainbow Tables, gut, versuchen wir es mal (ist lang her, dass ich die prinzipielle Funktionsweise von Hashtables im Studium lernen musste, also bitte nicht für Detailfehler hauen):
Das
MD5 - Verschlüsselungsverfahren basiert auf dem
Hashing. Dies wird anhand von Hashfunktionen (genauer: einer ganz bestimmten Hashfunktion) durchgeführt. Die Aufgabe der Funktion ist es nun einen möglichst eindeutige, aber wesentlich kürzere Identifikationsmöglichkeit zu schaffen (im Passwortfall ist das meist länger, aber das hat auch einen gewissen Sinn
). Das Problem ist nun, dass Hashfunktionen a: nach einem Schema arbeiten und b: es nur einen endlichen Zeichenvorrat und vor allem eine Begrenzung der Länge des Hashwertes gibt.
Der MD5 Algorithmus nutzt 128bit die als 32-stellige Hexadezimalzahl abgebildet werden. So, wenn man sich jetzt vorstellt, dass alle sinnvollen und sinnfreien (bei Passwörtern ja zu empfehlen) Kombinationen unterschiedlicher Länge auf einen begrenzten, limitierten Vorrat an Zeichen abgebildet werden sollen, ist schnell klar, dass es Doppelbelegungen nicht nur geben kann, sondern auch wird. Tritt dies ein, liegt eine Kollision vor. Da der Beitrag ohnehin schon recht langweilig ist, spar ich mir die Erklärung, wie man diese Kollisionen vermeiden kann, weil der Passwortsucher ja kein Interesse hat sie zu vermeiden und es im Regelfall auch nicht sonderlich notwendig wäre. Schließlich wird das Passwort ja nicht rückwirkend ermittelt, sondern nur eines gesucht, welches ebenfalls verwendet werden kann (md5 ist - in sinnvoller Zeit (Passwortwechsel einmal im halben Jahr empfohlen) - nach wie vor irreversibel). Wie gesagt, für den Suchenden ist das aber irrelevant.
Da die erwähnten Kollisionen aber bei gleichem Inhalt immer wieder auftreten werden, kann also als gesichert gelten, dass ein Wort, welches den gleichen Hashwert hat, wie das Passwort, auch als Passwort akzeptiert wird. Rainbow-Tables zu erstellen benötigt in etwa die gleiche Zeit, wie das Brüten, allerdings, das muss man nur einmal machen und man wird ganz sicher nicht von einem Server ausgesperrt. ABER: Um diese Tabellen verwenden zu können benötigt man den MD5 Schlüssel, der zwar von zahlreichen Foren, Spielen und auch privaten Anwendern genutzt wird, aber eben in der Datenbank liegt. Einige Anbieter sind nun dazu übergegangen ein
SALT dem Passwort des Anwenders hinzuzufügen. Zu deutsch heißt das schlicht Salz und genau das ist auch die Funktion dieser Zeichenkette, die zwar eineindeutig sein muss, aber vom Rechner einmalig zufällig generiert werden kann. Das Salt ändert an sich nichts daran, dass es immer noch ein MD5 Code ist, nur, dass das gefundene Ergebnis aus den Rainbow-Tables eben nicht mehr stimmt. Listigerweise kann dieses Salt durch den Betreiber eingeführt werden, ohne das der Benutzer davon großartig etwas merkt. Allerdings, es hilft das beste Salz nichts, wenn der Koch, der es verwendet dich Küchentür für jeden Fremden öffnet.
Eine andere Variante ist die DoppelMD5 Verschlüsselungen. Dabei wird genau das gemacht, was die meisten wohl schon ahnen, der erste Schlüssel wird ein zweites Mal MD5 codiert (richtig clever ist natürlich noch eine Manipulation am Schlüssel, nach Muster teilen und erneut zusammenfügen ist sehr beliebt). Eine Alternative, nur noch nicht so häufig verwendet, ist der
SHA256 (384 oder auch 512), es gibt aber noch weitere.
Leider bleibt ein Fakt bestehen, solange es Daten gibt, die eines gewissen Schutzes bedürfen, solange wird es Menschen geben, die diesen Schutz umgehen wollen und andere, die diesen Schutz verstärken müssen. In nur zwei Jahren dürfte das monatliche Passwortwechseln angesagt sein, wenn bis dahin kein besserer Verschlüsslungsalgorithmus erfunden wurde bzw. der Berechnungsraum erweitert wird (woran natürlich gearbeitet wird). Denn es ist nun einmal, wie es ist, das
Moore'sche Gesetz gilt, welches davon ausgeht, dass sich alle 2 Jahre die Komplexität, somit auch die Geschwindigkeit und Arbeitsweise von integrierten Schaltkreisen verdoppelt.
Mit diesem Wissen sollte die Erkenntnis einhergehen, dass Betreiber und Nutzer im gleichen Maße für die Sicherheit ihrer Daten verantwortlich sind. Ein Dienstanbieter sollte also immer das allgemeine Maß an Schutz bieten (selbst also je Zugang und evtl. verwendeten Server ein anderes, sicheres Passwort besitzen - im Falle Freewar / Darkfleet heißt das: MySQL-Zugang und Serverlogin sollten sich also unterscheiden und das von Welt zu Welt). Der Nutzer dagegen übernimmt die Verantwortung für seinen Teil der Daten, eben durch Wahl eines sicheren Passworts, welches nur an zwei Speicherorte gehört: In die Datenbank des Servers, für welches es Gültigkeit besitzt (d.h. jeder Zugang hat ein eigenes Passwort) und in den eigenen Kopf, keine Zettel (nicht einmal in einem Safe), keine Textdateien, keine SMS an sich selbst. Und sicher bedeutet in diesem Zusammenhang eben noch immer: bestehend aus 8+ Zeichen, Zahlen, Groß- und Kleinbuchstaben falls erlaubt Sonderzeichen.
So, muss reichen...
ps.: für alle Informatiker: ich habe versucht es allgemein verständlich zu machen, oder meint ihr wirklich, es wäre nützlich von Adressraum zu reden oder den wahnwitzigen Versuch zu unternehmen detaillierten Verteilungsfunktion zu notieren?
