Ich habe DayBlock angegriffen: das Sicherheits-Audit zum Nachlesen

DayBlock verspricht viel: Deine Einträge, Notizen und dein Tagebuch werden auf deinem Gerät verschlüsselt, der Server sieht nur Zeichensalat. So ein Versprechen ist nichts wert, wenn es niemand überprüft. Darum habe ich DayBlock im Oktober 2026 einem vollständigen internen Sicherheits-Audit unterzogen – jede Tür einmal angefasst, jedes Schloss einmal gerüttelt. Hier steht, was ich geprüft habe, was ich gefunden habe und was ich sofort verbessert habe. Den ausführlichen Bericht gibt es als PDF zum Herunterladen, geschrieben für alle, nicht nur für Fachleute.

Warum ein Audit – und warum öffentlich

Sicherheit ist bei DayBlock kein Anhängsel, sondern der Grund, warum es DayBlock so gibt, wie es DayBlock gibt: Ein Tagesplaner weiß, wann du zum Arzt gehst und wie es dir an einem Dienstagabend ging. Im Bedrohungsmodell habe ich schon offengelegt, wie DayBlock gebaut ist und wo die Grenzen liegen. Ein Audit ist der nächste Schritt: Statt zu beschreiben, wie es sein soll, prüfe ich, ob es wirklich so ist.

Und warum öffentlich? Aus demselben Grund wie beim Bedrohungsmodell: Gute Sicherheit hängt nicht davon ab, dass niemand weiß, wie sie gebaut ist. Wenn ich die Ergebnisse veröffentliche, kannst du sie nachlesen, mit anderen Diensten vergleichen – und mich beim Wort nehmen. Eine Regel gilt dabei immer: Veröffentlicht wird nur, was bereits behoben ist. Fände ich eine offene Lücke, würde ich sie zuerst schließen und erst danach darüber schreiben.

Was ich geprüft habe

Das Audit ging einmal durch alles, was zwischen deinem Browser und der Datenbank liegt:

• Anmeldung und Konto: das Anmeldeverfahren, bei dem dein Passwort dein Gerät nie verlässt, Sitzungen und ihre Cookies, die Wiederherstellung mit den 24 Wörtern, das Abmelden und das Löschen des Kontos.
• Verschlüsselung: die Schlüssel, die auf deinem Gerät entstehen, das Einwickeln des Hauptschlüssels, die Verschlüsselung jedes Datensatzes und die Frage, ob der Server wirklich nie Klartext sieht.
• Abgleich zwischen Geräten: ob sich beim Hin- und Herschicken der verschlüsselten Umschläge nichts einschleusen oder vertauschen lässt.
• Gruppen und Teilen: private Gruppen, deren Schlüssel nur im Einladungslink steht, öffentliche Gruppen und die Melde-Funktion.
• Kalender abonnieren: Wenn DayBlock einen fremden Kalender für dich abruft, darf das kein Hintertürchen ins eigene Netz sein. Genau diese Angriffsklasse – ein Server, der sich zu beliebigen Adressen schicken lässt – habe ich gezielt durchgespielt.
• Magazin und Redaktion: ob sich über Artikel fremder Code in die Seite schmuggeln lässt.
• Der Rest: E-Mails, Begrenzungen gegen Durchprobieren von Passwörtern, Sicherheits-Kopfzeilen des Browsers, der lokale Speicher der App und alle verwendeten Bibliotheken (automatische Prüfung auf bekannte Schwachstellen).

Ehrlich dazugesagt: Das war ein internes Audit – ich habe es selbst durchgeführt, systematisch und mit Unterstützung von KI-Analysewerkzeugen. Es ersetzt nicht die unabhängige externe Prüfung durch Fachleute. Die bleibt Pflicht, bevor DayBlock für alle öffnet, und ihr Bericht wird ebenfalls veröffentlicht.

Das Ergebnis in einem Satz

Ich habe keine kritische Lücke gefunden – keinen Weg, an verschlüsselte Inhalte, Passwörter oder fremde Konten zu kommen. Gefunden habe ich drei Stellen, an denen DayBlock vorsichtiger sein kann, als es war. Alle drei habe ich noch während des Audits verbessert.

Drei Dinge habe ich sofort verbessert

1. Der Browser besteht jetzt dauerhaft auf einer verschlüsselten Verbindung. DayBlock war immer nur über eine verschlüsselte Verbindung erreichbar. Neu ist eine Kopfzeile, mit der sich dein Browser das für ein ganzes Jahr merkt: Er versucht danach gar nicht mehr erst, eine unverschlüsselte Verbindung aufzubauen – selbst wenn jemand im selben WLAN ihn dorthin umleiten wollte.
2. Absenderangaben wird weniger geglaubt. Anfragen erreichen DayBlock über eine vorgeschaltete Verteilstation, die dem Server mitteilt, von welcher Adresse eine Anfrage kommt. Dieser Angabe vertraut der Server jetzt nur noch genau eine Station weit. Vorher hätte – in einer ungünstigen Konstellation – jemand eine erfundene Absenderadresse mitschicken und so die Begrenzungen austricksen können, die das Durchprobieren von Passwörtern bremsen. Die eingesetzte Verteilstation verwirft solche erfundenen Angaben zwar selbst, aber Sicherheit soll nicht an einer einzigen Stelle hängen.
3. Auch ein Nebendienst der Testumgebung bekommt die strengen Kopfzeilen. Ein kleiner Dienst, den es nur in der internen Testumgebung gibt, lief ohne die Sicherheits-Kopfzeilen, die Website und App längst haben. Das war kein Risiko für Nutzerdaten – zur Testumgebung gibt es nur Spieldaten –, aber Einheitlichkeit ist hier die bessere Gewohnheit.

Was dem Test standgehalten hat

Ein Audit findet nicht nur Schwächen, es bestätigt auch Stärken. Diese Punkte haben sich bewährt:

• Das Passwort bleibt bei dir. Auch beim genauen Hinsehen gilt: Es verlässt dein Gerät nie, der Server kann es nicht sehen und nicht aufschreiben.
• Verschlüsselte Datensätze lassen sich nicht vertauschen. Jeder Datensatz ist an seine eigene Kennung gebunden. Wer in der Datenbank Umschläge umsortiert, erzeugt nur Fehlermeldungen, keine falschen Einträge.
• Der Kalender-Abruf ist kein Hintertürchen. DayBlock prüft bei jedem Abruf, dass die Zieladresse öffentlich ist – auch nach Umleitungen und auch dann, wenn ein Angreifer die Namensauflösung austricksen will.
• Artikel können keinen Code einschleusen. Texte aus der Redaktion werden Zeichen für Zeichen entschärft, bevor sie zur Webseite werden; Links sind auf harmlose Formen begrenzt.
• Die Datenbank bekommt keine Befehle von außen. Alle Datenbankzugriffe sind so gebaut, dass Eingaben immer Daten bleiben und nie zu Befehlen werden können.
• Fremde Seiten können nicht in deinem Namen handeln. Ändernde Anfragen brauchen eine Kennung, die nur die echte App setzen kann, und die Sitzung reist nie zu fremden Seiten mit.
• Die Bibliotheken sind sauber. Die automatische Prüfung aller verwendeten Bibliotheken meldet keine bekannte Schwachstelle.

Ehrliche Grenzen: was das Audit nicht ändert

Ein paar Dinge bleiben, wie sie im Bedrohungsmodell stehen – ein Audit zaubert sie nicht weg:

• Der Server liefert den Code. Das Grundproblem jeder verschlüsselten Web-App: Wer den Server kontrolliert, könnte veränderten Code ausliefern. Geplant dagegen: nachprüfbare Fassungen mit veröffentlichten Prüfsummen und später Apps mit eingebautem Code.
• Zwei-Faktor-Anmeldung fehlt noch. Ein kurzes oder wiederverwendetes Passwort bleibt bis dahin das größte Risiko – das kannst nur du klein halten.
• Wer registriert ist, lässt sich erraten. Wie bei fast jedem Dienst verrät der Versuch, ein Konto mit einer fremden E-Mail-Adresse anzulegen, ob es dieses Konto schon gibt. Die Wiederherstellung und das erneute Senden der Bestätigung antworten dagegen bewusst neutral.
• Die externe Prüfung steht aus. Dieses Audit war meins. Vor dem öffentlichen Start prüfen Externe – und deren Bericht erscheint genauso offen wie dieser.

Der Bericht als PDF

Den vollständigen Bericht habe ich als PDF aufgeschrieben – bewusst so, dass ihn jeder verstehen kann: was geprüft wurde, was gefunden wurde, was verbessert wurde und was offen bleibt. Du kannst ihn herunterladen, weitergeben und mich daran messen:

Sicherheitsbericht Oktober 2026 (PDF, deutsch)
Security report October 2026 (PDF, English)

Jedes weitere Audit bekommt einen neuen, datierten Bericht; die alten bleiben erreichbar. So kannst du über die Zeit verfolgen, wie DayBlock sicherer wird.

Eine Schwachstelle gefunden?

Dann schreib mir bitte an hallo@dayblock.de mit dem Betreff „Sicherheit“. Beschreib, was du gefunden hast und wie es sich nachvollziehen lässt. Ich antworte, behebe die Lücke so schnell ich kann – und nenne dich danach gern mit Namen, wenn du das möchtest. Bitte teste nur mit deinem eigenen Konto und greif nicht auf Daten anderer zu.