Zwei-Faktor-Anmeldung #

owncloud.online prüft den zweiten Faktor im Kern, liefert ihn aber nicht selbst: Den Faktor bringt eine App mit, die sich in ihrer info.xml unter <two-factor-providers> einträgt. Für zeitgesteuerte Einmalpasswörter (TOTP) ist das die App twofactor_totp. Ohne eine solche aktivierte App fragt die Anmeldung keinen zweiten Faktor ab, auch dann nicht, wenn der Zwang eingeschaltet ist.

Provider-App bereitstellen #

Die App gehört nicht zum Lieferumfang des Kerns. Sie steht öffentlich im Marketplace (ohne API-Schlüssel) und wird wie andere Apps über den Markt installiert, siehe Apps und Marketplace. Auf der Kommandozeile installiert und aktiviert ein Befehl die App:

sudo -u www-data php8.4 occ market:install twofactor_totp

Liegt die App schon in der Instanz und ist nur abgeschaltet, genügt:

sudo -u www-data php8.4 occ app:enable twofactor_totp

Die QR-Codes erzeugt die App mit imagick und verlangt die Erweiterung in ihrer info.xml (<lib>imagick</lib>). Fehlt php8.4-imagick, lehnt occ app:enable das Aktivieren ab und nennt die fehlende Bibliothek („The library imagick is not available.“). market:install prüft die Bibliothek nicht und schaltet die App trotzdem ein. Ohne die Erweiterung lässt sich der Schlüssel aber weder in den Kontoeinstellungen noch auf der Anmeldeseite als QR-Code anzeigen. Installieren Sie php8.4-imagick deshalb vor der App.

Welche Apps aktiv sind, zeigt:

sudo -u www-data php8.4 occ app:list

Zweiten Faktor im Konto einrichten #

Der Weg führt über Einstellungen → Persönlich → Sicherheit, Abschnitt TOTP-Zweifaktorauthentifizierung:

1. Das Kästchen TOTP (zeitgesteuertes Einmalpasswort) aktivieren setzen. Der Server erzeugt daraufhin einen neuen Schlüssel und zeigt ihn zusammen mit einem QR-Code an.
2. Den QR-Code in der Authenticator-App scannen. Wer nicht scannen kann, überträgt den Wert hinter Dies ist dein neuer TOTP-Schlüssel: von Hand.
3. Den sechsstelligen Code aus der App in das Feld Authentifizierungscode eintragen und Bestätigen drücken. Die Antwort lautet Bestätigt oder Nicht bestätigt. In der Sprachfassung Deutsch (Förmlich: Sie) heißen dieselben Beschriftungen Überprüfen, Geprüft und Nicht geprüft.

Schritt 3 ist der entscheidende: Nur ein bestätigter Schlüssel zählt. Wird das Kästchen gesetzt, aber nie ein Code bestätigt, bleibt die Anmeldung unverändert. Beim nächsten Aufruf der Seite steht das Kästchen wieder leer, denn sein Zustand hängt am bestätigten Schlüssel. Wird das Kästchen wieder entfernt, löscht der Server den Schlüssel; eine erneute Aktivierung erzeugt einen neuen und verlangt einen neuen Scan.

Zum Zeitverhalten: Der Code wechselt alle 30 Sekunden, und die Prüfung akzeptiert drei Zeitschritte in beide Richtungen, also rund anderthalb Minuten Abweichung zwischen Server- und Geräteuhr. Ein bereits angenommener Code wird kein zweites Mal akzeptiert; der zuletzt geprüfte Code wird dafür gespeichert.

Zweiten Faktor erzwingen #

Der Zwang steht unter Einstellungen → Administration → Sicherheit, Abschnitt Zwei-Faktor-Authentifizierung. Dort gibt es zwei Bedienelemente:

• das Kästchen Erzwinge Zwei-Faktor-Authentifizierung für alle Nutzer.
• das Feld Die folgenden Gruppen sind von der erzwungenen Zwei-Faktor-Authentifizierung ausgenommen

In der Sprachfassung Deutsch (Förmlich: Sie) heißt der Navigationspunkt Administrator statt Administration; der Abschnitt selbst ist derselbe.

Beide Bedienelemente schreiben in die App-Konfiguration:

Dieselbe Einstellung auf der Kommandozeile:

sudo -u www-data php8.4 occ config:app:set core enforce_2fa --value yes
sudo -u www-data php8.4 occ config:app:set core enforce_2fa_excluded_groups --value '["Technik","Vorstand"]'
sudo -u www-data php8.4 occ config:app:get core enforce_2fa
sudo -u www-data php8.4 occ config:app:get core enforce_2fa_excluded_groups

Ausschalten geht über --value no oder durch Löschen des Schlüssels:

sudo -u www-data php8.4 occ config:app:delete core enforce_2fa

Was der Zwang je Gruppe tatsächlich leistet #

Das Modell kennt nur Ausnahmen, keine Positivliste: Der Zwang gilt für alle, und die eingetragenen Gruppen sind davon ausgenommen. Soll er nur für eine einzige Gruppe gelten, müssen alle übrigen Gruppen in der Ausnahmeliste stehen. Konten, die in keiner Gruppe sind, lassen sich auf diesem Weg nicht ausnehmen, weil die Prüfung nur Gruppenmitgliedschaften vergleicht. Mitglieder ausgenommener Gruppen können den Faktor weiterhin freiwillig einrichten; darauf weist auch die Oberfläche hin.

Verhalten bei erzwungenem Faktor #

• Konten ohne eingerichteten Faktor werden nicht ausgesperrt: Auf der Faktor-Seite erzeugt die App einen Schlüssel und zeigt den QR-Code an, die Einrichtung findet also unmittelbar bei der Anmeldung statt. Der eingegebene Code gilt zugleich als Bestätigung des neuen Schlüssels.
• Der Zwang überstimmt die kontobezogene Abschaltung (siehe unten).
• Ohne aktive Provider-App bleibt der Zwang wirkungslos, weil es keinen Faktor gibt, der abgefragt werden könnte.

Der Ablauf nach richtigem Passwort: Es erscheint die Seite Bestätigung in zwei Schritten mit der Liste der verfügbaren Faktoren; bei genau einem Faktor geht es direkt zur Code-Eingabe. Bis der Code stimmt, gibt der Server keine andere Seite frei; nur Anmelden abbrechen führt hinaus.

App-Passwörter und Client-Abgleich #

Gilt für ein Konto ein zweiter Faktor, weist der Server jede Client-Anmeldung ab, die das Kontopasswort mitsendet. Anfragen mit einem App-Passwort (Gerätetoken) laufen unverändert weiter.

Bestehende App-Passwörter bleiben gültig. Das Einschalten des zweiten Faktors entzieht keine Token. Das ist bequem für bereits eingerichtete Clients und zugleich der wunde Punkt der Maßnahme: Ein abgeflossenes App-Passwort umgeht den zweiten Faktor weiterhin. Wer den Faktor einführt, um kompromittierte Zugangsdaten auszuschließen, muss die Token deshalb durchgehen und entziehen.

App-Passwörter erstellen und entziehen Sie unter Einstellungen → Persönlich → Sicherheit, Abschnitt App-Passwörter / Token: Namen eintragen und Neuen App-Passcode erstellen drücken. Benutzername und Passwort / Token erscheinen danach ein einziges Mal. Auf derselben Seite listet der Abschnitt Sitzungen die aktuell angemeldeten Web-, Desktop- und Mobil-Clients.

Unabhängig vom zweiten Faktor lässt sich die Anmeldung mit dem Kontopasswort für alle Clients sperren, in config/config.php:

'token_auth_enforced' => true,

Die Browser-Anmeldung ist davon nicht betroffen.

Wenn ein Konto seinen zweiten Faktor verloren hat #

Der zweite Faktor lässt sich nicht wiederherstellen, nur zurücksetzen. Danach richtet das Konto ein neues Gerät ein.

In der Verwaltungsoberfläche steht dafür Einstellungen → Administration → Nutzer-Authentifizierung, Abschnitt TOTP Admin Reset. Die Beschriftungen dieses Abschnitts sind nicht übersetzt und erscheinen auch in einer deutschen Oberfläche englisch: über Search users das Konto suchen, in der Liste markieren und Reset selected drücken. Reset all TOTP setups setzt sämtliche Einrichtungen der Instanz zurück.

Derselbe Vorgang auf der Kommandozeile:

sudo -u www-data php8.4 occ twofactor_totp:delete-secret alice
sudo -u www-data php8.4 occ twofactor_totp:delete-secret alice bob
sudo -u www-data php8.4 occ twofactor_totp:delete-secret --all

Ohne Kontoangabe und ohne --all bricht der Befehl mit einem Hinweis ab. Die Ausgabe nennt je Konto die Zahl der gelöschten Schlüssel.

Was danach passiert, hängt am Zwang: Ist er für das Konto wirksam, richtet sich das Konto bei der nächsten Anmeldung auf der Faktor-Seite neu ein. Ist er es nicht, ist der zweite Faktor für dieses Konto aus, bis es ihn in den Kontoeinstellungen wieder einschaltet.

Zwei weitere Wege, die den Schlüssel erhalten:

# Faktor für ein Konto abschalten, ohne den Schlüssel zu löschen
sudo -u www-data php8.4 occ user:setting alice core two_factor_auth_disabled --value 1

# Abschaltung wieder zurücknehmen
sudo -u www-data php8.4 occ user:setting alice core two_factor_auth_disabled --delete

# Schlüssel als „nicht geprüft“ markieren; der Faktor ist damit aus, sofern kein Zwang gilt
sudo -u www-data php8.4 occ twofactor_totp:set-secret-verification-status false --uid alice

Beide Wege greifen nur, solange der Zwang für dieses Konto nicht gilt, denn der Zwang wird zuerst geprüft. Bei erzwungenem Faktor führt ein als „nicht geprüft“ markierter Schlüssel lediglich wieder auf die Faktor-Seite, auf der derselbe Schlüssel erneut als QR-Code erscheint. Die Abschaltung über two_factor_auth_disabled geht auch über die Provisioning-API: ein PUT auf ocs/v1.php/cloud/users/<uid> mit dem Schlüssel two_factor_auth_enabled (Wert true oder false). Beim Abruf der Kontodaten liefert die API dasselbe Feld mit.

Aufräumen von Schlüsseln bereits gelöschter Konten:

sudo -u www-data php8.4 occ twofactor_totp:delete-redundant-secret

Zusammenspiel mit der Bremse gegen Passwort-Raten #

Die Bremse gegen Passwort-Raten zählt fehlgeschlagene Passwort-Prüfungen je Kombination aus IP-Adresse und Anmeldename. Die ersten Versuche bleiben ohne Wartezeit, danach wächst sie, und das Anmeldeformular zeigt die Restzeit an. Hinter einem Reverse-Proxy zählt die Bremse nur richtig, wenn trusted_proxies korrekt gesetzt ist, siehe Sicherheit und Setup-Warnungen.

Für den zweiten Faktor ist die Reihenfolge entscheidend:

1. Falsches Passwort: Der Versuch wird gezählt, die Faktor-Seite wird nie erreicht.
2. Richtiges Passwort: Der Zähler für dieses Paar aus IP und Anmeldename wird geleert, danach folgt die Faktor-Seite.
3. Falscher Code auf der Faktor-Seite: Der Versuch wird nicht gezählt. Der Kern schreibt lediglich eine Warnung ins Protokoll: Two factor verify failed: '<konto>' (Remote IP: '<ip>').

Die Bremse schützt also das Passwort, nicht den zweiten Faktor. Nach beliebig vielen falschen Codes gibt es weder Wartezeit noch Sperre. Gegen das Raten des Codes stehen allein seine sechs Stellen, das enge Zeitfenster und die Sperre gegen die Wiederverwendung eines Codes. Wer das für zu wenig hält, überwacht die genannte Protokollzeile, siehe Serverprotokoll und Fehlermeldungen.

Ist die App brute_force_protection aktiviert, übernimmt sie den Schutz der Anmeldung und der Passwörter öffentlicher Links. Die eingebaute Bremse tritt auf genau diesen beiden Wegen zurück, damit nicht zwei Mechanismen nebeneinander zählen und zwei verschiedene Wartezeiten nennen. Für alle übrigen Aktionen bleibt sie zuständig.

Fehlersuche #