1. Clientseitige Kryptografie
Nachrichten werden im Browser mit Web Crypto (AES-GCM) verschlüsselt. Der Server speichert Chiffretext und Metadaten.
EncSend Sicherheitsmodell
Diese Seite beschreibt die aktuelle Implementierung: welche Daten clientseitig verschlüsselt werden, wie Links und Schlüssel gehandhabt werden, welche Zugriffskontrollen aktiv sind und wo die Grenzen des Modells liegen.
2. Schlüssel in URL-Fragmenten
Entschlüsselungsschlüssel werden in URL-Fragmenten übertragen wie #k oder #rk und werden nicht an den Server gesendet.
3. Optionale Passwort-Ebene
Passwortgeschützte Links verwenden serverseitige Passwort-Hashes sowie zusätzliche clientseitige Schlüssel-Umschlüsselung (PBKDF2-SHA-256).
4. Gültigkeitssteuerung
Ablauf-, Aufruf-/Einreichungslimits und Richtlinien für einmaliges Lesen begrenzen den Zugriff auf sensible Inhalte.
Datenfluss: Geheimnis senden
- 1. Der Browser erzeugt 256-Bit-Link-Schlüsselmaterial.
- 2. Die Nachricht wird mit einem zufälligen Nutzdaten-Schlüssel per AES-GCM verschlüsselt.
- 3. Der Nutzdaten-Schlüssel wird mit einem aus dem Link-Schlüssel abgeleiteten HKDF-SHA-256-Schlüssel umschlüsselt.
- 4. Optional wird dieser umschlüsselte Schlüssel zusätzlich mit einer passwortbasierten Ebene (PBKDF2-SHA-256) verschlüsselt.
- 5. Der Server speichert nur
encrypted_payload,encrypted_key, Krypto-Metadaten und Felder der Zugriffsrichtlinie. - 6. Nach erfolgreicher lokaler Entschlüsselung bestätigt der Client einen Aufruf; bei einmaligem Lesen wird das Geheimnis danach als zerstört markiert.
Datenfluss: Sichere Nachrichtenanfrage
- 1. Der Besitzer erzeugt eine Anfrage-URL mit einem zufälligen öffentlichen Token.
- 2. Externe Absender verschlüsseln lokal im Browser mit Anfrageschlüsselmaterial aus dem URL-Fragment.
- 3. Der Server speichert Einreichungen als Chiffretext und setzt Einreichungslimits sowie Ablauffristen durch.
- 4. Der Besitzer liest Einreichungen per lokaler Entschlüsselung; Klartext wird serverseitig nicht verarbeitet.
- 5. Für geräteübergreifendes Lesen kann der Anfrageschlüssel zusätzlich als vom Besitzer umschlüsseltes Artefakt gespeichert werden.
Zugriffskontrolle und Missbrauchsschutz
Öffentliche Zugriffstoken werden zufällig erzeugt, nur als SHA-256-Hashes in der Datenbank gespeichert und validiert über
hash_equals.
Link-Passwörter werden niemals im Klartext gespeichert und gegen serverseitige Hashes geprüft. Passwort-Sitzungen für öffentliche Links sind zeitlich begrenzt (Standard 120 Minuten).
Rate Limiting ist für kritische Endpunkte aktiv, einschliesslich Passwortprüfungen, öffentlicher Einreichungen, Login- und Verifizierungsabläufe.
Operationen auf Besitzerseite sind durch Authentifizierung, verifizierten E-Mail-Status und Autorisierungsrichtlinien geschützt; sensible Wiederherstellungsänderungen erfordern eine aktuelle Passwortbestätigung.
Besitzer-Wiederherstellung und Key Vault
EncSend bietet optionale verschlüsselte Wiederherstellungsartefakte für geräteübergreifende Szenarien:
- Kryptoprofil des Besitzers: verschlüsselter Master-Schlüssel (AES-GCM), passphrasenbasiert (PBKDF2-SHA-256).
- Benutzer-Key-Vault: verschlüsseltes Backup lokal gespeicherter Geheimnis-/Anfrageschlüssel.
- Vom Besitzer umschlüsselte Anfrageschlüssel pro Anfrage, einschliesslich fortsetzbarer Rotations-Batches mit Wiederholungsunterstützung.
Audit und Nachvollziehbarkeit
Sicherheitsrelevante Aktionen werden protokolliert (zum Beispiel Link-Ausstellung, Zugriff verweigert, Passwortabfrage-Schritte, Erstellung von Einreichungen und Wiederherstellungsaktualisierungen).
- Zugriffsereignis-Tabellen speichern Ereignistyp, Zeitstempel, User-Agent und kontextbezogene Metadaten.
- Audit-Protokolle über wichtige Ereignisse.
- Eine eigene Migration entfernt IP-Adress-Spalten aus sitzungs- und ereignisbezogenen Tabellen.
Wichtige Grenzen des Modells
- Die Browsersicherheit bleibt kritisch: Lokale Schlüssel werden im Browser-Speicher zwischengespeichert und erfordern eine gehärtete Client-Umgebung.
- JavaScript und Web Crypto sind für sichere Erstellung und lokale Entschlüsselungsabläufe zwingend erforderlich.
- Transportsicherheit (HTTPS, Reverse-Proxy-Härtung, TLS-Richtlinie) muss auf Infrastruktur-Ebene durchgesetzt werden.
- Passwort-Hashing schützt die serverseitige Speicherung, ersetzt aber keine starken Passwortwahlen.