Sicherheitsbericht: warum es keine E-Mail-Verifizierung gibt

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

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

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