Zum Inhalt

2FA — Zwei-Faktor-Authentifizierung

Vesana kennt zwei 2FA-Methoden. Jeder User entscheidet selbst, welche er unter Einstellungen → 2FA einrichtet — außer eine Pflicht-Regel schreibt eine bestimmte Mindeststärke vor (siehe unten). E-Mail-2FA wurde entfernt (schwächster Faktor, SMTP-abhängig).

Die zwei Methoden

Methode Wie Stärke
Authenticator-App (TOTP) Standard-Authenticator (z. B. Google Authenticator, Authy), QR-Code beim Einrichten Stark — funktioniert offline, kein Mail-Account-Zugriff nötig
Sicherheitsschlüssel (WebAuthn/Passkey) Hardware-Key oder Plattform-Passkey (z. B. Windows Hello, Touch ID) Stärkste Stufe — Hardware-gebunden, Phishing-resistent

Ein Konto kann beide Methoden gleichzeitig haben: Wer zusätzlich zum Authenticator einen Sicherheitsschlüssel registriert, verliert den Authenticator-Weg nicht. Die Anmeldemaske bietet dann an, was das Konto wirklich hat — Sicherheitsschlüssel, Authenticator-Code oder Backup-Code — mit Umschalter, falls der Schlüssel gerade nicht zur Hand ist. Bei 5 Fehlversuchen im Login greift ein 30-Minuten-Lockout.

Bis v1.9.441 sperrte ein registrierter Passkey das Konto aus

Die Anmeldung verlangte danach den Passkey, kannte aber nur das Feld für den Authenticator-Code — jede Eingabe endete in einer Fehlermeldung, und es half nur ein Zurücksetzen durch einen Super-Admin. Wer noch auf einer älteren Version ist, richtet Passkeys erst nach dem Update ein.

Authenticator-App (TOTP) einrichten

Einstellungen → 2FA → Authenticator-App:

  1. QR-Code mit der App scannen (oder Secret manuell eintippen)
  2. Angezeigten 6-stelligen Code eingeben zur Bestätigung → 2FA aktiv

Sicherheitsschlüssel (WebAuthn) einrichten

Einstellungen → 2FA → Sicherheitsschlüssel:

  1. Hardware-Key anstecken/antippen oder Plattform-Passkey bestätigen
  2. Registrierung abschließen → hat das Konto noch keine Backup-Codes, werden 10 Backup-Codes einmalig angezeigt — sofort herunterladen oder ausdrucken

Backup-Codes sind bei WebAuthn Pflicht — sie sind der Rettungsanker, falls der Schlüssel verloren geht. Ein weiterer Passkey ersetzt vorhandene Codes nicht. Wer seinen letzten Passkey löscht, erfüllt eine Passkey-Pflicht nicht mehr.

Auch die Authenticator-App bekommt Backup-Codes (ab v1.9.442): beim Aktivieren werden zehn Codes erzeugt und einmalig angezeigt, ebenso im Dialog, der 2FA verpflichtend einrichtet. Vorhandene Codes bleiben dabei unangetastet. Unter Einstellungen → 2FA steht, wie viele Codes noch übrig sind, mit einem Knopf zum Erzeugen — auch für Konten, die bisher keine hatten. Vorher besaß ein Konto mit reiner Authenticator-App gar keinen Ersatzweg: Handy verloren hieß Konto zu.

Backup-Codes neu erzeugen erfordert einen frischen Faktor-Nachweis

Neue Backup-Codes generieren — wie jede heikle Aktion — verlangt eine Identitätsbestätigung der letzten 15 Minuten (Passkey, Authenticator-Code, Passwort oder Backup-Code); sonst könnte ein gestohlenes Login-Cookie allein alle Codes rotieren.

Passkeys brauchen keine Einrichtung auf der Instanz: Vesana nimmt den Hostnamen der Adresse, unter der Vesana aufgerufen wird, als Relying-Party-ID. Browser bieten Passkeys allerdings nur über HTTPS (oder localhost) an.

Anmelden mit Passkey statt Passwort

Ein eingerichteter Passkey meldet auch ohne Benutzername und Passwort an: auf der Anmeldeseite Mit Passkey anmelden wählen, das Gerät zeigt seine Passkeys für diese Instanz, Fingerabdruck, Gesicht oder PIN bestätigen — fertig. Ein zweiter Faktor wird dabei nicht mehr abgefragt, denn der Passkey ist beides: Besitz des Geräts plus dessen Entsperrung.

  • Das Gerät muss die Entsperrung (PIN/Biometrie) bestätigen. Ein Sicherheitsschlüssel ohne PIN bleibt zweiter Faktor nach dem Passwort.
  • Der Passkey muss auf dem Gerät gespeichert sein (Handy, Windows Hello, Touch ID, Passwort-Manager). Passkeys, die vor diesem Update als reiner Hardware-Schlüssel registriert wurden, bietet das Gerät dort unter Umständen nicht an — dann einmal neu registrieren.
  • Nur für lokale Konten. Konten aus Active Directory/LDAP und SSO melden sich weiter über ihr Verzeichnis bzw. ihren Anbieter an; ihr Passkey bleibt zweiter Faktor.
  • Jeder Versuch steht im Audit-Log (login mit Methode passkey, abgelehnte als login_failed).

Faktor-Stärke-Hierarchie

Ein stärkerer Faktor erfüllt automatisch jede schwächere Pflicht:

Sicherheitsschlüssel (WebAuthn)  >  Authenticator-App (TOTP)

Wer per WebAuthn eingerichtet ist, erfüllt also auch eine Regel, die „mindestens TOTP" verlangt. Alte Regeln mit der entfernten Stufe „E-Mail" wirken wie „Beliebig".

2FA-Pflicht-Regeln (Admin → Anmeldung & Sicherheit → 2FA & Sitzungen)

Statt 2FA nur pauschal an- oder auszuschalten, legst du gezielte Pflicht-Regeln an — für einzelne User, eine ganze Rolle, alle Träger einer bestimmten Permission, oder einen ganzen Tenant:

Feld Bedeutung
Name / Beschreibung frei wählbar
Selektor-Typ Einzelner User / Rolle / Permission / Tenant
Selektor-Wert konkreter User, konkrete Rolle, konkrete Permission oder konkreter Tenant
Faktor erforderlich Beliebig / Authenticator-App (TOTP) / Sicherheitsschlüssel (WebAuthn)
Grace-Period (Tage) wie lange ein betroffener User Zeit hat, bevor der Login blockiert wird
Aktiv Toggle

Beim Anlegen einer Regel zeigt eine Auswirkungs-Vorschau live an, wie viele aktive User die Regel betrifft, wie viele davon noch kein passendes 2FA eingerichtet haben (und damit in die Grace-Period fallen), und wie viele bereits mitten in einer laufenden Grace-Frist stecken.

Wenn mehrere Regeln denselben User treffen

Es gewinnt die strengste: nach Faktor-Stärke (WebAuthn > TOTP > Beliebig), bei gleicher Stärke die kürzere Grace-Period.

Ablauf für den betroffenen User

  1. Erste Anmeldung nach Aktivierung der Regel → Hinweis, dass 2FA eingerichtet werden muss, mit verbleibender Grace-Period
  2. Innerhalb der Frist eingerichtet → normaler Login weiter
  3. Frist verstrichen ohne Setup → Login wird blockiert, bis der geforderte Faktor eingerichtet ist. Der Einrichtungs-Dialog erscheint dann sofort; bei Passkey-Pflicht lässt sich der Passkey direkt dort registrieren. Dauert die Einrichtung länger als 15 Minuten, bestätigt man sich per Passwort neu und macht weiter.

Ausnahmen

Pro Regel lassen sich einzelne User als Ausnahme eintragen (mit optionalem internen Grund-Text, z. B. „Service-Account, kein interaktiver Login"). Ausgenommene User ignorieren genau diese Regel — andere, für sie ebenfalls passende Regeln gelten weiterhin.

Selbst-Deaktivierung gesperrt bei aktiver Pflicht

Ein User kann sein eigenes 2FA nicht abschalten, solange eine Pflicht-Regel auf ihn zutrifft (auch nicht während der Grace-Period). Ein Super-Admin kann im Notfall trotzdem zurücksetzen (siehe Admin-Override unten).

Admin-Override

Wenn ein User komplett ausgesperrt ist (kein Authenticator, kein Sicherheitsschlüssel, keine Backup-Codes mehr):

Admin → Benutzer & Rechte → Benutzer → betroffener Benutzer → 2FA zurücksetzen (Symbol in der Zeile oder Rechtsklick)

Entfernt Authenticator-App, alle Passkeys und alle Backup-Codes des Benutzers (ab v1.9.437 vollständig — vorher blieb ein Passkey des verlorenen Geräts gültig) und meldet alle seine Sitzungen ab. Vor dem Reset gibt es eine Rückfrage mit den Folgen, danach eine Rückmeldung, was entfernt wurde. Ein Audit-Eintrag wird geschrieben; der Benutzer richtet 2FA beim nächsten Login neu ein (und unterliegt dabei wieder jeder für ihn geltenden Pflicht-Regel). Das eigene 2FA lässt sich so nicht zurücksetzen (dafür Einstellungen → 2FA oder ein zweiter Super-Admin); SSO-Konten sind ausgenommen.

Fehlversuche und Anmeldung

  • Fünf falsche Codes sperren die 2FA-Anmeldung für 30 Minuten (beim Einrichten wie beim Login). Gleichzeitige Versuche zählen alle als Fehlversuch.
  • Ein TOTP-Code gilt genau einmal — derselbe Code bestätigt keine zweite Anmeldung (ab v1.9.437).
  • Das Code-Feld trägt einen Feldnamen, damit Passwort-Manager (Bitwarden & Co.) den Code automatisch einsetzen.
  • Antwortet der Server während der Code-Eingabe nicht, steht das so da — nicht „Code falsch".
  • Greift eine Pflicht-Regel, sperrt der Server alles bis zur Einrichtung; der Einrichtungs-Dialog erscheint in Benutzer- und Admin-Portal sofort.

Empfehlung

  • Super-Admin, Admin: Sicherheitsschlüssel oder mindestens Authenticator-App per Pflicht-Regel erzwingen
  • Operator: Authenticator-App empfohlen
  • Viewer: optional, je nach Datensensibilität des Tenants

Anschluss