Linux Essentials//Die Einsteiger-Zertifizierung des LPI - Linup Front ...

13.2 Benutzer- und Gruppendaten 189
B
B
A
unangenehme Eigenschaft, nur die ersten acht Zeichen jedes Kennworts zu
bearbeiten, und der clevere Cracker kann inzwischen genug Plattenplatz
kaufen, um jedenfalls die gängigsten 50 Millionen (oder so) Kennwörter
»auf Vorrat« zu verschlüsseln. Zum »Knacken« muss er so nur noch in seinem
Vorrat nach der verschlüsselten Form suchen, was sehr schnell geht,
und kann dann einfach den Klartext ablesen.
Um das Ganze noch etwas aufwendiger zu machen, wird beim Verschlüsseln
eines neu eingegebenen Kennworts traditionell noch ein zufälliges Element
addiert (das sogenannte salt), das dafür sorgt, dass eine von 4096 Möglichkeiten
für das verschlüsselte Kennwort gewählt wird. Der Hauptzweck
des salt besteht darin, »Zufallstreffer« zu vermeiden, die sich ergeben, wenn
Benutzer X aus irgendwelchen Gründen einen Blick auf den Inhalt von /etc/
shadow wirft und feststellt, dass sein verschlüsseltes Kennwort genauso aussieht
wie das von Benutzer Y (so dass er sich mit seinem Klartextkennwort
auch als Benutzer Y anmelden kann). Als angenehmer Nebeneffekt wird
der Plattenplatz für das Cracker-Wörterbuch aus dem vorigen Absatz um
den Faktor 4096 in die Höhe getrieben.
Die gängige Methode zur Kennwortverschlüsselung basiert heute auf dem
MD5-Algorithmus, erlaubt beliebig lange Kennwörter und verwendet ein
48-Bit-salt statt den traditionellen 12 Bit. Netterweise ist das Verfahren auch
wesentlich langsamer zu berechnen als »crypt«, was für den üblichen Zweck
– die Prüfung beim Anmelden – ohne Bedeutung ist (man kann immer noch
ein paar hundert Kennwörter pro Sekunde verschlüsseln), aber die cleveren
Cracker schon behindert. (Sie sollten sich übrigens nicht davon irre machen
lassen, dass Kryptografen das MD5-Verfahren als solches heutzutage wegen
seiner Unsicherheit verpönen. Für die Anwendung zur Kennwortverschlüsselung
ist das völlig irrelevant.)
Von den verschiedenen Parametern zur Kennwortverwaltung sollten Sie
sich nicht zuviel versprechen. Sie werden zwar von der Login-Prozedur auf
der Textkonsole befolgt, aber ob sie an anderen Stellen im System (etwa
beim grafischen Anmeldebildschirm) genauso beachtet werden, ist systemabhängig.
Ebenso bringt es in der Regel nichts, den Anwendern in kurzen
Abständen neue Kennwörter aufzuzwingen – meist ergibt sich dann
eine Folge der Form susi1, susi2, susi3, … oder sie alternieren zwischen zwei
Kennwörtern. Eine Mindestfrist gar, die verstreichen muss, bevor ein Benutzer
sein Kennwort ändern kann, ist geradezu gefährlich, weil sie einem
Cracker möglicherweise ein »Zeitfenster« für unerlaubte Zugriffe einräumt,
selbst wenn der Benutzer weiß, dass sein Kennwort kompromittiert wurde.
Das Problem, mit dem Sie als Administrator zu kämpfen haben, ist in der Regel
nicht, dass Leute versuchen, die Kennwörter auf Ihrem System mit »roher Gewalt«
zu knacken. Viel erfolgversprechender ist in der Regel sogenanntes social
engineering. Um Ihr Kennwort zu erraten, beginnt der clevere Cracker natürlich
nicht mit a, b, und so weiter, sondern mit den Vornamen Ihres Ehegesponses, Ihrer
Kinder, Ihrem Autokennzeichen, dem Geburtsdatum Ihres Hundes et cetera.
(Wir wollen Ihnen natürlich in keiner Weise unterstellen, dass Sie so ein dummes
Kennwort verwenden. Neinnein, Sie doch ganz bestimmt nicht! Bei Ihrem Chef
sind wir uns da allerdings schon nicht mehr ganz so sicher …) Und dann gibt es
da natürlich noch das altgediente Mittel des Telefonanrufs: »Hallo, hier ist die IT-
Abteilung. Wir müssen unsere Systemsicherheitsmechanismen testen und brauchen
dazu ganz dringend Ihren Benutzernamen und Ihr Kennwort.«
Es gibt diverse Mittel und Wege, Linux-Kennwörter sicherer zu machen. Neben
dem oben genannten verbesserten Verfahren, das die meisten Linux-Systeme
heute standardmäßig anwenden, gehören dazu Ansätze wie (zu) simple Kennwörter
schon bei der Vergabe anzumeckern oder proaktiv Software laufen zu lassen,
die schwache verschlüsselte Kennwörter zu identifizieren versucht, so wie
Copyright © 2012 Linup Front GmbH