Skip to content

Zwei-Faktor-Authentifizierung - Die Server-Seite

Eine Zwei-Faktor-Authentifizierung ist sicher, wenn der richtige, also sichere, 2. Faktor gewählt wird. Damit allein ist es aber nicht getan. Zum einen muss der 2. Faktor auch auf dem Server implementiert werden (worauf ich hier nicht eingehe), zum anderen müssen einige Ausnahmefälle berücksichtigt werden. Denn trotz 2-Faktor-Authentifizierung benötigt man unter Umständen eine

Authentifizierung ohne 2. Faktor

Im wesentlichen müssen zwei Punkte berücksichtigt werden:

  1. Man benötigt eine Sonderlösung für Anwendungsfälle, die ohne zweiten Faktor auskomme müssen wie zum Beispiel andere Server, die auf den eigenen zugreifen müssen.
  2. Man benötigt eine Backuplösung für den Fall, dass ein Benutzer seinen 2. Faktor verloren hat oder er ihm gestohlen wurde. Nicht zu vergessen einen möglichen Ausfall des 2. Faktors, zum Beispiel eines Security-Tokens.

Autorisierung statt Authentifizierung für Apps

Fangen wir mit Apps an, die die Webanwendung im Namen eines Benutzers nutzen sollen. Dabei ist es völlig egal, ob das eine Desktop-Anwendung, eine andere Webanwendung oder eine Smartphone-App ist - sie muss sich irgendwie gegenüber dem Server als "Benutzer" authentifizieren.

Im einfachsten Fall hat der Benutzer dafür in der App seine Zugangsdaten gespeichert. Solange es sich dabei nur um Benutzernamen und Passwort handelt, war das zwar leichtsinnig, aber problemlos möglich. Aber wie gelangt die App bei einer 2-Faktor-Authentifizierung an den benötigten Faktor? Meist gar nicht, und das ist auch gut so.

Statt die App als "Benutzer" auszugeben, kann der Benutzer ihr auch gegenüber dem Server erlauben, in seinem Namen zu agieren. Dafür verwenden Sie OAuth. Wie das generell funktioniert und wie sie OAuth mit PHP nutzen habe ich in zwei Artikeln für das Entwickler Magazin beschrieben, die auch online veröffentlicht wurden (siehe die beiden Links).

Individuelle Zugangsdaten für spezielle Apps

Falls die Verwendung von OAuth aus welchen Gründen auch immer nicht möglich ist, bleibt als einzige Lösung nur der Verzicht auf den 2. Faktor und die Verwendung individueller Zugangsdaten, zumindest individueller Passwörter für je einzelne App, für die eine Sonderlösung nötig ist. Dabei sollte der Geltungsbereich dieser Zugangsdaten so weit wie möglich eingeschränkt werden, um einen Missbrauch zumindest zu erschweren.

Einem Angreifer ist es egal, ob er das Passwort einer App oder eines Benutzers ausspäht. Ist das Passwort aber zum Beispiel nur gültig, wenn es von einer ganz bestimmten IP-Adresse gesendet wird, schränkt das die Missbrauchsmöglichkeiten ein. Ein Angreifer kann zwar immer noch die Absender-Adresse des Requests mit dem Passwort fälschen, die Antwort des Servers erreicht ihn dann aber nicht.

Kann durch so einen quasi "blinden" Request Schaden angerichtet werden, hilft unter Umständen das Hinzufügen eines Challenge-Response-Verfahrens: Auf das Passwort wird mit dem Senden einer Challenge geantwortet, die einem Angreifer mit gefälschter Absender-Adresse nicht erreicht. Und die legitime App empfängt die Challenge zwar, antwortet aber nicht darauf, da sie ja zuvor keine Verbindung zum Server aufgebaut hat.

Backup tut not!

Was passiert, wenn ein Benutzer seinen 2. Faktor verliert, er ihm gestohlen wird oder der Faktor einfach defekt ist? Jede Anwendung, die eine 2-Faktor-Authentifizierung implementiert, muss für solche Fälle eine Möglichkeit vorsehen, über die der legitime Benutzer auch ohne 2. Faktor Zugriff auf die Anwendung erhält.

Diese Backuplösung kann beliebig komplex und/oder zeitaufwendig sein. Kommt es beim Erlangen des Zugriffs auf ein paar Tage nicht an, kann ein neuer 2. Faktor oder ein Brief mit einem temporärem Passwort per Briefpost an die Adresse des Benutzers geschickt werden. Soll es schnell gehen, kann ein dem Benutzer vorab mitgeteiltes "Notfall-Passwort" verwendet werden, über dass der Benutzer ohne 2. Faktor Zugriff auf die Anwendung erhält. Wird der 2. Faktor als SMS versendet, kann die SMS an eine vorab(!) vom Benutzer angegebene Backup-Telefonnummer gesendet werden, usw. usf.

Wichtig ist es, sicher zu sein, dass die Backuplösung nicht von einem Angreifer missbraucht werden kann. Wird zum Beispiel ein temporäres Passwort per Briefpost gesendet, könnte ein Angreifer die Backup-Lösung auslösen und den Brief dann aus dem Briefkasten des Empfängers angeln. Ist die Authentifizierung trotz angestoßener Backup-Lösung weiterhin mit der 2-Faktor-Authentifizierung möglich, bemerkt der Benutzer den Angriff womöglich erst, wenn es zu spät ist. Daher sollte bei Inanspruchnahme der Backup-Lösung die normale 2-Faktor-Authentifizierung gesperrt werden.

Dabei muss aber darauf geachtet werden, dass kein DoS-Angriff auf den Benutzer möglich ist. Es wäre ja schließlich fatal, wenn ein Angreifer durch einfaches Klicken eines "Ich habe meinen 2. Faktor verloren"-Links und Angabe der Benutzer-ID den Benutzer aus seinem Account aussperren könnte.

Generell ist eine Sperrung des abhanden gekommenen 2. Faktors aber schon deshalb nötig, weil es sich ja um einen Angriff auf den Benutzer handeln könnte. Wer kann zum Beispiel mit Sicherheit sagen, dass er sein Smartphone mit der App zum Erzeugen von Einmalpasswörtern wirklich verloren hat und es nicht gestohlen wurde? Von der Möglichkeit eines unehrlichen Finders ganz zu schweigen!

Sie sehen also, beim Einsatz einer 2-Faktor-Authentifizierung ist auf der Server-Seite einiges zu beachten.

Hiermit ist das Thema "Authentifizierung" zumindest fürs erste abgeschlossen. Womit es in der nächsten Folge weiter geht habe ich noch nicht endgültig entschieden.

Carsten Eilers


Übersicht über alle Artikel zum Thema

Authentifizierung: Sichere Passwörter
Authentifizierung: Passwortregeln, Teil 1
Authentifizierung: Passwortregeln, Teil 2
Authentifizierung: Ein Faktor reicht nicht (mehr)
Zwei-Faktor-Authentifizierung per SMS
Zwei-Faktor-Authentifizierung mit spezieller Hardware, Teil 1
Zwei-Faktor-Authentifizierung mit spezieller Hardware, Teil 2
Zwei-Faktor-Authentifizierung mit der Smartphone-App
Zwei-Faktor-Authentifizierung - Die Server-Seite

Trackbacks

blog.hagga.net am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.