Der Sicherheitsfragebogen, und wo die Antworten stehen
Die Login-Fragen eines Sicherheitsfragebogens von Firmenkunden, beantwortet für EAuth, jede mit der Ziffer oder Seite dahinter, auch unser Nein.
Der erste grosse Kunde schickt eine Tabelle: eine Spalte für Ihre Antwort, eine Spalte für den Nachweis, und ein guter Teil der Zeilen dreht sich darum, wie sich Leute anmelden. Haben Sie das Login selbst gebaut, merken Sie hier, was Sie nicht gebaut haben. Nutzen Sie EAuth, haben die meisten Zeilen schon eine Antwort. Hier ist die Liste, jeweils mit der Ziffer der AGB von EAuth oder der Seite der Dokumentation, die die Antwort belegt. Die AGB sind versioniert, und jede Version bleibt veröffentlicht (14.3). Die Ziffer, die Sie zitieren, ändert sich also nicht unter Ihnen.
Wo werden die Daten gespeichert, und von wem?
Nur in der Schweiz und im Europäischen Wirtschaftsraum; das sagt der Auftragsverarbeitungsvertrag (Anhang B.14). Seit dem 3. Oktober 2026 läuft EAuth auf unserem eigenen Cluster: acht Server bei fünf Hosting-Providern in vier Ländern. Die drei Datenbankknoten stehen in Frankfurt, Nürnberg und Paris, die Anwendung läuft in Genf und Amsterdam, die zwei Edges, an denen TLS endet, stehen in Falkenstein und Amsterdam, und ein Wächter läuft in Genf. Vor ihnen sitzt kein Proxy eines Dritten. Mails, also Adressbestätigungen, Passwort-Resets und Einladungen, gehen über einen Mailzustelldienst hinaus, der die Adresse des Empfängers und den Text der Mail sieht.
Nachweis: Anhang B, der Auftragsverarbeitungsvertrag, der keine separate Unterschrift braucht. Die AGB verpflichten uns, einen neuen Unterauftragsverarbeiter 30 Tage vor seinem Start anzukündigen, und Sie dürfen kündigen, wenn Sie Einwände haben (8.5, B.8).
Wie werden Passwörter gespeichert?
Argon2id, 64 MiB Speicher, drei Iterationen, zwei Lanes, ein zufälliger Salt von 16 Byte pro Passwort, mit den Parametern in jedem gespeicherten Hash, damit sie später ohne Reset erhöht werden können. Refresh Tokens, Authorization Codes, API-Keys, Einladungen und Wiederherstellungscodes werden nur als SHA-256-Digests gespeichert, ebenso die Links, die eine Adresse bestätigen oder ein Passwort zurücksetzen. Die Schlüssel zum Signieren der Tokens sind mit AES-256-GCM verschlüsselt, unter einem Schlüssel, der nie in der Datenbank liegt. Nachweis: Anhang C.1 und die Tabelle auf der Sicherheitsseite, die zeigt, wie Credentials gespeichert werden.
Werden E-Mail-Adressen verifiziert?
Ja, bevor eine Anwendung das Konto sieht. Seit dem 3. Oktober 2026 bekommt keine Anwendung ein Konto, dessen Adresse nicht bestätigt ist. Wer sich registriert, wird auf dem Rückweg von einer Seite angehalten, die einen neuen Link schickt, und der Link führt zurück zum Login; eine Anwendung, die still fragt, mit prompt=none, bekommt interaction_required. Deshalb ist email_verified in jedem ID-Token aus einem Login true. Eine Adresse gilt als bestätigt durch den Link, durch einen an sie geschickten Passwort-Reset oder dadurch, dass der Identity Provider einer Organisation für sie bürgt. Nachweis: der Quickstart in der Dokumentation.
Gibt es Multi-Faktor-Authentifizierung? Ist sie für Administratoren Pflicht?
Verfügbar für alle Endnutzer: eine Authenticator-App mit Wiederherstellungscodes, und Passkeys. Ob Ihre Nutzer einen zweiten Faktor haben müssen, ist eine Einstellung Ihrer Anwendung, und eine Organisation kann ihn von ihren Mitgliedern verlangen. Bei uns muss jede Rolle, die Inhalte oder Credentials ändern kann, einen zweiten Faktor nutzen, und das Dashboard prüft das bei jeder Anfrage, nicht nur beim Login. Nachweis: Anhang C.2.
Wie werden Sessions geschützt?
Refresh Tokens rotieren bei jeder Nutzung, und ein rotiertes Token, das erneut vorgelegt wird, widerruft die ganze Kette, denn der legitime Client und ein Dieb können nicht beide das neuste haben. Authorization Codes leben sechzig Sekunden, funktionieren einmal und sind an den Client, die Redirect-URI und die PKCE-Challenge gebunden; PKCE mit S256 ist bei jeder Anfrage Pflicht. Access Tokens leben standardmässig 15 Minuten. Administrative Sessions werden bei jeder Anfrage gegen die Datenbank geprüft, ein Widerruf greift also sofort. Nachweis: Anhang C.3 und „What is enforced“ auf der Sicherheitsseite.
Wie schützen Sie sich gegen Brute Force?
Jeder Versuch wird gezählt, bevor er geprüft wird, pro Adresse und pro Konto, und die Zähler schlagen geschlossen fehl: Ist der Speicher dahinter nicht erreichbar, verweigert die Login-Seite, statt Anfragen durchzulassen. Fünf falsche Passwörter für ein Konto von einer Adresse oder zwanzig von überall pausieren es für bis zu fünfzehn Minuten. Bei Codes für den zweiten Faktor sind fünf falsche in fünfzehn Minuten und zwanzig pro Tag erlaubt. Ein Browser, der sich schon einmal bei dem Konto angemeldet hat, behält ein eigenes Kontingent, damit ein Angreifer den Besitzer nicht durch Raten aussperren kann. Nachweis: die Sicherheitsseite mit den Zahlen und Anhang C.4.
Gibt es einen Audit Trail?
Jede Änderung an den Credentials und Einstellungen einer Anwendung geht in ein Audit-Log, mit dem Konto und der E-Mail-Adresse der handelnden Person: das Anlegen einer Anwendung, das Rotieren ihres Secrets, Änderungen an ihren Einstellungen, Webhooks, das Team, Organisationen und ihr Single Sign-on, Importe und Exporte von Konten, gelöschte Konten und ein Konto, das per Single Sign-on übernommen wurde. Ein Datenbank-Trigger verweigert jede Änderung an einem Eintrag und verweigert das Löschen eines Eintrags, der jünger als zwölf Monate ist. Nachweis: Anhang C.5.
Wie lange bewahren Sie was auf?
Sessions und Refresh Tokens, bis sie ablaufen, und widerrufene so lange, bis sie abgelaufen wären, damit eine gestohlene Kopie, die später vorgelegt wird, noch erkannt wird. Authorization Codes eine Stunde über ihre sechzig Sekunden hinaus. Bestätigungs- und Reset-Links eine Woche, nachdem sie benutzt wurden oder abgelaufen sind, Einladungen 30 Tage. Das Log der Token-Anfragen und das Audit-Log zwölf Monate, Webhook-Zustellungen 30 Tage. Ein Konto wird 30 Tage nach der Anfrage seines Besitzers gelöscht; eines, bei dem sich 24 Monate lang niemand angemeldet hat, wird zweimal angeschrieben, im Abstand von 30 Tagen, und 30 Tage nach der zweiten Mail gelöscht, ausser es meldet sich jemand an. Ein Sweep entfernt einmal pro Stunde, was fällig ist. Nachweis: die Sicherheitsseite, „How long things are kept“, und die AGB, Ziffern 7.4 und 7.5.
Können wir gehen?
Ja, mit den Passwort-Hashes. Die Konsole exportiert eine Anwendung mit ihren Konten, Organisationen, Rollen, Webhooks und Einstellungen jederzeit als JSON, ohne uns zu fragen. Die Hashes liegen in ihrer ursprünglichen Form vor, Argon2id oder in dem Format, in dem sie importiert wurden, sodass Ihre Nutzer beim nächsten Provider ihre Passwörter behalten. Passkeys sind an die Login-Domain gebunden und können nicht umziehen, und die Secrets für den zweiten Faktor und die eigenen Secrets des Dienstes werden nicht exportiert; diese richten die Leute neu ein. Nachweis: AGB, Ziffern 7.2 und 7.3.
Was passiert, wenn EAuth ausfällt?
Bereits ausgestellte Access Tokens funktionieren weiter, bis sie ablaufen, standardmässig nach 15 Minuten, denn Ihre Anwendung prüft sie gegen unsere öffentlichen Schlüssel, ohne uns zu fragen. Danach scheitern Refreshes, und neue Logins scheitern, bis EAuth wieder da ist. Die AGB sagen das wörtlich (4.7), ebenso, dass es kein Service Level Agreement und keine Verfügbarkeitszusage gibt (4.1). Sind Minuten ohne Zugang nicht akzeptabel, können wir die Lebensdauer Ihrer Access Tokens erhöhen, oder Sie betreiben EAuth auf Ihren eigenen Servern (4.8, Abschnitt 11).
Was einen Ausfall unwahrscheinlicher macht: zwei Anwendungsknoten und zwei Edges in verschiedenen Ländern und drei Datenbankknoten mit synchroner Replikation, sodass ein Schreibvorgang erst bestätigt wird, wenn beide Replikate ihn haben. Die Statusseite unter status.elchi.dev zeigt den aktuellen Zustand; die gemessene Verfügbarkeit wird dort veröffentlicht, sobald ein ganzer Monat gemessen ist, und nicht vorher. Ein Ausfall von mehr als 30 Minuten bekommt in diesem Journal einen Bericht mit seiner Ursache (4.9).
Unterstützen Sie Single Sign-on für unseren Identity Provider?
SAML 2.0 pro Organisation, mit Anfragen per HTTP-Redirect, wie Entra ID, Okta und Google Workspace sie annehmen. Signaturen prüft eine gepflegte Library gegen das Zertifikat, das Sie konfiguriert haben, jede Antwort muss zu einer Anfrage aus demselben Browser gehören und wird einmal akzeptiert, und die bestätigte Adresse muss in der verifizierten Domain der Organisation liegen. Antworten, die ein Provider unaufgefordert schickt, werden abgewiesen. SCIM gibt es nicht: Konten entstehen beim ersten Login. Nachweis: docs.elchi.dev/enterprise-sso.
Gab es ein unabhängiges Sicherheitsaudit?
Nein. Die AGB sagen das (9.2, Anhang C.6), und wenn ein Audit stattfindet, wird das Ergebnis veröffentlicht, egal was es sagt. Einen SOC-2-Bericht oder ein ISO-27001-Zertifikat gibt es ebenfalls nicht. Braucht ein Fragebogen hier ein Ja, können wir es heute nicht geben, und ich möchte lieber, dass Sie das von uns erfahren als von dem Auditor, den Sie beauftragen.
Wie erfahren wir von Änderungen?
Eine wesentliche Änderung der AGB wird 30 Tage vorher per Mail und im Changelog angekündigt (14.1), ein neuer Unterauftragsverarbeiter 30 Tage vorher (8.5) und eine Änderung, die Integrationen bricht, 90 Tage vorher, ausser ein Sicherheitsproblem verlangt eine kürzere Frist (2.3). Jede Ankündigungsmail wird festgehalten, damit sich belegen lässt, dass die Frist eingehalten wurde. Der Umzug des Issuers von auth.elchi.dev auf eauth.me am 3. Oktober 2026 brauchte keine Ankündigung: An diesem Tag gehörte jede bei EAuth registrierte Anwendung Elchi Studios (2.4). Nachweis: diese Ziffern und docs.elchi.dev/changelog.
Was in die Nachweis-Spalte gehört
Die Ziffer mit der Version: „AGB von EAuth 1.7, Anhang C.1“. Ein Sicherheitsteam kann eine versionierte Ziffer gegen den veröffentlichten Text prüfen, und die Antwort bleibt für die zitierte Version wahr. Ein Link auf eine Feature-Seite beweist nur, dass jemand sie geschrieben hat.
Quellen
- EAuth Terms of Service, Elchi Studios, gelesen am
- Security, EAuth documentation, Elchi Studios, gelesen am
- RFC 9700: Best Current Practice for OAuth 2.0 Security, IETF, gelesen am
- RFC 7636: Proof Key for Code Exchange by OAuth Public Clients, IETF, gelesen am
- RFC 9207: OAuth 2.0 Authorization Server Issuer Identification, IETF, gelesen am
Geschrieben von Samuel Krauss, Founder. Abgelegt unter eauth, security, enterprise, gdpr.
Übersetzt aus dem Englischen. Zum englischen Original