Das Sicherheitsmodell von Agile Secrets

Grundsatz

Ihr Browser verschlüsselt jedes Geheimnis, bevor es den Rechner verlässt. Der Schlüssel steht im Link hinter dem # (URL-Fragment). Diesen Teil senden Browser nach dem HTTP-Standard nicht an Server, er taucht also weder in unseren Anfragen noch in Protokollen auf. Unser Server speichert nur Chiffretext. Ohne den Link ist der Chiffretext wertlos, auch für uns.

Verfahren und Parameter

Wir nutzen ausschließlich die Web Crypto API des Browsers, keine eigene Kryptografie und keine Fremdbibliotheken.

Schlüssel

32 Byte (256 Bit) aus crypto.getRandomValues, base64url im Fragment

Zusatzpasswort

PBKDF2-HMAC-SHA-256, 600.000 Iterationen (OWASP-Empfehlung), 16 Byte Salz je Geheimnis, Unicode-NFC

Ableitung

HKDF-SHA-256 über Schlüssel (und Passwort-Ableitung), Salz „agile-secrets/v1“. Info „verschluesselung“ ergibt den AES-Schlüssel, Info „abruf“ einen 256-Bit-Abruf-Nachweis. Beide sind kryptografisch voneinander getrennt.

Verschlüsselung

AES-256-GCM, 96-Bit-Zufalls-IV je Geheimnis, 128-Bit-Tag, zusätzliche Daten „agile-secrets/v1/p“ bzw. „…/o“ (verhindert, dass jemand den Passwortschutz unbemerkt entfernt)

Inhalt

Text und Dateien in einem Umschlag. Dateinamen und -typen sind mitverschlüsselt, der Server kennt nur die Gesamtgröße.

Manipulation

GCM erkennt jede Veränderung am Chiffretext; die Entschlüsselung schlägt dann fehl, statt verfälschte Daten zu zeigen.

Einmal-Abruf und Löschung

Der Server speichert nur den SHA-256 des Abruf-Nachweises. Den Chiffretext gibt er nur heraus, wenn der Browser den passenden Nachweis schickt. Der entsteht nur aus dem vollständigen Link und gegebenenfalls dem richtigen Passwort. Daraus folgt:

• Wer nur die Kennung kennt, ohne den Teil nach dem #, kann das Geheimnis weder lesen noch verbrauchen.
• Ein falsches Passwort verbraucht nichts. Nach 10 Fehlversuchen löschen wir den Chiffretext, damit niemand Passwörter durchprobiert.
• Weil der Nachweis vom 256-Bit-Schlüssel abhängt, kann auch der Server das Passwort aus dem Hash nicht offline erraten.

Der Abruf läuft in einer Datenbank-Transaktion mit Zeilensperre: Nachweis prüfen, Chiffretext lesen, Chiffretext löschen (bzw. die Zahl der restlichen Abrufe senken), bestätigen. Zwei gleichzeitige Klicks warten aufeinander, der zweite findet nichts mehr. Wir löschen die Zeile, statt sie als gelesen zu markieren. Die Datenbank gibt den Speicherplatz beim nächsten Aufräumlauf frei; dafür sorgt ein häufiger Lauf (VACUUM) auf dieser Tabelle. Abgelaufene Geheimnisse löscht ein Job jede Minute.

Link-Vorschauen und Link-Prüfer

Chat-Programme und E-Mail-Sicherheitsdienste rufen Links vorab auf. Unsere Seite liefert dabei nur einen neutralen Titel und einen Knopf. Abgerufen wird ausschließlich per POST-Anfrage mit eigenem Header, ausgelöst durch einen Klick auf „Geheimnis anzeigen“, und nur mit gültigem Abruf-Nachweis. Abfragen per GET oder HEAD verändern nichts. Selbst ein Prüfdienst, der JavaScript ausführt und klickt, scheitert, wenn er das Fragment nicht mitnimmt.

Anfrage-Links

Ihr Browser erzeugt ein ECDH-Schlüsselpaar (P-256). Der Server bekommt nur den öffentlichen Teil. Der Browser Ihres Gegenübers erzeugt ein Einmal-Schlüsselpaar, leitet per ECDH und HKDF einen AES-256-GCM-Schlüssel ab und verschlüsselt die Antwort. Den privaten Schlüssel haben nur Ihr Gerät und Ihr Abhol-Link. Im Anfrage-Link steht ein Fingerabdruck (SHA-256) Ihres öffentlichen Schlüssels; der Browser Ihres Gegenübers prüft ihn, bevor er verschlüsselt. Würde jemand auf dem Server einen anderen Schlüssel unterschieben, fiele das auf. Die Frage selbst („Bitte schicken Sie mir …“) ist nicht verschlüsselt, weil Ihr Gegenüber sie lesen muss.

Passwort-Tresor

Der Passwortmanager nutzt dasselbe Prinzip wie die Einmal-Links: Verschlüsselt wird nur auf Ihrem Gerät, im Browser oder in der Chrome-Erweiterung.

Tresor-Passwort

Verlässt Ihr Gerät nie. PBKDF2-HMAC-SHA-256, 600.000 Iterationen, 16 Byte Salz, danach HKDF-SHA-256. Der Client lehnt weniger Iterationen ab, auch wenn der Server sie verlangt.

Tresor-Schlüssel

32 Zufallsbytes, einmal mit dem Tresor-Passwort und einmal mit dem Wiederherstellungscode (125 Bit) verschlüsselt (AES-256-GCM).

Einträge

Name, Adresse, Benutzername, Passwort und Notiz einzeln mit AES-256-GCM, die Eintrags-ID ist als zusätzliche Daten gebunden. Der Server kennt weder Inhalte noch Adressen, nur Anzahl, Größe und Zeitpunkte.

Team-Tresore

Jede Person hat ein ECDH-Schlüsselpaar (P-256), der private Teil liegt mit ihrem Tresor-Schlüssel verschlüsselt bei uns. Der zufällige Schlüssel eines Team-Tresors wird für jedes Mitglied einzeln mit dessen öffentlichem Schlüssel verschlüsselt. Beim Entfernen verschlüsselt der Client alle Einträge mit einem neuen Schlüssel; unvollständige Wechsel lehnt der Server ab. Was jemand schon gesehen hat, kann er behalten, deshalb sollten Sie diese Passwörter danach ändern.

2FA-Schlüssel

Liegen verschlüsselt im Eintrag. Codes nach RFC 6238 entstehen nur auf Ihrem Gerät. Liegen Passwort und 2FA im selben Tresor, sind sie nicht mehr getrennt: Das ist bequem, aber schwächer als ein zweites Gerät.

Passkeys

Die Erweiterung erzeugt ein P-256-Schlüsselpaar (ES256), der private Schlüssel liegt im verschlüsselten Eintrag. Die Domain prüft die Erweiterung selbst anhand der Absenderadresse, jede Nutzung bestätigen Sie in einem eigenen Fenster. Der entsperrte Tresor gilt dabei als Nutzerprüfung; ein Fingerabdruck wird nicht abgefragt. Passkeys sind nicht im CSV-Export enthalten.

Import und Export

Die CSV-Datei wird nur im Browser gelesen und erzeugt. Sie enthält alles im Klartext, deshalb verlangt der Export das Tresor-Passwort.

Nachweis

Der Server speichert den SHA-256 eines aus dem Passwort bzw. Code abgeleiteten Nachweises. Er erlaubt nur den Wechsel von Passwort und Code, damit eine gestohlene Sitzung den Tresor nicht unbrauchbar machen kann. Entschlüsseln kann er nichts.

Erweiterung

Verbindet sich per OAuth mit PKCE und einem eigenen Recht, das nur den verschlüsselten Tresor erreicht. Standardmäßig bleibt der Tresor auf dem Gerät entsperrt: Der Schlüssel liegt dann im Browserprofil, nur für die Erweiterung lesbar, bis 30 Tage nach der letzten Nutzung, bis Sie sperren oder trennen. Wer Zugriff auf das Gerät oder das Profil hat, kommt damit an den Tresor. In den Optionen lässt sich stattdessen eine Sperrzeit wählen, dann liegt der Schlüssel nur im Arbeitsspeicher. Einträge werden nur auf ihrer gespeicherten Adresse angeboten (gleiche Domain oder Subdomain, https nie auf http) und nur nach Ihrem Klick oder Tastenkürzel in sichtbare Felder eingefüllt. Bei eingebetteten Anmeldefeldern zählt die Adresse des Frames, nicht die der einbettenden Seite; das Popup nennt sie ausdrücklich. Das Einfüll-Symbol öffnet ein Menü in einem eigenen Frame der Erweiterung, das die Seite nicht lesen kann. Es liegt in der obersten Ebene des Browsers, schließt sich, wenn die Seite es durchsichtig macht, und nimmt Klicks erst nach einer halben Sekunde an. So wird Clickjacking erschwert. Das Inhaltsskript selbst bekommt nie Einträge.

Grenzen: Wer Tresor-Passwort und Wiederherstellungscode verliert, verliert den Inhalt, auch wir kommen nicht heran. Ist Ihr Tresor-Passwort schwach, kann es ein Angreifer mit Zugriff auf unsere Datenbank offline erraten. Eine bösartige Seite, auf der Sie selbst einfüllen, sieht das eingefüllte Passwort. Der Server könnte Einträge löschen oder einen älteren Stand ausliefern, aber nicht unbemerkt verändern. Im Browser vertrauen Sie außerdem darauf, dass wir unveränderten Code ausliefern; die installierte Erweiterung lädt keinen Code nach. Bei Team-Tresoren liefert der Server die öffentlichen Schlüssel: Ein manipulierter Server könnte beim Aufnehmen einen fremden Schlüssel unterschieben oder einen untergeschobenen Tresor anzeigen. Deshalb zeigen wir Fingerabdrücke, die Sie bei wichtigen Tresoren vergleichen können. Der persönliche Tresor gehört der Person, auch Team-Admins und unser Support kommen nicht hinein.

Gespeicherte Daten und Fristen

Datensicherung: Wir sichern Konten, Vorlagen, Metadaten und den verschlüsselten Passwort-Tresor (gelöschte Einträge bleiben darin bis zu 30 Tage), aber bewusst nie Chiffretexte geteilter Geheimnisse. Ein Backup würde ein gelöschtes Geheimnis wieder auferstehen lassen. Fällt die Datenbank aus, sind noch nicht geöffnete Geheimnisse verloren; das nehmen wir in Kauf.

Wovor Agile Secrets schützt

• Passwörter, die dauerhaft in Postfächern, Chatverläufen und deren Backups liegen
• Mitlesen auf dem Transportweg (TLS) und Einbruch in unsere Datenbank (nur Chiffretext ohne Schlüssel)
• Unbemerkte Kenntnisnahme: Wer den Link vor dem Empfänger öffnet, verbraucht ihn, und der Empfänger sieht „bereits geöffnet“
• Abgefangene Links, wenn Sie zusätzlich ein Passwort über einen anderen Weg mitteilen
• Verbrauch durch Link-Vorschauen und Prüfdienste
• Neugierige Admins und Betreiber, auch unsere eigenen Leute

Grenzen, ehrlich benannt

• Ausgelieferter Code. Wie bei jedem Dienst, der im Browser verschlüsselt, kommt der Code von unserem Server. Ein manipulierter Server könnte manipulierten Code ausliefern. Dagegen setzen wir eine strenge Content-Security-Policy ohne Fremdskripte und ein Deployment nur nach Tests. Prüfen lässt sich der ausgelieferte Code im Browser jederzeit. Quelloffen ist Agile Secrets derzeit nicht, ein externes Audit gibt es noch nicht.
• Endgeräte. Ist der Rechner des Absenders oder Empfängers kompromittiert, etwa durch Schadsoftware oder Browser-Erweiterungen, hilft keine Verschlüsselung.
• Wer den Link hat, hat das Geheimnis. Ohne Zusatzpasswort reicht der Link. Schicken Sie Link und Passwort deshalb über verschiedene Wege.
• Was einmal angezeigt wurde, kann kopiert werden. Die Löschung betrifft unseren Server, nicht den Bildschirm des Empfängers.
• Metadaten. Dass, wann und wie groß etwas geteilt wurde, wissen wir. Bei Anfrage-Links auch die Frage.

Betrieb und Sicherheits-Header

• Hosting bei der Hetzner Online GmbH, eigene Datenbank nur für Agile Secrets.
• Content-Security-Policy mit Nonce je Seitenaufruf, default-src 'self', keine fremden Skripte, keine Einbettung (frame-ancestors 'none'). Ausnahmen: die API-Dokumentation (Scalar in fester Version) und die Hilfeseite im Konto (Support-Chat). Auf Seiten, auf denen Geheimnisse eingegeben oder geöffnet werden, läuft nur unser eigener Code.
• Referrer-Policy: no-referrer, Cache-Control: no-store für alle Seiten und Antworten, HSTS, X-Content-Type-Options: nosniff, Cross-Origin-Opener- und Resource-Policy.
• Keine Analyse- oder Werbeskripte, keine Cookies ohne Anmeldung. Der Service Worker für die App startet erst nach der Anmeldung und speichert nur statische Dateien, nie Geheimnisse.
• Keine Protokolle von Inhalten. Fehlermeldungen enthalten nur Pfad und Fehlerart.
• Nach dem Öffnen entfernt die Seite den Schlüssel aus Adresszeile und Verlauf.

API und KI-Assistenten

Die API kennt zwei Wege. Ende-zu-Ende: Ihr Programm verschlüsselt selbst mit dem oben beschriebenen Verfahren und schickt nur Chiffretext. Bequem: Ihr Programm oder ein KI-Assistent schickt Klartext; dann verschlüsselt unser Server einmal im Arbeitsspeicher mit derselben Bibliothek, speichert nur den Chiffretext, gibt den Link einmal zurück und verwirft den Schlüssel. Solche Geheimnisse sind als „vom Server verschlüsselt“ gekennzeichnet.

Es gibt keine Funktion, mit der API oder KI Inhalte öffnen. Für Passwörter, die ein Assistent nicht kennen soll, erzeugt der Server ein Zufallspasswort und schickt den Link nur an Ihre E-Mail-Adresse.

Andere Dienste

Wir haben verbreitete Dienste anhand ihrer öffentlichen Dokumentation und ihres Quellcodes verglichen (Stand Oktober 2026). Das Grundprinzip „im Browser verschlüsseln, Schlüssel im Fragment“ nutzen auch Yopass, PrivateBin und Bitwarden Send; Onetime Secret und Password Pusher verschlüsseln auf dem Server. Was wir zusätzlich bieten: Abruf nur mit einem Nachweis aus dem vollständigen Link, Prüfung des Passworts vor der Herausgabe mit begrenzten Fehlversuchen, Ende-zu-Ende-Anfrage-Links mit Fingerabdruck, keine Backups von Inhalten.

Wo andere stärker sind: Diese Dienste sind quelloffen und lassen sich selbst betreiben, sie sind seit Jahren im Einsatz, und einige erlauben größere Dateien oder prüfen Empfänger per E-Mail-Code. Wenn Ihnen Selbst-Hosting wichtig ist, sind Yopass oder PrivateBin eine gute Wahl.

Schwachstelle melden

Sie haben eine Lücke gefunden? Schreiben Sie an info@agiledeveloper.de mit dem Betreff „Sicherheit Agile Secrets“. Wir antworten schnell, halten Sie auf dem Laufenden und nennen Sie auf Wunsch nach der Behebung. Bitte testen Sie nur mit eigenen Geheimnissen. Maschinenlesbar: security.txt.