Nextcloud und der zweite Faktor: Was hinter U2F, WebAuthn und dem Alltag mit Hardware-Schlüsseln steckt

Wer Nextcloud selbst betreibt, kennt die Diskussion. Irgendwann kommt der Punkt, an dem ein einfaches Passwort nicht mehr genügt – sei es, weil die DSGVO-Auditoren genauer hinschauen, weil ein Mitarbeiter auf einen Phishing-Link geklickt hat oder weil man selbst nachts schlecht schläft, wenn die Instanz mit Firmendaten offen im Netz steht. Zwei-Faktor-Authentifizierung ist dann schnell gesetzt: ein TOTP-Code, ein Backup-Code, fertig. Doch während viele bei Einmalpasswörtern per App hängen bleiben, lohnt sich ein zweiter Blick auf das, was unter dem etwas sperrigen Kürzel U2F firmiert – und was technisch längst von WebAuthn überholt wurde. Genau hier hat sich in der Nextcloud-Welt in den letzten Jahren mehr bewegt, als viele Admins auf dem Schirm haben.

Ein kurzer Rückblick: Warum U2F nicht mehr das Maß der Dinge ist

U2F steht für „Universal Second Factor“ und wurde 2014 von Google und Yubico ins Leben gerufen, bevor die FIDO Alliance das Zepter übernahm. Die Idee war einleuchtend: Ein kleiner USB-Stick oder eine NFC-Karte übernimmt den zweiten Faktor, das Geheimnis verlässt das Gerät nie, und der Schlüssel ist an eine Domain gebunden. Damit ist U2F weitgehend immun gegen die klassische Phishing-Falle, weil ein gefälschter Login unter einer ähnlich klingenden Domain technisch schlicht nicht funktioniert. Der Token prüft die Herkunft der Anfrage, bevor er überhaupt tätig wird.

Was U2F allerdings nicht konnte: Er war ausdrücklich nur als zweiter Faktor gedacht. Kein passwortloser Login, kein Ersatz für die erste Anmeldung, keine Verwendung als einziger Faktor für sensible Endgeräte. Genau deshalb hat die FIDO Alliance 2018 mit FIDO2 nachgelegt: WebAuthn auf Seiten des Browsers, CTAP2 auf Seiten des Tokens. U2F wurde zu CTAP1 degradiert, sozusagen der Vorläufer, den man aus Kompatibilitätsgründen noch mitschleift. Moderne YubiKeys, Nitrokeys oder SoloKeys beherrschen beides und werden heute meist als FIDO2-Token verkauft. Die alten „U2F-only“-Sticks sind fast aus dem Handel verschwunden, tauchen als Firmenbestand aber noch in Schubladen auf.

Nicht zuletzt deshalb ist die Bezeichnung „Nextcloud Two-Factor U2F“ heute etwas irreführend. Wer in der Nextcloud-App-Verwaltung nach der entsprechenden Erweiterung sucht, findet zwei Kandidaten: die alte App twofactor_u2f, die seit Jahren keine Pflege mehr erfährt, und twofactor_webauthn, die konzeptionell dasselbe leistet, nur zeitgemäß und mit voller FIDO2-Unterstützung. Beide Apps fristen in der offiziellen Übersicht ein eher unauffälliges Dasein – ein Umstand, der nicht zuletzt daran liegt, dass Nextcloud selbst die WebAuthn-Erweiterung erst relativ spät aus dem Community-Kontext in den eigenen Fokus gerückt hat.

Was Nextcloud unter der Haube anbietet

Nextcloud bringt seit Version 15 einen Zwei-Faktor-Rahmen mit, den man sich als eine Art Steckbrett vorstellen muss. Der Kern selbst kennt nur die Schnittstelle: Er verwaltet den Zustand pro Benutzer, stellt den Login-Flow bereit und zwingt den Client – etwa den Browser, den Desktop-Client oder die mobile App –, nach der Passwort-Eingabe einen zweiten Schritt zu absolvieren. Welche Verfahren dabei zum Einsatz kommen, regeln separate Apps. Im Standardpaket finden sich meist TOTP, Backup-Codes und die hauseigene Bestätigungsmethode über die Nextcloud-Notifications. Wer mehr braucht, installiert Erweiterungen wie eben twofactor_webauthn.

Ein interessanter Aspekt: Nextcloud erzwingt den zweiten Faktor nicht global. Die Prüfung greift pro Benutzer, und ob überhaupt ein zweiter Faktor verlangt wird, entscheidet in der Regel eine administrativ gesetzte Policy. Erst wenn der Administrator die Erzwingung aktiviert, müssen alle Benutzer – je nach Wählverhalten und App-Konfiguration – ein zweites Verfahren einrichten. Das klingt bürokratisch, ist aber sinnvoll, weil die Migration in einem bestehenden Bestand sonst schnell zum organisatorischen Problem wird. Man kann so in einer Testgruppe anfangen, dort Erfahrung sammeln und erst dann die Breite überrollen.

Für die Benutzerverwaltung stehen einige occ-Befehle bereit, die den Alltag erleichtern: occ twofactorauth:enforce schaltet die Erzwingung ein, occ twofactorauth:state zeigt den aktuellen Status, und mit occ twofactorauth:disable respektive :enable lassen sich einzelne Anbieter für einen bestimmten Benutzer deaktivieren – das ist die Rettungsleine, wenn sich jemand ausgesperrt hat. Wer die Erzwingung pro Gruppe differenzieren möchte, braucht dafür eine eigene App oder ein Skript, das die Einstellung über die OCS-API setzt. In der Praxis ist das ein Punkt, an dem man sich schnell eine kleine Automatisierung baut.

Der harte Katalog: Was der Server mitbringen muss

Bevor man in die Konfiguration einsteigt, sollte die technische Basis stimmen. WebAuthn verlangt zwingend einen sicheren Kontext – in der Praxis HTTPS. Die einzige Ausnahme sind localhost-Zugriffe, was für Entwicklungsumgebungen reicht, im Produktivbetrieb aber niemanden ernsthaft zufriedenstellt. Ein selbst signiertes Zertifikat funktioniert, führt in einigen Browsern jedoch zu Warnmeldungen, die den WebAuthn-Flow empfindlich stören können. Also lieber ein richtiges Zertifikat, notfalls von der eigenen internen CA.

Zweitens muss die Domain, unter der Nextcloud erreichbar ist, mit der konfigurierten „Relying Party ID“ übereinstimmen. Das ist der Begriff aus der WebAuthn-Spezifikation für den administrativen Bereich, an den ein Token gebunden wird. Vereinfacht gesagt: Ein Schlüssel, den ein Benutzer für cloud.firma.de registriert hat, funktioniert nicht bei cloud.firma-intern.de – und auch nicht bei einer IP-Adresse. Dieses Detail ist in der Praxis der häufigste Grund, warum eine eigentlich saubere Installation nicht funktioniert. Wer Nextcloud hinter einem Reverse Proxy wie nginx, Apache oder Traefik betreibt, muss in der config.php dafür sorgen, dass die Umgebungsvariablen korrekt durchgereicht werden. Besonders wichtig sind overwrite.cli.url, overwriteprotocol, overwritehost und trusted_proxies. Ohne diese Angaben weiß Nextcloud nicht, ob der Benutzer über https://cloud.firma.de oder über die interne Proxy-Adresse hereinkommt – und die WebAuthn-Origin-Prüfung schlägt fehl.

Drittens sollte man sich die Frage stellen, welche Tokens im Haushalt vorhanden sind. FIDO2-taugliche Schlüssel gibt es heute in fast jeder Preisklasse. YubiKey 5 NFC, Nitrokey 3, SoloKeys Solo 2 oder die günstigeren Varianten von Feitian sind gängige Optionen. Wer nur die alten U2F-Sticks besitzt: Die funktionieren weiterhin mit twofactor_webauthn, weil CTAP1 abwärtskompatibel unterstützt wird. Spätestens beim Wechsel auf passwortlose Szenarien wird man aber nicht drumherum kommen, nachzurüsten. Für Unternehmen mit MDM-Strategie sind außerdem Kartenleser und Smartcards mit PIV relevant – hier wird allerdings nicht WebAuthn, sondern PKI-basierte Verfahren über SSO-Provider interessant, dazu weiter unten mehr.

Einrichtung in der Praxis

Die Installation selbst ist unspektakulär. In der Nextcloud-Administration wechselt man in den App-Store, sucht twofactor_webauthn, aktiviert die App. Beim nächsten Login kann nun jeder Benutzer in den persönlichen Sicherheitseinstellungen einen Sicherheitsschlüssel registrieren. Der Ablauf ist selbsterklärend: Button drücken, Token anstecken oder per NFC auflegen, PIN eingeben, fertig. Der Browser bittet um Erlaubnis, mit dem Token zu kommunizieren, und legt anschließend eine Referenz auf das Gerät auf dem Server ab. Das eigentliche Geheimnis bleibt auf dem Token und verlässt dieses nie.

Wichtig zu wissen: Moderne FIDO2-Token verlangen in der Regel eine PIN, wenn sie als zweiter Faktor verwendet werden. Das dient weniger dem Schutz vor Diebstahl im engeren Sinne – dafür ist der zweite Faktor ja gerade gedacht – als vielmehr der Missbrauchsverhinderung bei verlorenen Sticks. Die PIN wird lokal auf dem Token geprüft, der Server sieht sie nie. Bei älteren U2F-Sticks entfällt dieser Schritt. In gemischten Umgebungen kann das zu Verwirrung führen, weil einige Nutzer plötzlich eine PIN eingeben sollen und andere nicht.

Was viele unterschätzen: Der Registrierungsvorgang ist an den Browser gebunden. Chrome, Firefox, Edge und Safari unterstützen WebAuthn in aktuellen Versionen vollständig. Ältere Browser oder bestimmte in Unternehmensumgebungen verteilte „Sicherheitsbrowser“ können Probleme machen, insbesondere wenn sie WebAuthn aus Datenschutzgründen deaktivieren. In der Praxis lohnt es sich, vor einem Rollout die Zielumgebung zu prüfen. Auch die Nutzung über Citrix, Terminal Server oder virtuelle Desktops ist ein Thema für sich – hier sind USB-Weiterleitungen oft nicht sauber konfiguriert, und NFC funktioniert sowieso nicht.

Für die administrative Seite ist besonders die Backup-Code-App von Bedeutung. Sie ist nicht optional, und sie sollte es auch nicht sein. Ein verlorener Hardware-Schlüssel ohne Backup-Code endet in einem Administrator-Rettungseinsatz, den man niemandem wünscht. Wirklich jeder Admin-Tutorial-Artikel vergisst diesen Punkt gerne: Bevor man den ersten Token registriert, sollte man Backup-Codes für sich selbst und für die Benutzer erzwingen. Nextcloud generiert sie bei Bedarf, und der Benutzer ist dafür verantwortlich, sie aufzubewahren.

Erzwingung – die richtige Dosis finden

Die globale Erzwingung ist ein zweischneidiges Schwert. Auf der einen Seite ist sie der einzige Weg, Sicherheit im gesamten Benutzerbestand durchzusetzen. Auf der anderen Seite ist sie ein harter Schalter. Wer sie umlegt, sperrt damit faktisch jeden aus, der noch keinen zweiten Faktor eingerichtet hat. Ausnahmen sind nicht vorgesehen, und die Rücknahme der Erzwingung ist administrativ möglich, aber potenziell ein Rückschritt in Bezug auf die Sicherheit.

Ein mehrstufiges Vorgehen bietet sich an: Zuerst Testgruppe aktivieren, dann sukzessive erweitern, erst am Ende die vollständige Erzwingung. Wer Zugriff auf die Nextcloud-Datenbank hat, kann die Erzwingung gruppenweise steuern, aber schöner ist es, das über die Benutzerverwaltung zu machen – am saubersten, indem man die Zugehörigkeit zu einer Gruppe „MFA-Pflicht“ nutzt und diese Gruppe dann in der Erzwingung berücksichtigt. Das funktioniert leider nicht out of the box; man braucht eine kleine Eigenentwicklung, eine App aus dem Community-Ökosystem oder die Konfiguration über einen Identity Provider, der die MFA-Anforderung bereits mitbringt.

Sinnvoll ist außerdem eine Ausnahme für Servicekonten. Maschinenbenutzer, die über die API auf Nextcloud zugreifen – Backup-Skripte, Monitoring, Sync-Jobs –, können keinen WebAuthn-Flow durchlaufen. Sie benötigen App-Passwörter oder eine andere Form der Authentifizierung, die von der Erzwingung ausgenommen ist. Nextcloud unterscheidet hier sauber, aber viele Admins stolpern darüber, weil sie die App-Passwörter nicht als Teil der MFA-Strategie sehen. Sie sind es aber sehr wohl: Ein App-Passwort umgeht die Zwei-Faktor-Prüfung, was bequem und gefährlich zugleich ist.

Was die Clients können – und was nicht

WebAuthn funktioniert im Browser. Das ist der klare Fall. Aber wer Nextcloud produktiv nutzt, arbeitet mit Desktop-Clients, mobilen Apps und WebDAV-Zugriffen. Hier zeigt sich eine wichtige Grenze: Diese Clients können den WebAuthn-Flow nicht selbst durchlaufen. Sie sind darauf angewiesen, dass der Benutzer sich im Browser anmeldet und dort ein App-Passwort generiert, das er dann im Client hinterlegt. Der Ablauf ist nicht elegant, aber sicher und mittlerweile gut dokumentiert.

Der Nextcloud Desktop-Client ab Version 3.3 unterstützt den Login-Flow über den System-Browser. Der Nutzer wird zum Browser weitergeleitet, meldet sich dort inklusive zweitem Faktor an und erhält anschließend einen App-spezifischen Token, der zurück in den Client fließt. Das ist deutlich besser als das manuelle Kopieren, war aber nicht immer so und taucht in älteren Clients noch als Frickelei auf. Mobile Apps für iOS und Android unterstützen den Flow ebenfalls, jedoch nicht in jeder Version und nicht immer identisch. Auch hier gilt: lieber vorab testen, statt zu hoffen.

Ein weiterer Punkt: Die Anmeldung über WebDAV, CalDAV oder CardDAV, wie sie bei synchronisierten Clients zum Einsatz kommt, akzeptiert kein WebAuthn. Für diese Zwecke sind App-Passwörter das Mittel der Wahl. Administrativ bedeutet das: Wer App-Passwörter nicht zentral betreut, hat schnell einen Wildwuchs an Tokens, die niemand überblickt. Nextcloud listet sie pro Benutzer auf und erlaubt das Zurückziehen. Das regelmäßige Aufräumen sollte in den Betriebsablauf eingeplant werden.

Migrieren von twofactor_u2f zu twofactor_webauthn

Wer noch die alte U2F-App betreibt, sollte zeitnah umstellen. Die Wartung ist eingestellt, Sicherheitslücken werden nicht mehr geschlossen, und die Kompatibilität mit modernen Browsern ist mindestens fraglich. Die Migration ist technisch nicht schwierig, verlangt aber Disziplin: Die beiden Apps können nicht parallel betrieben werden, weil sie sich um dieselbe Rolle streiten. Zuerst wird die alte App deinstalliert, dann die neue installiert, anschließend müssen alle Benutzer ihre Tokens neu registrieren. Das ist der unangenehme Teil, den viele aufschieben.

Eine Alternative kann sein, den Token als FIDO2-Schlüssel neu auszurollen – die Hardware bleibt ja dieselbe. Das klingt trivial, ist es aber nicht, weil die Token häufig im Unternehmen verteilt sind und die Nutzer zur Neu-Registrierung eingeladen werden müssen. In größeren Umgebungen empfiehlt sich ein gestaffeltes Vorgehen nach Abteilungen oder Standorten. Nichts ist unangenehmer als eine globale Umstellung, die am Freitagmittag die halbe Belegschaft aussperrt.

Der Übergang lässt sich insofern abfedern, als Backup-Codes parallel aktiv bleiben können. Solange die Backup-Codes gültig sind, haben Nutzer eine Notfalloption, auch wenn der Token gerade nicht registriert ist. Allerdings gilt: Sobald die alte App deinstalliert wurde, sind die alten U2F-Registrierungen weg. Das lässt sich nicht rückgängig machen.

Die Sache mit dem Phishing-Schutz

Es lohnt sich, den eigentlichen Sicherheitsgewinn klar zu benennen, weil er oft unter dem Berg von Konfigurationsdetails verschwindet. Ein Hardware-Token mit WebAuthn-Anbindung schützt gegen Phishing, weil der Schlüssel die Herkunft der Login-Anfrage prüft. Ein Angreifer, der eine gefälschte Nextcloud-Login-Seite unter einer anderen Domain betreibt, bekommt keine gültige Signatur – der Token verweigert schlicht die Arbeit. Bei TOTP ist das anders: Wer den Code abgreift, hat wenige Sekunden Zeit, ihn auf der echten Seite zu verwenden. Ein halbwegs flotter Phishing-Proxy reicht dafür aus. Genau diese Angriffe sind in den letzten Jahren massiv gestiegen, häufig über Reverse-Proxy-Kits wie Evilginx, die die Session übernehmen, bevor der zweite Faktor überhaupt greift.

Im Vergleich zu Push-Benachrichtigungen – wie sie etwa bei Duo oder Microsoft Authenticator üblich sind – schneidet der Hardware-Schlüssel ebenfalls besser ab, weil MFA-Fatigue-Angriffe nicht greifen. Bei Push-Verfahren kann ein Angreifer den Benutzer mit wiederholten Anfragen zermürben, bis dieser irgendwann bestätigt. Bei WebAuthn gibt es diesen Hebel nicht, weil die Anfrage an den Token selbst gebunden ist und nicht einfach bestätigt werden kann, ohne den Token zu besitzen.

Das bedeutet allerdings nicht, dass WebAuthn ein Allheilmittel ist. Wer die Backup-Codes schlecht aufbewahrt oder auf dem gleichen Gerät speichert, hat den zweiten Faktor ad absurdum geführt. Wer App-Passwörter ohne Ablaufdatum ausstellt, die in einem Chatverlauf herumliegen, hat dasselbe Problem. Die Technik ist nur so gut wie ihre organisatorische Einbettung. Nicht zuletzt deshalb lohnt sich eine kleine Richtlinie im Unternehmen, wann welche Art von Token verwendet wird und wie mit Verlust umzugehen ist.

Der Weg über Identity Provider

Wer ein größeres Umfeld betreut, wird irgendwann über einen zentralen Identity Provider nachdenken. Neben der Nextcloud-eigenen Anmeldung kann Nextcloud über SAML oder OpenID Connect an einen externen IdP angebunden werden. In dieser Konstellation wandert die MFA-Verantwortung zum IdP, und die WebAuthn-Integration findet nicht in Nextcloud, sondern in Keycloak, Authentik, Authelia oder einem Cloud-IdP statt. Das hat Vorteile: ein zentraler Ort für Authentifizierungspolicies, MFA-Erzwingung für alle Anwendungen, sauberes Provisioning über SCIM oder LDAP. Der Preis ist Komplexität und eine zusätzliche Komponente, die betrieben werden will.

Interessant ist in diesem Zusammenhang, dass Nextcloud selbst gar nicht so viel Know-how in Richtung WebAuthn mitbringt – die eingebaute MFA-Schnittstelle ist im Kern ein Rahmen für Erweiterungen, und die sicherheitsrelevanten Entscheidungen werden in den einzelnen Apps getroffen. Wer eine vollständig kontrollierte Authentifizierungskette braucht, ist mit einem externen IdP häufig besser beraten. Das ist ein Punkt, an dem die Community seit Jahren diskutiert und der sich mit jeder Version ein wenig weiterentwickelt.

Typische Stolperfallen im Betrieb

Über die Jahre haben sich einige Fehlerbilder eingebürgert, die immer wieder auftauchen. Der Reverse-Proxy-Fall wurde bereits erwähnt, aber es gibt weitere Klassiker. Ein häufiges Problem sind unterschiedliche Domains im gleichen Benutzerkonto: Wer sich mal unter cloud.example.com und mal unter cloud.example.net anmeldet – etwa weil beide DNS-Einträge nach außen zeigen –, kann den Token nur für eine der beiden Varianten registrieren. Wer die Ursache nicht kennt, sucht lange. Die Lösung besteht darin, in der Nextcloud-Konfiguration eine einzige kanonische Domain zu etablieren und die zweite per HTTP-Redirect dorthin umzuleiten.

Ein anderer Klassiker ist die fehlerhafte Zeitsynchronisation. Bei U2F und WebAuthn spielt die Serverzeit eine geringere Rolle als bei TOTP, aber wenn die Uhrzeit im Browser oder in der App deutlich abweicht, kann die Zeremonie fehlschlagen. NTP sauber konfigurieren, das hilft. Weniger offensichtlich: Manche Endpoint-Security-Suiten blockieren den Browser-Zugriff auf die HID-Schnittstelle. Wer im Unternehmen einen „Sicherheitsbrowser“ verteilt, sollte prüfen, ob WebAuthn zugelassen ist. Auch manche VPN-Setups, die TLS-Verbindungen aufbrechen, können die WebAuthn-Zeremonie stören, wenn sie nicht sauber konfiguriert sind.

Schließlich ein Punkt, der selten genannt wird: Wer die MFA-Erzwingung aktiviert und dann die WebAuthn-App deinstalliert – etwa aus Versehen im Rahmen einer Umstellung –, bricht sich selbst die Anmeldung. In der Zweifaktor-Konfiguration von Nextcloud werden die registrierten Faktoren mit einer Anbieter-ID verknüpft. Verschwindet die App, sind die Referenzen unbrauchbar. Man sollte daher vor jedem Eingriff in die App-Verwaltung immer einen zweiten Weg zur Anmeldung parat haben, sei es der zweite Administrator mit einem anderen Verfahren, sei es ein Terminalzugriff auf occ.

Ein Blick auf Kosten und Hardware-Lebenszyklus

Ein FIDO2-Token kostet zwischen 25 und 90 Euro, je nach Hersteller und Ausstattung. Im Unternehmensumfeld kommen die üblichen Fragen: Wer beschafft, wer tauscht aus, was passiert bei Verlust. Bewährt hat sich ein Modell, bei dem jeder Beschäftigte zwei Tokens erhält – einen als Hauptgerät, einen als Reserve zu Hause. Wer nur einen Token hat und diesen verliert, ist auf Backup-Codes angewiesen und muss beim IT-Support vorstellig werden. Zwei Tokens sind deutlich teurer, aber sie reduzieren den Supportaufwand spürbar.

Lebenszyklus-Management ist eine unterschätzte Disziplin. Token altern, Firmware-Lücken werden bekannt, manche Hersteller liefern nur wenige Jahre lang Sicherheitsupdates. Yubico und Nitrokey haben in dieser Hinsicht einen passablen Ruf, andere Anbieter weniger. Wer auf Nummer sicher gehen will, prüft regelmäßig die Firmware der Tokens – soweit das möglich ist – und plant den Austausch ein, bevor die installierte Basis EOL ist. Zertifizierungen wie FIDO2 Level 1 und Level 2 geben zumindest eine Orientierung, welcher Token für welche Zwecke geeignet ist.

Was bleibt zu tun?

Für die meisten Nextcloud-Admins ist die pragmatische Antwort: Die alte U2F-App stilllegen, twofactor_webauthn installieren, ein paar Testbenutzer einrichten, Backup-Codes bereitstellen, dann die Erzwingung stufenweise ausrollen. Wer kein zentrales IdP betreibt, hat damit eine solide Basis. Wer ein IdP betreibt, wird die MFA ohnehin dort verankern und in Nextcloud nur noch konsumieren. Der eigentliche Kern beider Wege ist derselbe: ein zweiter Faktor, der nicht abgegriffen werden kann.

Ob man dafür einen klassischen U2F-Stick oder einen modernen FIDO2-Schlüssel verwendet, ist heute weniger eine Sicherheitsfrage als eine Frage des Lebenszyklus. U2F ist nicht unsicher, aber es ist ein auslaufendes Modell. Wer neu einsteigt, sollte gleich auf FIDO2 setzen. Wer alte Bestände pflegt, kann U2F noch eine Weile weiterlaufen lassen, aber der Aufwand für Migration und Kommunikation sollte in der Roadmap stehen – nicht als „irgendwann“, sondern als konkreter Punkt mit Verantwortlichkeit und Zeitfenster.

Dabei zeigt sich einmal mehr, dass Nextcloud in puncto Authentifizierung inzwischen mehr kann, als viele auf den ersten Blick vermuten. Die WebAuthn-Anbindung ist technisch sauber, sie integriert sich in den bestehenden MFA-Rahmen und sie steht auch kleineren Installationen offen, die keinen IdP betreiben wollen. Was fehlt, ist weniger Funktionalität als klare Kommunikation: Die Dokumentation ist dünn, die App-Landschaft unübersichtlich, und wer sich zum ersten Mal mit dem Thema beschäftigt, verbringt die ersten Stunden mit Suchen statt mit Konfigurieren. Ein interessanter Aspekt – und vielleicht der wichtigste – ist dabei, dass die Sicherheit am Ende nicht an der Technik hängt, sondern an der Frage, ob die Organisation es schafft, den zweiten Faktor als Selbstverständlichkeit zu etablieren. Tokens in Schubladen sind teuer, unbequem und nutzlos. Tokens, die täglich benutzt werden, verändern die Sicherheitslage einer Nextcloud-Instanz hingegen spürbar.

Wer sich also die Mühe macht, hat am Ende nicht nur einen Phishing-Schutz gewonnen, sondern auch ein Stück Betriebsruhe. Und das ist in Zeiten, in denen jede Woche eine neue Schwachstelle die Runde macht, ein nicht zu unterschätzender Wert.