Passwortsicherheit bei Webanwendungen

Ben Fuhrmannek • SektionEins GmbH

Evaluation und Zwei-Faktor-Authentifizierung (2FA)

Braucht man eigentlich Passwörter? Es gibt viele Alternativen zur üblichen Anmeldung mit Benutzername und Passwort. Ob die Alternativen zur Anmeldung an einer bestimmten Webanwendung geeignet sind, liegt sehr an der Art der Anwendung und deren Anforderungen. Ein Web-Shop würde zum Beispiel nur wenige Kunden haben, wenn man sich ausschließlich per "Client-Zertifikat" anmelden könnte. Eine technische Universität dagegen kann erwarten, dass sich Studierende ein entsprechendes Zertifikat installieren.

Passwörter zur Authentifizierung haben den großen Vorteil, dass ein Login sehr einfach zu implementieren ist, und jeder weiß, wie so eine Art Login funktioniert. Deshalb ist ein Login mit Benutzername und Passwort auch im Jahr 2021 der Standard für Webanwendungen. Leider gibt es eine Reihe von Problemen:

  • Benutzer wählen schlechte Passwörter oder das gleiche Passwort für mehrere Dienste
  • Passwörter können mitgelesen oder weitergegeben werden
  • Passwörter können erraten werden
  • Passwörter einzugeben ist generell unbequem

Für Webanwendungen gibt es mehrere Alternativen zur Authentifizierung mit Benutzername und Passwort:

  • X.509 TLS Client-Zertifikat: Ein entsprechendes Zertifikat kann vom Benutzer selbst erzeugt werden, dann von einer CA signiert werden und nach der Installation im Webbrowser als sicheres Loginverfahren verwendet werden. Der private Teil des Zertifikats kann dabei je nach System im Browser oder im Betriebssystem sicher abgelegt werden oder alternativ auf externer Hardware. Dieses Verfahren gilt als sehr sicher. Aber sowohl die Implementierung auf Serverseite als auch die Einrichtung für Benutzer ist etwas komplexer als andere Verfahren.
  • FIDO U2F: FIDO Universal 2nd Factor (U2F (Quelle: https://en.wikipedia.org/wiki/Universal_2nd_Factor)) ist ein offener Standard, der in allen aktuellen Browsern implementiert ist. Ein Hardware-Token, der per USB, NFC oder Bluetooth angesprochen werden kann, dient als sicherer zweiter Faktor. Zur Sicherheit und Wirksamkeit von Hardware-basierter Authentifizierung wird gerne Google zitiert (Quelle: https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/), wo es seit der Einführung von U2F-Token für Mitarbeiteraccounts keine Accountübernahmen gegeben habe. — Günstige U2F-Hardware-Token werden schon für unter fünf Euro angeboten. In den meisten U2F-Token ist der private Schlüssel einmalig bei der Fertigung vorgegeben. Der U2F-Standard wurde durch den FIDO2-Standard überholt.
  • FIDO2 und Webauthn: FIDO2 (Quelle: https://fidoalliance.org/fido2/) ist der Nachfolger von U2F. Login mit Benutzername und Passwort wird hier komplett abgelöst durch ein Login mit Hardware-Token, der in den meisten Fällen wieder abgesichert ist mit einer PIN, so dass man zwei Faktoren zur Authentifizierung braucht. Alle aktuellen Browser unterstützen den FIDO2-Standard im Zusammenspiel mit Webauthn. Webauthn (Quelle: https://www.w3.org/TR/webauthn-1/) ist die W3C-Empfehlung zur Implementierung von starker Authentifizierung. Durch Webauthn kann der Benutzer wählen, wie das Login zu einer Anwendung für ihn am sinnvollsten erscheint. Das kann z.B. mittels Fingerabdruck sein, oder per Gesichtserkennung. Der Browser gibt nach erfolgreicher Freigabe durch den Benutzer die Schlüssel zur Authentifizierung an der Anwendung frei. Eine Art der Freigabe ist dabei die Nutzung von Schlüsseln auf einem FIDO2 Hardware-Token.
  • Login mit Handy-App und Push-Nachricht: Eine Handy-App bittet um Bestätigung des Logins, während man sich an einem Webbrowser einloggt. Beispiele sind die "Microsoft-Authenticator" App und "Google prompts".
  • Einmalpasswörter HOTP/TOTP: HMAC-based One-time Password (HOTP) ist ein Verfahren, mit dem Einmalpasswörter generiert werden. Der Benutzer tauscht ein Mal mit dem Server ein Initialpasswort aus. Danach wird nach einem offenen Standard für jedes Einmalpasswort eine weitere Iteration eines Hash-Algorithmus angewendet. Aus dem Ergebnis wird das Einmalpasswort abgeleitet. Das Time-based One-time Password (TOTP) erweitert HTOP so, dass automatisch nach einer vorgegeben Zeit - meistens 30 Sekunden - ein neues HOTP-Passwort generiert wird. Das wohl bekannteste Beispiel für TOTP ist die "Google Authenticator" App. Das Verfahren wird üblicherweise als zweiter Faktor zur Absicherung von Accounts mit Passwort-Authentifizierung verwendet.
  • Einmalpasswörter via SMS: Der Benutzer bekommt eine Textnachricht mit einem Einmalpasswort per SMS, das als zweiter Faktor dient. Diese Art der Authentifizierung gilt als unsicher, da ein Angreifer ggf. Zugriff auf das Telefon des Benutzers hat, oder Zugriff auf die SIM-Karte des Benutzers, oder Zugriff auf den Übertragungsweg der SMS.
  • Single-Sign-On (SSO) bzw. Login mit externem Dienst: Hier wird das Problem der Authentifizierung an der eigenen Anwendung zu einem anderen Anbieter ausgelagert. Beispiele sind "Login mit Apple" oder "Login mit Google". Der Aufwand für die Implementierung ist meistens recht gering, da offene Standards wie Oauth oder OpenID Connect verwendet werden oder der Anbieter Bibliotheken für die gebräuchlichsten Programmiersprachen zur Verfügung stellt. Für den Benutzer ist diese Art Login sehr komfortabel, allerdings macht man sich sowohl als Benutzer als auch als Betreiber der Webanwendung stark abhängig von dem externen Dienst. Die Praxis hat gezeigt, dass diese Art Login eher als Option zur Verfügung steht, nicht als einzige Authentifizierungsmöglichkeit.

Die angesprochenen Verfahren zur Zweifaktor-Authentifizierung (2FA) beziehen sich auf eine zweite Art der Authentifizierung als zweiten Faktor. Der Benutzer braucht also zum Authentifizieren neben einem Passwort, das er weiß, eine Hardware oder ein App auf dem Smartphone, die er besitzt. Ein zweites Passwort wäre dagegen kein zweiter Faktor.

Ein großes Problem, bei der Implementierung von 2FA ist die Authentifizierung im Fall, dass der Benutzer seinen zweiten Faktor nicht mehr hat. Vorstellbar sind z.B. Einmalpasswörter, die der Benutzer herunterladen und ausdrucken soll. Falls der Benutzer die Passwörter statt dessen nicht druckt, sondern speichert, wäre ein digitaler Angriff denkbar. Im anderen Extremfall, wenn z.B. eine Accountwiederherstellung vergessen worden wäre zu implementieren, oder wenn der Prozess zu umständlich oder fehlerhaft implementiert wäre, hätte der Benutzer effektiv seinen Account verloren. Es gilt also einen Mittelweg zu finden, je nach Anwendungsfall.