Freitag, 22. Oktober 2010


Topthema

Donnerstag, 26. November 2009 | Topthema

About Security #232: Schwachstellen-Suche: Sichere Authentifizierung

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

Nachdem es nun einige Folgen lang um die Suche nach Schwachstellen in der Authentifizierung ging, geht es ab dieser Folge um deren Behebung bzw. die Entwicklung sicherer Authentifizierungssysteme.

Viele Wünsche auf einmal

Ein sicheres Authentifizierungssystem muss viele Wünsche bzw. Anforderungen auf einmal erfüllen, denn es muss sowohl sicher als auch einfach zu bedienen sein: Das System soll den Benutzern keine störenden Hürden in den Weg legen und gleichzeitig mögliche Angreifer aussperren, außerdem soll es möglichst wenig Support erfordern, effizient und kostengünstig arbeiten, ... - manche der Anforderungen widersprechen sich, und es ist teilweise schwierig, die richtige Balance zwischen Sicherheit und Bedienbarkeit etc. zu finden. Im folgenden werden Möglichkeiten zur Verhinderung der vorgestellten Schwachstellen bzw. Angriffe aufgeführt.

1. Verwendung sicherer Zugangsdaten

Benutzernamen müssen eindeutig sein.

Für die verwendeten Passwörter müssen Mindestanforderungen festgelegt und erzwungen werden (vgl. About Security #214 und #215). Das betrifft z.B.

  • die Mindestlänge,
  • die Verwendung von Buchstaben, Ziffern und Sonderzeichen,
  • die Verwendung von gro� und klein geschriebenen Zeichen,
  • das Vermeiden von Wörtern aus Wörterbüchern, dem Benutzernamen und anderen üblichen Passwörtern.

Außerdem dürfen neue Passwörter nicht mit den vorherigen identisch oder ihnen ähnlich sein.

Vom System vergebene Benutzernamen und/oder Passwörter dürfen nicht vorhersagbar sein, müssen also eine Zufallskomponente enthalten (vgl. About Security #228).

Dem Benutzern sollte die Verwendung besonders sicherer, d.h. besonders langer und/oder aus einem großen Zeichenvorrat gebildeter Passwörter möglich sein, unabhängig davon, ob die Passwortregeln es verlangen oder nicht. Außerdem muss dann auch das gesamte Passwort geprüft werden und nicht nur z.B. die ersten 5 Zeichen (vgl. About Security #226).

2. Sichere Verwendung der Zugangsdaten

Die Zugangsdaten müssen so erzeugt, gespeichert und übertragen werden, dass unauthorisierte Zugriffe darauf unmöglich sind.

Die Kommunikation zwischen Client und Server sollte kryptographisch gesichert erfolgen. Dabei sollte auf bekannte, sichere Systeme wie z.B. SSL/TLS zurückgegriffen und die Verwendung von Eigenentwicklungen vermieden werden (vgl. About Security #217 und #219).

Wird für die ohne Authentifizierung zugänglichen Bereiche der Webanwendung HTTP verwendet, sollte bereits das Anmeldeformular über HTTPS geladen werden, statt erst beim Abschicken der Zugangsdaten darauf zu wechseln (vgl. About Security #218).

Die Zugangsdaten sollten nur als POST-Request übertragen werden, nie als Cookie oder GET-/URL-Parameter. Besonders letztere sind gefährlich, da sie in Logfiles und Bookmarks gespeichert und dort ausgespäht werden können. Außerdem sollten die Zugangsdaten niemals vom Server zurück an den Client gesendet werden (vgl. About Security #217).

About Security: Die komplette Serie

Auf dem Server sollten die geheimen Teile der Zugangsdaten, d.h. insbesondere die Passwörter, so gespeichert werden, dass ihre Ursprungswerte nicht ermittelt werden können. Ein Angreifer, der z.B. über eine SQL-Injection-Schwachstelle Zugriff auf den Server erlangt, könnte sie sonst ausspähen und verwenden. Am besten werden nur die Hash-Werte der Daten gespeichert, ein Salt verhindert die Verwendung vorberechneter Wertetabellen (vgl. About Security #220).

Eine "Remember me"-Funktion sollte nur nicht geheime Daten wie den Benutzernamen speichern, nicht das zugehörige Passwort (vgl. About Security #224). In nicht sicherheitskritischen Bereichen könnte dem Benutzer die Möglichkeit geboten werden, auch das Passwort zu speichern, das dann aber nicht als Klartext, sondern mit einem nur dem Server bekannten Schlüssel verschlüsselt gespeichert werden muss. Außerdem sollte der Benutzer auf die Gefahr eines möglichen Angriffs hingewiesen werden: Jeder mit Zugriff auf den betroffenen Rechner, egal ob lokal oder remote, kann sich dann mit den gespeicherten Daten bei der Webanwendung anmelden.

Es muss eine Möglichkeit zur Änderung des Passworts geben, so dass die Benutzer kompromittierte Passwörter selbst ersetzen können (vgl. About Security #221). Ob das Passwort regelmäßig gewechselt werden sollte, ist mehr oder weniger Geschmacksache: Keiner der üblichen Angriffe wie Phishing, Brute-Force-Angriffe, Brechen des ausgespähten Passwort-Hashes oder Keylogger lässt sich damit verhindern, lediglich die Nutzungsdauer des ausgespähten Passworts wird verkürzt. Was sich aber durch einen erneuten Angriff korrigieren lässt.

Werden vom Server erzeugte Zugangsdaten 'out of band' an den neuen Benutzer übertragen, muss das so sicher wie möglich erfolgen. Die Zugangsdaten dürfen nur kurze Zeit gültig sein, der Benutzer muss nach der ersten Anmeldung zur Änderung des Passworts gezwungen werden, und er sollte dazu angehalten werden, die übertragenen Zugangsdaten zu löschen bzw. zu vernichten (vgl. About Security #229).

In der nächsten Folge wird die Entwicklung sicherer Authentifizierungssysteme fortgeführt.

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

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren