Zum Inhalt springen

Sicherheit

Sicherheitsarchitektur und Bedrohungsmodell

Notenz verwendet zwei grundlegend unterschiedliche Verschlüsselungsstufen. Normale Tresor-Einträge werden serverseitig verschlüsselt, damit wir sie automatisch zustellen können. Die Sealed Vault- und Shared-Key-Einträge von Guardian werden vollständig in deinem Browser verschlüsselt: Den Schlüssel haben wir nie. Diese Seite erklärt genau, was jede Stufe tut, was wir lesen können und was nicht, und wo die ehrlichen Grenzen liegen.

Die Kurzversion, einfach erklärt

  • 🔐 Deine Notizen werden verschlüsselt, sobald sie uns erreichen. Wir speichern verschlüsselte Daten, nicht lesbaren Text. Unsere Mitarbeiter lesen ihn nicht.
  • 🔑 Deine Empfänger können es nur lesen, wenn dein Tresor ausgeführt wird. Nicht vorher.
  • 🤔 Könnte Notenz es technisch entsperren? Für den Standard-Tresor ja: wir verfügen über den Schlüssel, der für die automatische Bereitstellung erforderlich ist, wenn du es nicht kannst. Lies, warum und wie sich Sealed Vault unterscheidet →
  • 🌐 Deine Verbindung ist immer sicher. Wie beim Online-Banking ist das Vorhängeschloss in deinem Browser immer aktiviert.
  • 🪪 Dein Passwort wird niemals so gespeichert, wie es ist. Wir speichern einen unidirektionalen mathematischen Fingerabdruck davon. Auch wenn unsere Datenbank gestohlen würde, bliebe dein Passwort sicher.
  • 🚨 Hast du ein Problem gefunden? E-Mail [email protected] und wir werden es schnell beheben.

Zweistufiges Verschlüsselungsmodell

Stufe 1: Normale Tresor-Einträge

Alle normalen Einträge, die keine Sealed-Vault- oder Shared-Key-Einträge sind. Das umfasst den Großteil des Tresorinhalts.

  • Textnotizen: Fernet (AES-128-CBC + HMAC-SHA256), serverseitig
  • Dateien: AES-256-GCM, blockweises Streaming, serverseitig
  • Schlüssel bei: Notenz (für die automatische Zustellung erforderlich)
Notenz kann diese Einträge technisch entschlüsseln. Diese Fähigkeit wird benötigt, um sie automatisch zuzustellen, wenn du aufhörst einzuchecken.

Stufe 2: Zero-Knowledge (nur Guardian)

Sealed Vault (Private Secrets) und Shared-Key-Tresor-Einträge. Vollständig in deinem Browser verschlüsselt, bevor sie hochgeladen werden.

  • Sealed Vault: PBKDF2-SHA256, 600.000 Iterationen, AES-256-GCM
  • Shared-Key / Eintragsspezifische Phrase: PBKDF2-SHA256, 100.000 Iterationen, AES-256-GCM
  • Schlüssel bei: Nur dir. Notenz speichert ausschließlich Geheimtext.
Notenz kann diese Einträge nicht lesen. Selbst ein vollständiger Server-Einbruch legt ihren Klartext nicht offen. Kompromiss: Ein vergessener Schlüssel bedeutet unwiderruflichen Verlust.

Was Notenz sehen kann und was nicht

Notenz kann lesen

  • Eintragstitel (unverschlüsselt gespeichert, um dir die Organisation zu erleichtern)
  • Inhalt normaler Tresor-Einträge (serverseitiger Schlüssel, für die Zustellung erforderlich)
  • Normale Tresor-Dateien (zum Zeitpunkt der Zustellung entschlüsselt)
  • Deine E-Mail-Adresse, dein Check-in-Zeitplan und deine Empfängerliste
  • Metadaten: wann Einträge erstellt, abgerufen und zugestellt wurden

Notenz kann nicht lesen

  • Sealed-Vault-Geheimnisse (clientseitiger Schlüssel, niemals übertragen)
  • Inhalt von Shared-Key-Tresor-Einträgen (clientseitiger Schlüssel, niemals übertragen)
  • Eintragsspezifisch verschlüsselter Inhalt (clientseitiger Schlüssel)
  • Dein Kontopasswort (nur als PBKDF2-SHA256-Hash gespeichert)
  • Zwei-Faktor-Codes (nur als HMAC-SHA256-Prüfsumme gespeichert)

Bedrohungsmodell: Wogegen wir schützen und wogegen nicht

Wir schützen vor

  • ✓ Wird nur die Datenbank gestohlen: Deine Dokumente und Notizen sind verschlüsselt gespeichert.
  • ✓ Server-Einbruch bei Stufe-2-Einträgen: Sealed-Vault- und Shared-Key-Geheimtext kann selbst bei vollem Server-Zugriff nicht entschlüsselt werden, da der Schlüssel unsere Server nie erreicht.
  • ✓ Versehentlicher Mitarbeiterzugriff: Kein Admin-Bereich zeigt den entschlüsselten Inhalt von Notizen und Dateien
  • ✓ Brute-Force auf Kontopasswörter: PBKDF2-SHA256-Streckung, ratenbegrenzter Login
  • ✓ Token-Raten: Alle öffentlichen Links sind ratenbegrenzt und kryptografisch zufällig.
  • ✓ Session-Fixierung und CSRF: CSRF-Tokens auf allen zustandsändernden Endpunkten, sichere HttpOnly-Cookies

Wir schützen NICHT vor (ehrliche Grenzen)

  • ✗ Vollständige Kompromittierung des Live-Servers (Stufe 1): Ein Angreifer mit Zugriff auf Datenbank und Hauptschlüssel kann normale Tresor-Einträge entschlüsseln. Wir mindern dieses Risiko durch Schlüsselrotation, es bleibt jedoch ein theoretisches Risiko.
  • ✗ Normale Tresor-Einträge sind gegenüber Empfängern nicht Ende-zu-Ende-verschlüsselt: Sie werden von unserem Server entschlüsselt und per E-Mail versendet. TLS schützt die E-Mail beim Transport, wir sehen jedoch den Klartext zum Zeitpunkt der Zustellung.
  • ✗ Gerätekompromittierung: Wenn dein Gerät kompromittiert ist, kann eine im Browser eingegebene Stufe-2-Passphrase vor der Verschlüsselung abgefangen werden. Keine serverseitige Maßnahme kann dies verhindern.
  • ✗ Vergessene Stufe-2-Passphrase: Sealed-Vault- und Shared-Key-Einträge werden dauerhaft unwiederbringlich. Es gibt keinen serverseitigen Zurücksetzungspfad.
  • ✗ Metadaten: Auch bei Stufe-2-Einträgen speichern wir Bezeichnungen (Titel), Zeitstempel und Zustelladressen. Stufe 2 verbirgt den Inhalt, nicht die Existenz eines Eintrags.

Verschlüsselung im Ruhezustand

Textnotizen werden vor dem Speichern serverseitig mit Fernet (AES-128-CBC + HMAC-SHA256) verschlüsselt. Dateien verwenden Streaming AES-256-GCM (4-MB-Blöcke, eindeutiger Nonce pro Block). Der Hauptschlüssel wird getrennt vom Inhalt gespeichert; eine gestohlene Datenbank allein ergibt nur unlesbaren Geheimtext.

  • ✓ Textnotizen: Fernet (AES-128-CBC + HMAC-SHA256), serverseitiger Schlüssel
  • ✓ Dateien: AES-256-GCM-Streaming (eindeutiger 12-Byte-Nonce pro Block), serverseitiger Schlüssel
  • ✓ Hauptschlüssel getrennt von der Datenbank gespeichert; Schlüsselrotations-Werkzeuge verfügbar
  • ✓ Klartext wird nie aufbewahrt: Uploads werden direkt nach dem Eingang verschlüsselt und die temporäre Upload-Kopie wird gelöscht

Deine Inhalte werden verschlüsselt gespeichert

Deine Notizen und Dateien werden verschlüsselt gespeichert. Titel werden unverschlüsselt gespeichert (damit du den Überblick behältst), der Inhalt selbst wird jedoch verschlüsselt gespeichert. Unsere Server entschlüsseln normale Einträge, wenn du sie nutzt und um deinen Tresor zuzustellen, wenn es Zeit ist. Wenn du einen Vertrag hochlädst oder Notenz einen Brief oder ein Dokument lesen lässt, wird dessen Inhalt zur KI-Verarbeitung an Anthropic (USA) gesendet. Sealed-Vault- und Shared-Key-Einträge können wir nicht lesen. Siehe unten für das Gesamtbild.

  • ✓ Kein Klartext in Anwendungsprotokollen
  • ✓ Der Inhalt von Notizen und Dateien in deinem Tresor liegt auch in Datenbanksicherungen verschlüsselt
  • ✓ Kein Admin-Bereich zeigt den entschlüsselten Inhalt deiner Notizen und Dateien

Zwei-Personen-Geheimnis (geteilte Lieferung)

Für besonders sensible Gegenstände kannst du dich für unseren Zwei-Personen-Geheimmodus entscheiden. Wenn dein Tresor ausgeführt wird, wird das Geheimnis mathematisch in einen separaten Anteil für jeden deiner ausgewählten Empfänger (zwei oder mehr) aufgeteilt, wobei eine bewährte Technik zum Teilen von Geheimnissen zum Einsatz kommt. Zwei beliebige dieser Anteile reichen aus, um die ursprüngliche Nachricht zu rekonstruieren, aber ein einzelner Anteil allein verrät absolut nichts darüber.

  • ✓ Mit nur einer Freigabe kryptografisch nicht lesbar
  • ✓ Beliebige 2 von N Anteilen rekonstruieren das Geheimnis. Selbst wenn du den Kontakt zu einem vertrauenswürdigen Kontakt verlierst, können zwei beliebige andere es trotzdem entsperren
  • ✓ Anteile werden nach der Generierung nie zusammen gespeichert

Textnotizen

Der Notiztext selbst wird unter deinen Empfängern aufgeteilt. Zwei beliebige von ihnen fügen ihre Anteile in notenz.com/reconstruct/ ein und die ursprüngliche Nachricht wird vollständig in ihrem Browser neu erstellt. Es wird nichts an Notenz zurückgesendet.

  • ✓ Die Rekonstruktion erfolgt zu 100 % clientseitig, ohne Server-Roundtrip
  • ✓ Notenz speichert niemals den rekonstruierten Klartext

Dateien

Bei Dateien teilt Notenz die auf Zugang auf die Datei, nicht auf die Datei selbst. Ein kurzes Zufallszugriffstoken wird nach demselben Schema unter deinen Empfängern aufgeteilt. Wenn zwei von ihnen ihre Anteile auf der Rekonstruktionsseite kombinieren, verwendet der Browser das neu zusammengesetzte Token, um die Datei anzufordern. Notenz entschlüsselt sie serverseitig und streamt sie als direkten Download. Kein einzelner Anteil allein kann das Token erzeugen.

  • ✓ Nur das Zugriffstoken wird aufgeteilt. Es wird keine Binärdatei per E-Mail versendet
  • ✓ Datei wird im Ruhezustand mit AES-256-GCM-Verschlüsselung gespeichert; erst im Moment des Downloads entschlüsselt
  • ✓ Download-Link gültig für 90 Tage; läuft danach automatisch ab

Ehrliche Einschränkung, der Transparenz halber

Anders als bei Shared-Key-Elementen hält Notenz den Inhalt deines Zwei-Personen-Geheimnisses tatsächlich selbst: Wir speichern die aufgeteilten Anteile bei uns, bis dein Tresor ausgeführt wird, damit wir sie kombinieren und zustellen können. Das bedeutet, es ist nicht wissensfrei, und ein persönlicher Datenexport (Einstellungen → Meine Daten herunterladen) enthält diesen Inhalt in lesbarer Form. Wenn du eine Garantie brauchst, dass selbst Notenz den Inhalt nicht lesen kann, verwende stattdessen ein Shared-Key-Vault-Element.

Schutz für geteilte Links

Zustellungslinks, Split-Secret-Share-Links, Empfängerbestätigungslinks und Rückruflinks sind alle vor automatisiertem Erraten und Missbrauch geschützt. Wenn ein einzelner Link ungewöhnlich viele Anfragen von derselben Quelle erhält, werden weitere Anfragen vorübergehend blockiert und der Tresorbesitzer wird per E-Mail benachrichtigt, damit er das Prüfprotokoll seines Kontos überprüfen kann.

  • ✓ Ratenbegrenzung für alle tokenbasierten öffentlichen Links (Zustellungs-, Split-Secret-, Bestätigungs- und Rückrufseiten)
  • ✓ Der Tresorbesitzer erhält eine einmalige E-Mail-Benachrichtigung, wenn zum ersten Mal auf einen Liefer- oder Split-Secret-Link zugegriffen wird
  • ✓ Verdächtige Aktivitäten werden im Prüfprotokoll deines Kontos aufgezeichnet

Ehrliche Antwort: Konnte Notenz meinen Tresor lesen?

Für deinen Standard-Tresor (Einträge außerhalb von Sealed Vault und Shared-Key): technisch gesehen ja. Hier erfährst du im Klartext, warum.

Die ganze Aufgabe von Notenz besteht darin, deinen Tresor automatisch zuzustellen, wenn du aufhörst einzuchecken, auch wenn du selbst kein Passwort mehr eingeben kannst. Damit das funktioniert, muss unser System in der Lage sein, deinen Tresor selbstständig und ohne dich zu entsperren. Deshalb behalten wir einen Generalschlüssel, der das kann.

That means: if someone broke into a stolen database backup alone, they'd find nothing but scrambled bytes: useless without the key. But if someone fully broke into our live servers (not just the database), they could, in theory, get the key too and unlock your vault. We guard hard against that (separate storage for the key, no staff access, encrypted backups, and we're rolling out key-rotation tooling so a leaked key can be replaced quickly), but it's an honest limit, not a guarantee of "nobody, ever, under any circumstances."

Möchtest du einen Tresor, den selbst Notenz niemals öffnen kann, Punkt? Verwende den Versiegelten Tresor (Guardian). Er wird in deinem Browser mit deinem Passwort verschlüsselt. Wir haben nie den Schlüssel, Punkt. Der Nachteil: Er kann nicht automatisch zugestellt werden, und wenn du dein Passwort vergisst, ist er für immer verloren.

Möchtest du die gleiche „Notenz kann es nie öffnen”-Garantie, das Element muss aber trotzdem an einen Empfänger geliefert werden? Verwende ein Shared-Key Vault-Element (Guardian). Du generierst deinen eigenen Schlüssel in deinem Browser, Notenz sieht ihn nie und der Artikel wird weiterhin wie gewohnt an deinen Empfänger geliefert, aber nur du kannst ihm den Schlüssel zum Öffnen geben.

Sealed Vault: Zero-Knowledge-Verschlüsselung

Guardian

Sealed Vault-Elemente werden vor dem Hochladen vollständig in deinem Browser verschlüsselt. Die Server von Notenz speichern nur Chiffretext: niemals deine Klartextgeheimnisse, niemals deinen Verschlüsselungsschlüssel. Selbst ein vollständiger Einbruch in die Notenz-Datenbank bringt nichts Lesbares ans Tageslicht.

Technische Spezifikation

  • ✓ Schlüsselableitung: PBKDF2-SHA256, 600.000 Iterationen
  • ✓ Verschlüsselung: AES-GCM 256-Bit
  • ✓ IV: Zufällige 12 Bytes pro Geheimnis, nie wiederverwendet
  • ✓ Auth-Tag: Das AES-GCM-Authentifizierungs-Tag erkennt Manipulationen und falsche Passwörter
  • ✓ Laufzeit: Alle Kryptooperationen laufen in deinem Browser über die Web-Crypto-API, sodass Schlüssel niemals dein Gerät verlassen

Wichtige Einschränkung

Sealed Vault benötigt zum Entschlüsseln dein Notenz-Passwort. Wenn du dein Notenz-Passwort vergisst, können deine Tresorgeheimnisse nicht wiederhergestellt werden. Das ist beabsichtigt: Es gibt keine serverseitige Hintertür.

Möchtest du, dass Sealed Vault eine Zurücksetzung des Kontopassworts übersteht?

By default, Sealed Vault uses your normal Notenz login password. If you ever reset that password (e.g. via "forgot password"), your existing Sealed Vault secrets become unreadable, because they were encrypted with the old password.

Um dies zu vermeiden, kannst du auf der Sealed Vault-Seite ein separates Sealed Vault-Passwort aktivieren: ein zweites Passwort, das nur zum Entsperren deiner vertraulichsten Geheimnisse verwendet wird, völlig unabhängig von deinem Konto-Login. Das Zurücksetzen deines Kontopassworts hat keine Auswirkungen mehr darauf.

Es gilt die gleiche Regel, nur noch mehr: Wenn du dieses separate Passwort vergisst, kann Notenz deine Sealed Vault-Geheimnisse nicht wiederherstellen, Punkt. Es gibt keinen Reset-Link, keine Support-Überschreibung und keine Möglichkeit für uns, zu helfen. Notiere es dir an einem sicheren Ort, bevor du es einschaltest.

Ermögliche später jemand anderem Zugriff darauf

Der Sealed Vault wird bei der Tresorausführung niemals automatisch zugestellt. Damit eine Vertrauensperson später Zugang erhält, gibst du ihr selbst, außerhalb von Notenz, zwei getrennte Dinge: Zugang zu deinem Notenz-Konto und dein Sealed-Vault-Passwort.

Halte diese beiden getrennt (z. B. Kontodaten beim Testamentsvollstrecker, das Sealed-Vault-Passwort in einem versiegelten Brief oder bei einem Anwalt): Wer beides hat, kann den Tresor öffnen. Wer nur eines hat, nicht.

Shared-Key-Vault-Element: End-to-End-Verschlüsselung, die weiterhin bereitgestellt wird

Guardian

Sealed Vault gibt dir die Garantie „Notenz kann das nie lesen“, kann es aber an niemanden weitergeben. Es ist nur für dich. Ein Shared-Key-Vault-Artikel bietet dir die gleiche Garantie für einen Artikel, den du tatsächlich an einen Empfänger liefern lassen möchtest.

Wenn du ein solches Element hinzufügst, generiert dein Browser einen zufälligen geheimen Schlüssel und verschlüsselt damit deine Notiz oder Datei, bevor sie jemals an Notenz gesendet wird. Wir speichern nur die verschlüsselte Version. Wir sehen deinen Schlüssel nicht, speichern ihn nicht und haben keine Möglichkeit, ihn zu rekonstruieren. Wenn dein Tresor ausgeführt wird, erhält dein Empfänger diesen Artikel wie jeden anderen, plus eine einfache Entsperrseite, die in den Lieferlink integriert ist. Um ihn zu öffnen, fügt er den Schlüssel ein.

  • ✓ In deinem Browser verschlüsselt, bevor es Notenz erreicht: wir speichern immer nur die gesperrte Version
  • ✓ Wird wie andere Artikel auch weiterhin automatisch an deinen Empfänger geliefert, wenn dein Tresor ausgeführt wird
  • ✓ Der Empfänger erhält im Lieferlink eine integrierte Entsperrseite, auf der er den Schlüssel eingeben kann, um ihn zu lesen oder herunterzuladen

Den Schlüssel musst du selbst weitergeben: bitte lies dies sorgfältig durch

Notenz hat diesen Schlüssel nie. Das ist der springende Punkt, aber es bedeutet auch, dass es allein deine Aufgabe ist, den Schlüssel zu deinem Empfänger zu bringen, nicht unsere. Sende ihn so, wie du etwas Sensibles mitteilen würdest: persönlich, per Telefonanruf, über eine Ende-zu-Ende-verschlüsselte Chat-App wie Signal, überall, außer indem du ihn neben dem Artikel selbst liegen lässt.

Wenn du den Schlüssel verlierst oder es nie schaffst, ihn weiterzugeben, erhält dein Empfänger das Element weiterhin, wenn dein Tresor ausgeführt wird, er kann es jedoch nie öffnen. Die darin enthaltenen Daten sind dauerhaft gesperrt. Notenz kann ihn nicht wiederherstellen, zurücksetzen oder einen Ersatzschlüssel generieren. Es gibt keinen Supportprozess, der dieses Problem beheben kann.

Verwende dies für die wenigen Dinge, die maximale Geheimhaltung erfordern Und Lieferung. Für alles andere ist der Standard-Tresor (den wir automatisch liefern können, auch wenn du den Zugriff auf alles verlierst) die sicherere Wahl im Alltag.

Phrasen-Verschlüsselung pro Eintrag

Guardian

Guardian-Nutzer können jeden Tresor-Eintrag mit einer leicht merkbaren 6-Wort-Passphrase schützen, die im Browser erzeugt wird (technisch: Web Crypto PBKDF2, 100.000 Iterationen, SHA-256, AES-256-GCM). Die Passphrase wird niemals an Notenz-Server übertragen. Empfänger geben sie am Zustelllink ein, um den Inhalt clientseitig zu entschlüsseln. Dies funktioniert unabhängig von oder zusammen mit dem Zwei-Personen-Geheimnis (Shamir-Geheimnisteilung: teilt den Schlüssel so auf, dass zwei Vertrauenspersonen ihn gemeinsam freigeben müssen).

If Notenz ever disappears

Zero-knowledge encryption means Notenz never holds your keys, which also means Notenz is not required to decrypt your content: only the passphrase and the standard cryptography are. We publish a standalone offline decryption tool that runs entirely in a saved browser page, with no server, no login, and no external requests. Save a copy now: it will keep working with your passphrase even if Notenz's servers are unreachable.

Verkehr und Infrastruktur

Der gesamte Datenverkehr zwischen deinem Browser und unseren Servern wird bei der Übertragung mit TLS (HTTPS) verschlüsselt. Wir verwenden CSRF-Schutz auf allen Endpunkten, die den Zustand ändern. Sitzungscookies sind als HttpOnly und Secure gekennzeichnet.

  • ✓ Ausschließlich TLS/HTTPS; HTTP wird auf HTTPS umgeleitet
  • ✓ CSRF-Tokens auf allen POST/DELETE-Endpunkten
  • ✓ HttpOnly + Sichere Sitzungscookies
  • ✓ Gehostet in Frankfurt (EU)

Anmeldung und Authentifizierung

Passwörter werden mit PBKDF2-SHA256 gehasht (Django-Standard). Zwei-Faktor-Authentifizierung (2FA) per E-Mail-Einmalcode ist standardmäßig für alle Konten aktiviert. Guardian-Konten können sie nicht deaktivieren.

  • ✓ PBKDF2-SHA256-Passwort-Hashing (Django-Standard, Industriestandard)
  • ✓ E-Mail-2FA standardmäßig für alle Tarife aktiviert
  • ✓ Guardian-Tarif: 2FA ist verpflichtend und kann nicht deaktiviert werden
  • ✓ 2FA-Codes werden als HMAC-SHA256-Prüfsumme gespeichert, nicht als Rohcode
  • ✓ OTP-Codes verfallen nach 5 Minuten
  • ✓ 2FA-Verifizierung erforderlich (in der aktuellen Sitzung), bevor 2FA deaktiviert werden kann
  • ✓ Ratenbegrenzt: maximal 5 Verifikationsversuche pro 10 Minuten

Hast du ein Sicherheitsproblem gefunden?

Wir nehmen Sicherheitsmeldungen ernst. Wenn du eine Schwachstelle gefunden hast, schick uns bitte eine E-Mail an [email protected]. Wir antworten innerhalb von 48 Stunden und beheben das Problem gemeinsam mit dir. Wir haben noch kein formelles Bug-Bounty-Programm, aber wir schätzen eine verantwortungsvolle Offenlegung sehr.