Bei diesem Thema handelt es sich um den Platz 2 der OWASP-Top10 2017, im Original „Broken Authentication„. Die deutsche Übersetzung konkretisiert das Thema auf die 2 Bereiche: Authentifizierung und Session-Management, da das inhaltlich 2 separate Bereiche sind.

Authentifizierung

Bei der Authentifizierung ist das Haupt-Thema der Umgang mit Passwörtern. Sowohl auf Seiten des Benutzers, als auch auf Seite der Webanwendung. Benutzer sind bequem, sie geben sich in der Regel nicht viel Mühe mit Passwörtern, so dass diese zu einfach sind, also nicht komplex genug und zu leicht zu knacken. Alles unter 12 Zeichen Länge kann recht einfach geknackt werden, besonders wenn die Bestandteile des Passworts in einem Wörterbuch vorkommen. Über eine Wörterbuch-Attacke bekommt man solche Passwörter besonders schnell geknackt.Und wenn die Benutzer ihr Passwort dann auch noch auf anderen Seiten wiederverwenden, dann hat man auch noch Zugriff auf diese Konten.

Es kommt regelmäßig vor, dass durch Schwachstellen Webseiten gehackt werden und alle Benutzerdaten gestohlen werden. Immer wieder werden Fälle bekannt, bei denen zig-Millionen Kundendaten gestohlen wurden, oft mit Passwörtern und weiteren kritischen Daten. 

Zu nennen sind da die ganz großen Hacks, von denen wir höchstwahrscheinlich alle betroffen sind:

  • 2011: Sony PlayStation Network: 75 Mio. Kundendaten
  • 2012: LinkedIn 160 Mio. Kundendaten
  • 2013: JP Morgan Chase, 
  • 2014: eBay (145 Mio Kundendaten), HomeDepot
  • 2015; Anthem, T-Mobile USA, Ashley Madison
  • 2016: Yahoo, MySpace, LinkedIn
  • 2017: Uber, Equifax
  • 2018: Netflix, Quora, Under Armour, Marriott (500 Mio. Kundendaten)

Gehackte Webseiten:

MySpace, Yahoo, Sony, Twitter, Badoo, LinkedIn, Minecraft, Netflix, PayPal, Origin, Amazon, Gmail, …

Unsere alle Benutzernamen und Passwörter wurden also bereits höchstwahrscheinlich gestohlen, wenn wir auf einer dieser Seiten einen Account haben oder hatten. Überprüfen kann man das hier, auf Have-I-been-pwned.

Präventionsmaßnahmen

Was kann man also tun?

  • Komplexe Passwörter verwenden
  • Passwörter sicher speichern
  • Regelmäßig Passwörter ändern
  • Passwörter nur 1x verwenden

Wie kann man das erreichen?

Wir unterscheiden hier noch die Möglichkeiten der Benutzer und der Betreiber der Webanwendungen.

Als Benutzer

Kein normaler Mensch kann sich viele, ausreichend komplexe Passwörter merken, zumal auf jeder Webseite ein anderes, das dann auch noch regelmäßig geändert werden muss. Deshalb gibt es für das Handling von Passwörtern nur eine sinnvolle Maßnahme, nämlich ein Passwort-Manager-Programm verwenden. Dort muss man sich nur das Master-Passwort merken, alle weiteren Passwörter werden dort sicher gespeichert.

Auch wenn das übliche Gegenargument kommt, dass wenn das Master-Passwort gehackt wird, dann sei alles bekannt. Ja, das stimmt, aber das ist um Welten unwahrscheinlicher, als der oben beschriebene, laxe Umgang mit Passwörtern der letzten Jahre. Die Passwort-Manager-Programme gelten als sicher, und das Master-Passwort kann man sich ja aufschreiben und in den Safe legen. Viel sicherer geht es eigentlich nicht, denn eines darf man nicht vergessen: es gibt keine absolute Sicherheit. Doch wenn der Aufwand für den Angreifer zu groß wird, dann zieht er weiter.

Als Webanwendungs-Betreiber

Erzwingen von komplexen Passwörtern

Die Verwendung von komplexen Passwörtern muss erzwungen werden. Daran gibt es nichts zu rütteln, denn wenn die Webseite durch zu einfache Passwörter geknackt wird, dann leidet nicht nur der betroffene Benutzer darunter, sondern auch die Webanwendung. 

Speichern von Passwörtern

Passwörter von Benutzern dürfen nicht gespeichert werden, damit ist nicht nur die unverschlüsselte Speicherung gemeint, sondern auch die Verschlüsselte. Denn was Verschlüsselt ist, kann generell auch wieder entschlüsselt werden. Und dafür gibt es keinen Grund. Nur der Benutzer selbst soll das Passwort kennen. Folglich stellt sich die Frage: wie findet dann die Überprüfung statt, ob das eingegebene Passwort richtig ist? Die Antwort ist: über einen Hash. Ein Hash ist das Produkt eines Hash-Algorithmus, der aus einem Passwort eine neue Zeichenfolge macht, und zwar immer in der selben Länge. z.B. bei SHA-256 sind das 64-Zeichen. Ändert sich im Passwort auch nur ein Zeichen, dann sind alle Zeichen des Hashes komplett anders. Dieser Hash wird also abgespeichert von der Webanwendung, so dass bei Eingabe des Passworts vom Benutzer der Hashwert mit dem gleichen Algorithmus gebildet wird, und dieser mit dem gespeicherten der Webanwendung verglichen wird. Stimmen beide überein, dann ist das Passwort richtig.

Hash-Algorithmus aktuell halten

Regelmäßig den verwendeten Hash-Algorithmus überprüfen und ggf. austauschen, damit er noch sicher genug ist. Durch schnellere Computer oder Bekanntwerden von Schwachstellen ist das immer wieder erforderlich. Dann muss beim nächsten Login des Benutzers das Passwort im neuen Hash abgespeichert werden und der alte Hash gelöscht werden. Denn werden die alten Hashes irgendwann erbeutet, dann können die Passwörter daraus erbeutet werden, was man auch vermeiden sollte. Die Passwort-Hashes der Benutzer, die nach einer gewissen Karenzzeit sich nicht einloggen, sollten deshalb auch gelöscht werden. Diese Benutzer müssen sich dann, wenn sie irgendwann wiederkommen, ein neues Passwort generieren lassen über den Passwort-Zurücksetz-Prozess.

Passwort-Zurücksetz-Prozess

Beim Prozess für das Rücksetzen des Passwortes sollte man es vermeiden, einen unsicheren Kanal zur Übermittlung des Passwortes zu verwenden. Auf keinen Fall darf es per E-Mail verschickt werden. Stattdessen sollten sichere Kanäle verwendet werden, so wie es im Banking-Umfeld gemacht wird, z.B. per Smartphone-App mit Ende-zu-Ende-Verschlüsselung. Oder sogar initial per Post. SMS gelten ebenfalls als nicht sicher, sind aber immer noch besser als E-Mail.

Session-Management

Session-ID

Das Zuweisen einer Browser-Session zu einem Benutzer-Kontext auf dem Server findet immer anhand einer Session-ID statt. Als unsicher gilt, wenn diese ID irgendwo sichtbar auftaucht, sei es in der URL, oder auch als Request-Parameter, der unterwegs im Netzwerk durch einen Man-in-the-middle-Angriff ausgelesen werden kann. Die Requests tauchen auch oft in Log-Ausgaben auf, so dass die dort ebenfalls abgegriffen werden könnten, wenn auf diese Zugriff besteht. URLs werden zudem im Browser in der Chronik und dem Cache gespeichert, was auch ein Ziel eines Angriffs ein kann.

Deshalb gehört eine Session-ID immer in ein gesichertes Cookie, das auf dem Transport verschlüsselt über HTTPS übertragen wird, so wie die gesamte Kommunikation. Per Konfiguration wird der Zugriff auf dieses Session-Cookie eingeschränkt, so dass es nicht per JavaScript ausgelesen werden kann, und nicht unverschlüsselt per HTTP übertragen wird.

Session-Cookie

Um einen Session-Fixation-Angriff zu vermeiden, bei dem ein Angreifer dem Opfer eine vordefinierte Session-ID unterschiebt, auf die der Angreifer dann aufspringen kann, wenn sich das Opfer einloggt, muss eine Session-ID nach dem Login von der Anwendung automatisch geändert werden. Nur so läuft bei dieser Attacke der Angreifer ins Leere.

Timeouts

Inaktivitäts-Timeout

Damit nach Untätigkeit im Browser-Fenster bzw. nach Schließen des Browsers, ohne auf Abmelden geklickt zu haben, die Session beendet wird, gibt es einen Timer, der herunterzählt und automatisch die Session beendet. Dieses Session-Timeout findet normalerweise spätestens nach 30 Minuten statt. Im Banking-Umfeld bereits nach 10 Minuten. Dies ist wichtig, da Benutzer sehr oft nicht auf Abmelden klicken, was dazu führen kann, dass diese Session von einem Angreifer verwendet werden kann. Dazu müsste er zwar erst die Session-ID herausfinden, aber dafür gibt es zahlreiche Möglichkeiten. Sind diese nicht alle durch Secure Coding verhindert, dann findet der Angreifer alle Daten des Benutzers ungesichert vor. Um das zu verhindert, gibt es ein Session-Inaktivitäts-Timeout.

Absolutes Timeout

Aber was geschieht mit Webseiten, die im Hintergrund immer wieder von selbst Anfragen absetzen? Sogenannte Ajax-Calls, das sind Requests, die per JavaScript eigenständig abgeschickt werden, um den Status der Webseite zu aktualisieren. Sie sorgen dafür, dass ein Inaktivitäts-Timeout nicht stattfinden kann. Deshalb sollte es neben den Inaktivitäts-Timeouts auch noch ein absolutes Timeout geben, das die Session nach beispielsweise 12 Stunden beendet, bzw. eine erneute Authentifizierung verlangt. Andernfalls würde eine Session zu lange leben, zumindest solange sie in einem vielleicht längst vergessenen Browser-Reiter angezeigt wird. Da dies ein Risiko darstellt, sollte es neben dem Inaktivitäts-Timeout auch ein absolutes Timeout geben.