Sicherheit & Passkeys

Orimora ist passwortlos konzipiert — du meldest dich per Magic-Link oder SSO-Provider an und kannst Passkeys für schnelle, phishing-resistente Logins hinzufügen. Diese Seite behandelt die Konto-Sicherheitseinstellungen unter Einstellungen → Sicherheit und verwandte Bereiche.

Passkeys (WebAuthn)

Ein Passkey ist ein kryptografischer Zugang, der auf deinem Gerät gespeichert ist (Touch ID / Face ID / Windows Hello / ein Hardware-Sicherheitsschlüssel). Er meldet dich ohne Passwort oder E-Mail-Umweg an und ist nicht phishbar.

Passkey hinzufügen

1. Gehe zu Einstellungen → Sicherheit.
2. Klicke Passkey hinzufügen, optional benennen (z. B. „MacBook Touch ID”).
3. Schließe die Biometrie-/Sicherheitsschlüssel-Abfrage deines Geräts ab.

Der Passkey erscheint in der Liste mit Name und Erstelldatum. Lege einen pro regelmäßig genutztem Gerät an.

Mit einem Passkey anmelden

Wähle im Login-Screen Mit einem Passkey anmelden und schließe die Geräte-Abfrage ab. Weder E-Mail noch Passwort sind beteiligt.

Verwalten / entfernen

Jeder Passkey kann aus der Liste umbenannt oder gelöscht werden. Einen Passkey zu entfernen verhindert sofort seine Nutzung zur Anmeldung.

Tipp

Registriere einen Passkey auf mehr als einem Gerät (oder einem sicher verwahrten Hardware-Schlüssel). Hast du nur einen Passkey und verlierst dieses Gerät, weiche auf den Magic-Link-/SSO-Login aus, den du ursprünglich genutzt hast.

Sessions

Sessions sind cookie-basiert und rotieren beim Login. Zwei Timeouts gelten:

• Eine absolute Lebensdauer (30 Tage).
• Ein Idle-Timeout — eine Session wird nach SESSION_IDLE_TIMEOUT_DAYS (Standard 7) Inaktivität ungültig, auch innerhalb des absoluten Fensters. Betreiber können ihn anpassen oder deaktivieren (siehe Konfiguration).

Zwei-Faktor-Authentifizierung (TOTP)

Magic-Link-Nutzer können unter Einstellungen → Sicherheit einen zeitbasierten Einmalcode (RFC 6238) aus einer Authenticator-App (Google Authenticator, 1Password, Aegis, …) als zweiten Faktor hinzufügen.

• Einrichten: QR-Code scannen (oder Schlüssel manuell eingeben), dann einen 6-stelligen Code bestätigen. Es werden einmalig 10 Single-Use-Backup-Codes angezeigt — sicher aufbewahren.
• Beim Login: nach dem Magic-Link wird ein Code abgefragt, bevor die Session erstellt wird. Ohne Authenticator funktioniert ein Backup-Code.
• Passkeys umgehen es immer; SSO nur, wenn der IdP MFA assertet: ein Passkey ist bereits ein starker Faktor. Bei OIDC/SAML wird die MFA-Anforderung nur dann an den Identity Provider delegiert, wenn dessen Assertion belegt, dass MFA durchgeführt wurde (ein amr von mfa/ein anerkannter zweiter Faktor, oder ein MFA-AuthnContextClassRef). Ein Single-Factor-SSO-Login zählt nicht und fällt auf die lokale Faktor-Pflicht zurück.
• Deaktivieren / Backup-Codes erneuern erfordert einen aktuellen Code (Besitznachweis). Ist ein Mitglied ausgesperrt (Gerät + Backup-Codes verloren), kann ein Team-Admin dessen MFA zurücksetzen (auditiert), sodass neu eingerichtet werden kann.

Secrets sind at-rest verschlüsselt, Backup-Codes gehasht und Single-Use, Codes sind innerhalb ihres Fensters nicht wiederholbar, und die Verifikation ist rate-limitiert.

Step-up bei sensiblen Aktionen: Änderungen an der SSO-Konfiguration, das Erstellen eines SCIM- oder API-Tokens, das Hinzufügen eines Mitglieds zu einer Systemgruppe (z. B. Admins) und ähnliche kritische Aktionen verlangen eine erneute Faktor-Bestätigung — ein aktueller TOTP-/Backup-Code oder ein Passkey — selbst in einer aktiven Session, als Schutz davor, dass eine gekaperte Session irreversible Änderungen vornimmt. Nutzer ohne zweiten Faktor werden nicht abgefragt (kein Lockout).

MFA für das ganze Team erzwingen

Ein Workspace-Admin kann unter Einstellungen → Workspace → Zwei-Faktor-Authentifizierung für jedes Mitglied einen zweiten Faktor verpflichtend machen. Solange aktiviert:

• Mitglieder ohne TOTP-Authenticator oder Passkey landen auf einer einmaligen Einrichtungsseite und können den Workspace erst nutzen, wenn sie einen Faktor angelegt haben.
• SSO-Logins sind nur ausgenommen, wenn der IdP MFA assertet — meldet sich ein Mitglied über OIDC/SAML an und belegt die Assertion Multi-Faktor (amr: ['mfa']/ein anerkannter zweiter Faktor, oder ein MFA-AuthnContextClassRef wie die Multi-Auth-Klasse von Microsoft Entra), wird MFA an den IdP delegiert und es wird kein lokaler Faktor verlangt. Ein Single-Factor-SSO-Login gilt als noch-nicht-MFA, und das Mitglied landet wie alle anderen auf der lokalen Einrichtungsseite. Um sich auf diese Ausnahme zu verlassen, konfiguriere deinen IdP so, dass er MFA assertet.
• Zum Aktivieren musst du selbst bereits einen zweiten Faktor haben (kein Self-Lockout); die Änderung ist step-up-geschützt und wird auditiert. Verliert ein Mitglied seinen Faktor, kann ein Admin dessen MFA zurücksetzen, damit es sich neu einrichten kann.

Konto-Steuerung

Aktion	Wo
E-Mail ändern	Einstellungen → Profil — bestätigt per signiertem E-Mail-Link
Konto löschen	Einstellungen → Profil — bestätigt per signiertem Link
API-Keys verwalten	Einstellungen → Entwickler — siehe REST-API
Autorisierte OAuth-Apps	Einstellungen → Entwickler → Autorisierte Apps — siehe MCP

Härtung für Betreiber

Self-Hoster sollten zusätzlich prüfen: At-Rest-Verschlüsselungsschlüssel (LLM_ENCRYPTION_KEY, PUBLISHING_ENCRYPTION_KEY), die CORS-Allowlists (API_CORS_ALLOWED_ORIGINS, MCP_OAUTH_CORS_ORIGINS) und das Audit-Log unter Einstellungen → Admin → Audit. Alles in der Konfiguration behandelt.