From 0ec532296dbc98d359fb77d927be582aad22d0cc Mon Sep 17 00:00:00 2001 From: Florian Wilde Date: Sat, 15 Aug 2026 11:06:08 +0200 Subject: [PATCH] Sicherheitsbericht: warum es keine E-Mail-Verifizierung gibt MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Die Frage kam auf und die Antwort gehoert festgehalten, sonst stellt sie sich in einem halben Jahr wieder — dann ohne die Begruendung. Kurz: Es gibt keine Selbstregistrierung. Konten legt ein Administrator an, der die Adresse selbst eintraegt; eine Bestaetigungsmail wuerde also niemanden hereinlassen und niemanden fernhalten. Und weil es keinen Reset per E-Mail gibt, ist die unbestaetigte Adresse auch kein Uebernahmeweg. Noetig wuerde sie in dem Moment, in dem sich Leute selbst registrieren duerfen. Dazu das Zeitfenster der Ersteinrichtung ausdruecklich benannt: Das erste Konto entsteht ohne Legitimation und ist gleich Administrator. Dagegen hilft keine Verifizierung, sondern nur die Reihenfolge beim Aufsetzen — oder ein einmaliges Token, das jetzt auf der Roadmap steht. --- docs/roadmap.md | 9 +++++++++ docs/sicherheit.md | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+) diff --git a/docs/roadmap.md b/docs/roadmap.md index 4743523..176981d 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -152,6 +152,15 @@ Fenstern geschieht. ## Später denkbar +**Das Fenster der Ersteinrichtung schließen** · klein +Heute wird das erste Konto ohne jede Legitimation angelegt und ist gleich +Administrator. Wer die Anwendung öffentlich stellt, bevor er sein Konto +angelegt hat, kann sie an einen Fremden verlieren. Vorschlag: ein einmaliges +Token, das beim ersten Start ins Protokoll geschrieben wird und für die +Ersteinrichtung nötig ist. Klein im Aufwand — und das Erste, was zu tun ist, +falls die Anwendung je aus dem eigenen Netz herausgeht. Siehe +[sicherheit.md](sicherheit.md). + **Codes exportieren** · klein Eine CSV aller Codes einer Gruppe mit Name, Kurz-URL, Ziel und Scans — für die Übergabe an eine Druckerei oder die Ablage. diff --git a/docs/sicherheit.md b/docs/sicherheit.md index f527be2..62aa2b5 100644 --- a/docs/sicherheit.md +++ b/docs/sicherheit.md @@ -195,6 +195,44 @@ Konto nur bei **bestätigter** E-Mail-Adresse. Bewusst nicht umgesetzt, mit Begründung. +**E-Mail-Verifizierung.** Es gibt keine — und sie würde derzeit auch nichts +bringen. Die Anwendung kennt **keine Selbstregistrierung**: Es gibt nur +`login`, `setup`, `logout` und `change-password`. Konten legt ein +Administrator an, der die Adresse selbst einträgt. Eine Bestätigungsmail +würde also belegen, dass eine Adresse existiert, aber niemanden hereinlassen +und niemanden fernhalten. + +Dazu kommt: Es gibt **kein „Passwort vergessen" per E-Mail**. Zurücksetzen +kann nur ein Administrator unter Verwaltung → Benutzer. Damit ist die +unbestätigte Adresse auch kein Übernahmeweg — bei einem Reset per Mail wäre +sie einer. Die Adresse ist hier schlicht ein Anmeldename. + +Nötig würde die Verifizierung in dem Moment, in dem sich Leute selbst +registrieren dürfen. Dann allerdings zwingend, zusammen mit einem +SMTP-Versand, Ablauffristen für die Bestätigungslinks und einem Weg für +nicht zugestellte Mails. + +Zwei Stellen bleiben davon ohnehin unberührt, weil dort nicht der +Administrator die Adresse einträgt: + +- **Die Ersteinrichtung.** Wer zuerst kommt, wird Administrator. Dagegen hilft + keine Verifizierung, sondern nur, das Fenster zu schließen — siehe unten. +- **Die Anmeldung über einen Anbieter.** Dort bürgt der Anbieter für die + Adresse, und genau das prüft die Anwendung: Ein bestehendes Konto wird nur + bei `email_verified` verknüpft. + +**Das Zeitfenster der Ersteinrichtung.** Solange es keinen Benutzer gibt und +die Anmeldung eingeschaltet ist, wird das erste Konto ohne jede Legitimation +angelegt — und ist Administrator der Installation. Steht die Anwendung schon +öffentlich, bevor der Betreiber sein Konto anlegt, kann ein Fremder sie +übernehmen. + +Heute ist das eine Frage der Reihenfolge: erst starten, sofort das erste +Konto anlegen, dann erreichbar machen. Sauberer wäre ein einmaliges Token, +das beim ersten Start ins Protokoll geschrieben wird und für die +Ersteinrichtung nötig ist. Steht als Vorschlag in der +[Roadmap](roadmap.md). + **Vollständige Content-Security-Policy für Skripte.** Bräuchte Nonces durch die ganze Anwendung, weil Next.js eingebettete Skripte ausliefert. Der Nutzen wäre echt — es ist die zweite Verteidigungslinie gegen XSS —, aber halb