Zum Inhalt springen

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.

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.

  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.

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

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

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).

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).

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.

Manche Aktionen sind sensibel genug, dass eine gültige Session allein nicht ausreicht — Orimora verlangt unmittelbar davor eine erneute Bestätigung des zweiten Faktors, auch wenn du bereits angemeldet bist. Das begrenzt den Schaden einer geliehenen oder gekaperten Session.

Step-Up schützt unter anderem: das Ändern deiner E-Mail, das Übertragen des Arbeitsbereich-Eigentums, das Wiederherstellen der E-Mail eines Mitglieds, das Umschalten der team-erzwungenen MFA, das Löschen des Arbeitsbereichs sowie das Verwalten von API-Keys / Entwickler-Einstellungen. Bei Bedarf wirst du nach einem Passkey oder einem aktuellen TOTP-/Backup-Code gefragt; die erneute Bestätigung bleibt für ein kurzes Zeitfenster gültig, sodass eine Reihe von Aktionen nicht wiederholt nachfragt.

AktionWo
E-Mail ändernEinstellungen → Profil — doppelte Bestätigung (siehe unten)
Konto löschenEinstellungen → Profil — bestätigt per signiertem Link
API-Keys verwaltenEinstellungen → Entwickler — siehe REST-API
Autorisierte OAuth-AppsEinstellungen → Entwickler → Autorisierte Apps — siehe MCP

Die Änderung deiner E-Mail-Adresse unter Einstellungen → Profil erfordert die Zustimmung beider Postfächer, bevor sich etwas ändert — eine gekaperte Session allein kann dein Konto nicht an die Adresse eines Angreifers umbinden:

  1. Du gibst die neue Adresse ein. Orimora sendet zwei E-Mails:
    • einen Autorisierungs-Link an deine aktuelle Adresse (zugleich Frühwarnung, mit einem „das war ich nicht — ablehnen”-Link), und
    • einen Verifizierungs-Link an die neue Adresse (als Besitznachweis).
  2. Die Änderung wird erst wirksam, wenn beide Links bestätigt sind (in beliebiger Reihenfolge). Bis dahin bleibt deine Adresse unverändert.
  3. Nach der Umstellung geht eine Sicherheitsbenachrichtigung an deine vorherige Adresse.

Wenn du einen zweiten Faktor hast, ist die Anforderung Step-Up-geschützt. Jeder Link ist einmalig nutzbar und nach 24 Stunden abgelaufen.

Orimora hat zwei unterschiedliche destruktive Abläufe. Beide sind unwiderruflich und bewusst schwer versehentlich auszulösen — sie sind nicht dasselbe wie ein Dokument in den Papierkorb zu legen.

Unter Einstellungen → Profil ist das Löschen deines Kontos ein zweistufiger Ablauf:

  1. Du gibst einen Bestätigungssatz ein; daraufhin wird ein signierter Bestätigungslink an deine aktuelle E-Mail-Adresse gesendet.
  2. Erst durch das Öffnen dieses Links (Nachweis, dass du das Postfach kontrollierst) wird die Löschung ausgeführt.

Das schützt dich vor einem einzelnen Fehlklick — und davor, dass eine Phishing-Seite die Anfrage in deinem Namen abschickt, denn ein versehentlicher Klick kann den E-Mail-Schritt nicht abschließen. Auch Link-Vorschau-Bots sind unkritisch: Der Link zeigt nur eine Bestätigungsseite, er löscht nichts, bevor du aktiv bestätigst.

Nach der Bestätigung wird dein Konto gelöscht, nicht nur verborgen: Name und E-Mail werden anonymisiert, sämtliche deiner Sessions werden widerrufen, deine API-Keys und Anmeldedaten werden ungültig, und jede laufende Kollaborations-Verbindung wird getrennt. Das ist ein echter DSGVO-Pfad zum Recht auf Löschung.

Unter Einstellungen → Arbeitsbereich → Gefahrenzone kann ein Admin mit Bearbeitungsrechten den gesamten Arbeitsbereich dauerhaft löschen. Zur Bestätigung musst du den Namen des Arbeitsbereichs eingeben und — sofern du einen zweiten Faktor hast — diesen erneut bestätigen (ein aktueller TOTP-/Backup-Code oder ein Passkey), derselbe Step-up-Schutz wie bei anderen folgenschweren Aktionen.

Das Löschen des Arbeitsbereichs entfernt alle seine Daten dauerhaft — Dokumente, Sammlungen und Mitgliederdaten — in einem einzigen atomaren Vorgang (er gelingt vollständig oder ändert nichts). Jedes Mitglied wird sofort abgemeldet (alle Sessions werden widerrufen) und vom Arbeitsbereich getrennt; die einzelnen Konten bleiben bestehen, sodass sie einem anderen Arbeitsbereich beitreten oder einen neuen erstellen können. Die Löschung wird im Audit-Log festgehalten, bevor die Daten entfernt werden.

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.