About Security #226: Schwachstellen-Suche: Authentifizierung

Inhalte überspringen »

Topthema

Donnerstag, 15. Oktober 2009 | Topthema

About Security #226: Schwachstellen-Suche: Authentifizierung - "Halbe Passwörter"

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/051879)

Schwachstellen im Bereich der Authentifizierung müssen nicht automatisch sofort dazu führen, dass ein Angreifer sich ohne Zugangsdaten zu kennen, anmelden kann. Viele Schwachstellen erleichtern "nur" andere Angriffe, sollten aber trotzdem nicht auf die leichte Schulter genommen werden. Wie z.B. die unvollständige Prüfung der Zugangsdaten.

Gute Passwörter

Gute Passwörter sind mindestens 8 Zeichen lang, bestehen aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen und sind keine Wörter. So oder so ähnlich beschreiben viele Webanwendungen die Anforderungen an ein Passwort.

Schlechte Passwörter

Die Veröffentlichung der Anforderungen an ein gutes Passwort ist nur die halbe Miete: Sie müssen auch umgesetzt, d.h. geprüft, werden. Und daran scheitern viele Webanwendungen. Was noch nicht besonders schlimm ist, wenn die Benutzer sich selbst daran halten. Manche Webanwendungen gehen aber weiter und schwächen die Passwörter, z.B. indem sie nur die ersten n Zeichen des Passworts prüfen oder die Eingabe Case-insensitiv prüfen, d.h. für die Prüfung alle Zeichen in Groß- oder Kleinbuchstaben umwandeln. Manche Anwendungen löschen auch die Sonderzeichen, z.B. um Probleme durch evtl. unterschiedliche Kodierungen zu vermeiden. Alle diese Maßnahmen schwächen die Passwörter, da sie die Menge möglicher Passwörter teilweise drastisch reduzieren. Wenn statt 10 Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen nach der Umwandlung nur 8 Buchstaben geprüft werden, schränkt das den bei einem Brute-Force-Angriff zu prüfenden Bereich stark ein, die Wahrscheinlichkeit, ein gültiges Passwort zu ermitteln, steig also stark an. Vor allem, wenn Benutzer ihr Passwort aus einem normalen Wort gebildet haben, in das sie Zahlen und Sonderzeichen eingefügt haben. Vielleicht hat der Benutzer sein Passwort aus den Wörtern 'sicheres' und 'Paßwort' und seinem Geburtsdatum gebildet:

si1ch0er1es1Pa1ß9wo7rt7

ist ein auf den ersten Blick ganz gutes Passwort, es enthält Groß- und Kleinbuchstaben, mit dem ß ein Sonderzeichen und Ziffern. Wenn die Webanwendung nun aber die Zahlen und das Sonderzeichen streicht, bleibt nur

sicheresPawort

Wenn davon dann nur die ersten 8 Zeichen geprüft werden, ergibt das

sicheres

Das ist zwar nicht unbedingt ein typisches Passwort, aber doch ein Wort aus einem Wörterbuch. Ist es nun auch noch egal, ob es gross, klein oder gemischt geschrieben wird, wird es bei einem Brute-Force-Angriff eher früher als später gefunden.

Passwortprüfung testen

Beim Test der eigenen Anwendung weiß man, dass das Passwort vollständig geprüft wird und die Passwort-Richtlinien durch Prüfungen beim Setzen des Passworts durchgesetzt werden. Andernfalls sollte man das schnellstens entsprechend ändern. Aber wie geht man bei einem Black-Box-Test vor?

Für den Test muss der Tester einen Account kontrollieren. Ohne die Möglichkeit, sich anzumelden, ist kein Test möglich. Zuerst wird ausprobiert, ob das Passwort in voller Länge geprüft wird. Dazu wird beim Login das letzte Zeichen weggelassen. Ist trotz des jetzt eigentlich falschen Passworts die Anmeldung erfolgreich, kann durch schrittweises Weglassen weiterer Zeichen ermittelt werden, wie viele Zeichen des Passworts geprüft werden.

Um zu testen, ob das Passwort Case-sensitiv oder -insensitiv geprüft wird, wird als nächster Test ein Zeichen des Passworts groß statt klein oder klein statt groß eingegeben. Ist die Anmeldung möglich, ist die Passwortprüfung Case-insensitiv.

Als weiterer Test werden vorhandene Sonderzeichen weg gelassen. Ist mit dem so geänderten Passwort eine Anmeldung möglich, werden sie bei der Passwortprüfung nicht berücksichtigt.

Durch die Kombination verschiedener Tests werden die Regeln für die Passwortprüfung möglichst weit eingegrenzt. Ein Angreifer kann die gewonnenen Informationen dann nutzen, um beim Brute-Force-Angriff auf überflüssige Versuche zu verzichten.

Nicht eindeutige Benutzernamen

Eine weitere mögliche Schwachstelle sind nicht eindeutige Benutzernamen. Kann der Benutzer den Benutzernamen bei der Registrierung selbst wählen, muss die Anwendung darauf achten, dass ein vorhandener Benutzername nicht erneut verwendet wird. Ansonsten kann es zu unerwarteten Verhalten der Webanwendung sowie evtl. einer Angriffsmöglichkeit kommen.

Dazu ein Beispiel: Der Default-Benutzername für den Administrator der Anwendung sei admin. Benutzernamen sind Case-insensitiv und werden beim Login auch so behandelt, die Prüfung auf bereits vergebene Benutzernamen erfolgt aber durch einen Fehler Case-sensitiv. Was passiert, wenn ein Benutzer sich mit den Benutzernamen Admin registriert? Je nachdem, wie die Passwortprüfung implementiert ist, kann das beim Login zu unterschiedlichen Reaktionen führen: Admin kann sich mit seinem Passwort als admin anmelden, der Administrator admin landet im Benutzerkontext des normalen Benutzers Admin, keinem von beiden ist eine Anmeldung möglich, oder es passiert etwas ganz anderes.

In der nächsten Folge wird dieses Problem und seine möglichen Folgen weiter beschrieben.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers