Tutorial: Einen zweiten Faktor einrichten und beim Anmelden verlangen
Voraussetzungen
- Diese DokuWiki-Instanz mit installiertem Paket wkidentity.
- Ein Konto mit Superuser-Recht für die Einstellungen.
- Ein Gerät mit einer Authenticator-App. Microsoft Authenticator und Google Authenticator sind der Regelfall; Aegis, FreeOTP, 2FAS und Bitwarden verhalten sich bei abweichenden Parametern anders — siehe Schritt 4.
Schritt 1: Den Anbieternamen setzen
Verwaltung → Konfigurationseinstellungen, Abschnitt wkidentity:
issuer = (leer)
Leer bedeutet: Der Wiki-Titel wird verwendet. Der Name steht später neben dem Konto in der Authenticator-App und entscheidet, ob jemand mit drei ähnlichen Einträgen den richtigen findet.
Schritt 2: Aus dem Profil heraus einrichten
Als das Konto anmelden, das den Faktor tragen soll, und do=profile öffnen. Der Knopf Einrichten erscheint nur, solange noch kein Faktor eingerichtet ist.
Die Einrichtung ist zweistufig: Der Start erzeugt ein Geheimnis, legt es aber ausschließlich in der Sitzung ab. Erst ein korrekter Code speichert es dauerhaft. Ein falscher Code lässt das schwebende Geheimnis unberührt — derselbe Bildcode kann erneut eingelesen werden.
Schritt 3: Prüfen, dass die Codes übereinstimmen
Bevor irgendetwas davon abhängt: do=wkidentity_debug (Verweis im Profil, steuerbar über show_debug_link). Die Seite rechnet Codes zu einem eingefügten Geheimnis vollständig im Browser und schickt nichts an den Server.
Schritt 4: Die Toleranz nur anpassen, wenn es sein muss
digits = 6 period = 30 window = 1
window ist die Toleranz gegen Uhrendrift in Zeitschritten. digits und period bleiben am besten unverändert: Microsoft Authenticator und Google Authenticator ignorieren beide Werte und rechnen immer mit sechs Ziffern und dreißig Sekunden. Abweichende Werte funktionieren nur mit Apps, die die Parameter tatsächlich auswerten — sonst wird jeder Code abgelehnt.
Schritt 5: Die Erzwingung einschalten, mit einem Weg zurück
enforce_login = 1
Ab jetzt verlangt jede Anmeldung eines eingerichteten Kontos zusätzlich einen Code. Konten ohne Faktor bleiben unberührt.
Die Einstellung überschreibt Kernverhalten der Anmeldung und steht deshalb als einfacher Schalter im gewöhnlichen Konfigurationsmanager, nicht nur im eigenen Verwaltungsbildschirm: Sie muss auch dann noch erreichbar sein, wenn der Verwaltungsbildschirm nicht mehr aufgeht.
Schritt 6: Die Versuchsgrenzen setzen
login_max_attempts = 5 login_attempt_window = 600
Nach login_max_attempts falschen Codes wird der wartende Anmeldevorgang verworfen; die Person beginnt wieder beim Kennwort. login_attempt_window ist zugleich die Lebensdauer des wartenden Vorgangs — danach beginnt sie auch mit null Fehlversuchen von vorn.
Erwartetes Ergebnis
Ein eingerichtetes Konto meldet sich mit Kennwort an, bekommt statt einer fertigen Sitzung eine Codeabfrage und ist erst nach korrektem Code angemeldet. Ein nicht eingerichtetes Konto meldet sich unverändert einstufig an. Ein bewiesener Faktor gilt für assurance_ttl Sekunden als Absicherung dieser Sitzung.
Nächste Schritte
- How to: Einen zweiten Faktor verlangen — wenn nicht nur beim Anmelden, sondern für bestimmte Inhalte