Windows Server 2008 Sicherheit – Die technische Referenz - Gattner

44 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle
welcher Satz von Kennwörtern möglicherweise den Hashwert generiert, den er knacken
will, die Hashwerte für alle Optionen berechnen und die Ergebnisse mit dem Hashwert vergleichen.
Das war deutlich langsamer als der Password Appraiser, aber um ein vielfaches
schneller als eine Brute-force-Methode. Zhu Shuanglei implementierte dieselbe Technik im
enorm beliebten Rainbow Crack Tool, das praktisch alle Hashformate knacken kann, die es
gibt. Angriffe mit vorberechneten Hashwerten werden nach diesem Tool oft als Rainbow
Cracks oder Rainbow-Table-Angriffe bezeichnet.
Angriffe mit vorberechneten Hashwerten wurden in der Presse gewaltig breitgetreten, und
viele Leute sowie selbsternannte »Sicherheitsexperten« haben sich darüber ausgelassen, wie
schlimm sie sind und dass sie nur funktionieren, weil Windows so fehlerhaft ist, und dass
Microsoft Windows verbessern muss, um den Erfolg solcher Tools zu verhindern. Üblicherweise
werden solche Sprüche mit der Aussage garniert, dass Entwickler anderer Betriebssysteme
(natürlich) so vorausschauend waren, einen Schutz vor diesen Angriffen zu implementieren.
Diese Einschätzungen sind grobe Vereinfachungen, die durch keinerlei Erfahrungen
oder Ereignisse gestützt werden.
Erstens ist Windows nicht fehlerhaft, weil es keine Angriffe mit vorberechneten Hashwerten
in seinem Entwurf berücksichtigt. Es stimmt, dass die Verwendung eines Saltwerts in der
Berechung des Kennworthashwerts gegen Angriffe mit vorberechneten Hashwerten helfen
kann. Aber dies war keine (und ist nach wie vor keine) signifikante Bedrohung, gegen die
man sich schützen müsste. Ich habe es bereits vorher erwähnt: Falls ein Angreifer Zugriff
auf Ihre Hashwerte hat, ist Ihr Computer oder das Netzwerk bereits verhängnisvoll kompromittiert.
Sie wurden in diesem Fall bereits gehackt, und der Schaden ist bereits so groß, dass
ein Angreifer kaum noch mehr Schaden anrichten kann, auch wenn er diese Kennworthashwerte
knackt.
Lassen Sie sich außerdem nicht einreden, dass die Entwickler von Konkurrenzbetriebssystemen
die Voraussicht besaßen, einen Schutz vor solchen Angriffen zu verwirklichen. Saltwerte
wurden als Schutz hinzugefügt, weil die Kennwortdatei von allen gelesen werden
konnte. Angriffe mit vorberechneten Hashwerten waren irrelevant, als diese Plattformen
entworfen wurden. Hunderte von Gigabyte oder sogar Terabyte an Kennworthashwerten
bereitzuhalten, war einfach nicht praktikabel, als Computer 16 KByte Arbeitsspeicher und
ein Bandlaufwerk hatten.
Zweitens ist es absolut sinnlos, Windows-Kennworthashwerte mit Saltwerten zu versehen,
um Angriffe mit vorberechneten Hashwerten abzuwehren. Sehen Sie sich doch an, wie die
Authentifizierungsprotokolle arbeiten. Falls Sie die Hashmechanismen ändern, müssen Sie
auch ein neues Authentifizierungsprotokoll einführen, weil die alten Protokolle die alten
Hashwerte voraussetzen. Das letzte Mal wurde ein Authentifizierungsprotokoll tatsächlich
aufgegeben, als in Windows Vista LM entfernt wurde. Das dauerte 13 Jahre ab der Einführung
des Nachfolgers. Wenn der Hashmechanismus so geändert wird, dass ein Saltwert hinzugefügt
wird, kann das Angriffe mit vorberechneten Hashwerten zweifellos verhindern. Es
würde aber wieder einen Zeitraum wie etwa 13 Jahre erfordern, bis die alten NT-Hashwerte
verschwunden sind. Und weil Kennworthashwerte unabhängig davon, ob sie mit oder ohne
Saltwert berechnet werden, klartextäquivalent sind, würde diese Maßnahmen das eigentliche
Problem ohnehin nicht beseitigen. Jeder, der behauptet, dass in Windows lediglich Kennwörter
mit einem Saltwert versehen werden müssten, hat das Problem entweder nicht bis
zum Ende durchdacht oder versteht es überhaupt nicht.