Öffnen Sie einen „Online-Passwort-Generator“, klicken Sie auf Erzeugen und schauen Sie ins Network-Panel der Entwicklertools. Steht das frische Passwort in Request-Body oder Query, hat Klartext Ihr Gerät bereits verlassen. Dafür brauchen Sie keine Markenversprechen — der Browser legt den Verkehr offen.
Rechnung im Browser ist kein Modewort für „dezentral“. Es geht darum, das Klartext-Fenster auf dem Gerät zu halten: eine Übertragung weniger, ein Server-Log weniger, eine Chance weniger, dass jemand einen Speicherabzug falsch liest. Unten stehen Bedrohungsmodell, prüfbare Schritte und klare Grenzen. Der Werkzeugkasten von PassAfer folgt diesem Prinzip; dieser Text ist kein Produktüberblick. Er beantwortet eine Frage: Warum sollte sensible Rechnung nicht standardmäßig beim Server liegen?
Welches Fenster Server-Rechnung öffnet
Das Klartext-Fenster meint: Wo existiert Klartext (oder ein Schlüssel, der ihn unmittelbar zurückholt) wirklich? Rechnet der Server, ist das Fenster selten nur der Moment des Absendens. Es ist eine Kette, die sich hinterher kaum löschen lässt:
- Die TLS-Sitzung vom Browser zur Herkunft — der Serverprozess sieht die entschlüsselte Anfrage, nicht Ciphertext.
- Stichproben in Reverse-Proxy, WAF, APM und Fehlertracking; ein 500er kann Formularfelder in den Crash-Report schreiben.
- Query-Strings in Anwendungs-, Slow-Query- und Access-Logs; wer den Schlüssel in
?key=legt, schreibt ihn ins Access-Log. - Zwischendateien in Datenbank, Objektspeicher und Temp-Disk sowie Backup und Offsite-Kopien.
- Die Zeit, in der Betrieb, Support oder ein Angreifer eine dieser Kopien halten — das Fenster war schon offen; „löschen nach Gebrauch“ ändert das nicht.
Rechtsräume und Unterauftragnehmer machen „wir schauen nicht hin“ schwer prüfbar. Sie können Protokoll und Traffic prüfen, nicht die Hausordnung im Rechenzentrum der Gegenseite.
Beim Passwort-Generator sticht das besonders: Sie wollen ein Geheimnis, das noch nirgends vorkam. Entsteht es in fremdem Rechenzentrum, liegt die erste Kopie nicht bei Ihnen. Kleben Sie es danach in Produktionskonfiguration, CI-Variablen oder einen Passwortmanager, haben Sie einen Knoten mehr, den Sie nicht sehen.
Gleiches gilt für den Passwortcheck: Ein häufig genutztes Passwort an einen entfernten „Stärke-Check“ zu schicken, gibt das empfindlichste Wiederverwendungsgeheimnis an Dritte. Öffentliche Leak-Abfragen lassen sich als k-Anonymity bauen; PassAfer wählt eine härtere Grenze — das Testpasswort wird nicht hochgeladen, Stärke und die Liste schwacher Passwörter laufen lokal. Zu prüfen ist nicht „die Gegenseite sagt, sie speichert nicht“, sondern: Die Anfrage enthält dieses Passwort gar nicht.
Bei der Dateiverschlüsselung bedeutet „hochladen → auf dem Server verschlüsseln → wieder herunterladen“, dass Passphrase und Datei mindestens im Serverspeicher vollständig da waren. Lokales Streaming gibt dem Server keinen Klartext: Er muss nicht einmal wissen, ob Sie ein Foto oder ein Disk-Image verschlüsseln.
HTTPS ist keine lokale Rechnung
TLS schützt Mithörer auf dem Weg, nicht den Server am anderen Ende. Rechnet der Server, muss die Gegenseite Klartext lesen. Lokale Rechnung löst etwas anderes: Die Gegenseite soll dieses Material gar nicht sehen.
Was „lokal“ konkret meint
„Lokal“ wird schnell zum Slogan. Es muss auseinanderfallen, sonst gilt auch „nur für Sie sichtbar“ in einer Cloud-Ablage als lokale Verschlüsselung.
Ein Prozess auf Ihrem Gerät — nicht „in irgendeinem Cloud-Konto“
Lokal heißt bei PassAfer: Die Rechnung läuft im Browser-Tab. Zufallszahlen kommen von crypto.getRandomValues, symmetrische Verschlüsselung über die Web Crypto API. Schlüsselmaterial sitzt in kurzlebigen CryptoKey-Objekten und geht standardmäßig nicht als Analysefeld nach draußen. Ergebnisse können Sie kopieren, exportieren oder auf die Platte laden; nach dem Schließen der Seite räumt der Browser den Klartext nach seinem Lebenszyklus, statt eine zweite Kopie remote zu halten.
Das ist etwas anderes als „Datei in eine nur für mich sichtbare Cloud legen“. Der Cloud-Server kann Objektklartext meist lesen, außer Sie haben vorher lokal versiegelt und nur Ciphertext hochgeladen. Lokal zuerst fragt: Ist Klartext außerhalb Ihres Geräts in nutzbarer Form erschienen?
Algorithmus und Dateigrenze sind prüfbare Fakten
Die erste Version kennt nur AES-256-GCM (authentifizierte Verschlüsselung: wurde Chiffretext verändert, schlägt die Entschlüsselung fehl). Die Dateiverschlüsselung streamt einzelne Dateien, Obergrenze 5 GB, Ausgabe .lock (bevorzugt) oder .enc, damit ein ganzes Video nicht auf einmal im Speicher landet. Diese Zahlen stehen in der Spezifikation, nicht in Werbeadjektiven; taucht auf der Seite ein nicht gelieferter Algorithmuswechsel auf, gilt die Produktbeschreibung, nicht eine Vermutung.
Lokal heißt nicht „alles ohne Konto“
Rechenort und Anmeldepflicht sind zwei Dinge. Gäste können Zufallszeichen und merkbare Passphrasen erzeugen, kopieren und exportieren; Passwortcheck, Link-Bereinigung, das Erstellen einer selbstzerstörenden Nachricht, Dateiverschlüsselung und Tresor brauchen ein Konto. Wer „lokal“ als „jeder darf alle Tools nutzen“ liest, widerspricht der Rechte-Matrix.
| Fähigkeit | Ohne Anmeldung | Wird sensibles Material standardmäßig hochgeladen? |
|---|---|---|
| Zufalls- / Passphrase-Generator | Verfügbar | Kein Upload; Erzeugung im Browser |
| Zum Tresor hinzufügen | Anmeldehinweis | — |
| Passwortcheck | Anmeldehinweis | Testpasswort bleibt lokal; Stärke + Liste schwacher Passwörter |
| Link-Bereinigung / Schwärzung | Anmeldehinweis | URL und Text lokal; nichts in Analytics |
| Selbstzerstörende Nachricht erstellen | Anmeldehinweis | Hochgeladen wird Chiffretext, nicht der Klartext |
| Selbstzerstörende Nachricht lesen | Für Empfänger öffentlich | Schlüssel im URL-#-Fragment, nicht mit HTTP an den Server |
| Dateiverschlüsselung | Anmeldehinweis | Datei und Passphrase bleiben lokal; Streaming AES-256-GCM |
Die selbstzerstörende Nachricht ist der einzige Pfad, der serverseitig etwas zwischenlagert — aber nur Chiffretext. Der Entschlüsselungsschlüssel liegt hinter dem URL-#: Das Fragment fährt nicht mit der HTTP-Anfrage mit, Access-Logs enthalten in der Regel nur den Pfad. Die Leseseite ist für Empfänger offen — sonst müsste die Gegenseite erst ein Konto anlegen, und einmaliges Teilen wäre unmöglich. Nach dem ersten Lesen wird der Chiffretext planmäßig gelöscht. Zero Knowledge heißt nicht „es wird nichts gespeichert“, sondern „gespeichert und trotzdem nicht entschlüsselbar“. Hier reicht diese Vereinbarung.
Im Network-Panel prüfen, ob Sensibles nach draußen geht
Slogans beweisen sich nicht selbst. Die folgenden Schritte brauchen nur die eingebauten Entwicklertools. Ziel ist nicht, Seitenkanäle weltweit auszuschließen, sondern Online-Tools zu entlarven, die Klartext per POST abschicken.
Mit dem Passwort-Generator ohne Anmeldung beginnen. Öffnen Sie die Generatorseite, bleiben Sie abgemeldet. Zufallszeichen und Passphrasen müssen sofort funktionieren. So trennen Sie Kontosystem und „wird beim Erzeugen etwas gesendet“ und verwechseln Login-Requests nicht mit einem Passwort-Upload.
Network öffnen und Preserve log aktivieren. Chrome, Edge und Firefox reichen. Filter zuerst auf Fetch/XHR, dann alle Requests. Preserve log verhindert, dass ein Seitenwechsel die Liste leert. Auch sendBeacon und Service-Worker-Requests erscheinen im Panel.
Ein leicht erkennbares Passwort erzeugen. Länge etwas höher setzen, Ergebnis in einen Editor kopieren. In die Network-Suche das ganze Passwort oder eine Teilzeichenkette einfügen, die zufällig nicht in JS-Quellen vorkommt.
URL, Query und Request Payload auf Treffer prüfen. Trifft keine Anfrage diese Teilzeichenkette, ist Klartext zumindest beim Erzeugen nicht als HTTP-Inhalt rausgegangen. Irrelevante Strings in statischen Skripten zählen nicht; gesucht ist genau die gerade erzeugte Zeichenkette.
Nach der Anmeldung dieselbe Methode. Passwortcheck, Link-Bereinigung und Dateiverschlüsselung brauchen ein Konto. Danach mit einem reinen Testpasswort oder einer kleinen Datei erneut suchen. Der Passwortcheck darf das Testpasswort nicht remote schicken; die Bereinigung darf den Originaltext nicht POSTen; die Dateiverschlüsselung darf Klartext nicht als Multipart hochladen.
Bei der selbstzerstörenden Nachricht Chiffretext und Fragment trennen. Beim Erstellen (Anmeldung nötig) sollte der Server Chiffretext bekommen, nicht Ihren Klartext. Im vollständigen Link steht der Schlüssel hinter #; ohne Fragment im Network darf der Schlüssel nicht im Pfad auftauchen. Empfänger öffnen die Leseseite ohne Konto.
Was dieser Schritt beweist — und was nicht
Network zeigt: Ist Klartext in dieser Operation in HTTP gelandet? Es sieht keinen gleichursprünglichen Speicherzugriff, keine bösartige Erweiterung und keine XSS-Einschleusung. Zum Entlarven vieler „Online-Tools“ reicht das; es ist kein formaler Beweis.
Was lokal bleiben muss — und welche Ausnahme klar sein sollte
Auf dem Gerät bleiben muss, was nach dem Verlassen nicht zurückzuholen ist: frisch erzeugte Passwörter, alte Testpasswörter, zu schwärzender Text, Dateiklartext, symmetrische Schlüssel. Stehen sie in fremden Logs, löscht das Schließen der Seite die Kopie der Gegenseite nicht.
Das Gerät verlassen darf nur, was kryptographisch für den Server nutzlos ist oder zum Kontosystem gehört. Beispiele: der Chiffretext-Blob einer selbstzerstörenden Nachricht, Benutzername und Anmeldepasswort, statische Ressourcen ohne Geheimnis. Login und „Tool-Klartext hochladen“ nicht vermischen: Login ist Stufung — ohne Konto den Generator, nach der Anmeldung Passwortcheck, Link-Bereinigung, Einmal-Link, Dateiverschlüsselung und Tresor. Anmeldeinformationen gehören zum Konto, nicht zur Frage, ob das gerade erzeugte neue Passwort hochgeladen wird.
Die Dateiverschlüsselung liefert .lock / .enc zum Download. Danach gehen Chiffretext-Dateien per Cloud, USB oder Mail. Die Cloud sieht weiterhin weder Passwort noch Original — sofern das Passwort nicht in derselben Übertragung oder derselben Mail im Klartext steht. Lokale Verschlüsselung ändert „der Cloud-Admin kann Ihre Fotos standardmäßig öffnen“, nicht die physische Aufbewahrungspflicht.
Link-Bereinigung und Schwärzung halten URL und Text ebenfalls im Browser: UTM- und Werbeparameter entfernen, Telefonnummern und Ausweise maskieren, Ergebnis vor dem Versand prüfen. Der Originaltext wird nicht hochgeladen und nicht als Analytics-Inhalt gesendet. Würde der Vorgang das ganze Ticket an den Server POSTen und „geschwärzt“ zurückgeben, wäre das Klartext-Fenster dort schon offen; Schwärzung wäre nur noch Darstellung.
Grenzen und Irrtümer lokaler Browser-Verschlüsselung
Lokal zuerst senkt die Exposition auf Server und Übertragungsweg, nicht auf einem von Malware kontrollierten Rechner. Grenzen in die Erwartung zu schreiben hilft mehr als drei Buchstaben AES in der Fußzeile.
Ist die Seite injiziert, hilft der Algorithmus nicht
XSS oder ein gekapertes Skript kann Eingabefelder lesen. Web Crypto schützt Schlüsseloperationen in einer ehrlichen Seite, nicht „bösartiger Code ist schon same-origin“. Verlassen Sie sich auf Same-Origin-Policy, Content-Security-Policy und Integrität der Frontend-Lieferkette. Aus „AES-256-GCM“ folgt nicht „also ist XSS wirkungslos“.
Erweiterungen, Firmenproxy, Schulterblick
Browsererweiterungen und Firmen-SSL-Entschlüsselung können Seiteninhalt weiterhin sehen. Sitzt ein Firmenproxy mit eigenem Root-Zertifikat dazwischen, zeigt das Network-Panel die Welt hinter dem Proxy. Geräteverlust, Bildschirmfreigabe und Schulterblick kann lokale Rechnung nicht abwehren. Das ist Endpunktsicherheit und gehört getrennt von „der Server soll keinen Klartext halten“.
„Kein Upload“ heißt nicht „kein Netz“
Seite, Skripte und Login-Requests gehen weiter raus. Zu prüfen ist, ob sensible Felder in Requests stehen — nicht, ob das Kabel gezogen ist. PassAfer meldet Testpasswörter, Bereinigungs-Original oder Dateiinhalt auch nicht als Analyseereignis; in Events sollte das Geheimnis selbst nicht vorkommen.
Fähigkeiten nicht überzeichnen
Die erste Version ist AES-256-GCM; erwarten Sie auf der Seite keinen umschaltbaren RSA- oder undelieferten nationalen Algorithmus. Schreiben Sie die Leseseite der selbstzerstörenden Nachricht nicht als anmeldepflichtig. Behaupten Sie nicht, der Server könne Klartext oder Schlüssel sehen — das widerspricht den Produktfakten. Ehrlich lokal zuerst: sensible Rechnung im Browser; Klartext, Schlüssel und Dateien standardmäßig ohne Upload; bei der selbstzerstörenden Nachricht lagert der Server nur Chiffretext.
Wo Sie selbst nachprüfen können
Wollen Sie zuerst klären, ob das Erzeugen etwas nach draußen schickt, ist der Passwort-Generator der günstigste Einstieg: keine Anmeldung, Zufallszeichen und Passphrasen lokal, Kopieren und Export ebenso. Network öffnen, die gerade erzeugte Zeichenkette suchen. Der Aufwand ist gering und das Gespür für das Klartext-Fenster entsteht schnell.
Typische Alternativen haben konkrete Lücken. Klartext-Mail und Messenger lassen Schlüssel in Verlauf, Serverarchiv und Gerätebackup; Cloud-Ablagen sind für den Server standardmäßig lesbar, außer Sie verschlüsseln zuerst lokal; Schlüssel in Query-Parametern landen fast immer im Access-Log. Das sind keine Komfortmängel — das Klartext-Fenster ist eingebaut.
Brauchen Sie ein Backup, das nicht offen in die Cloud soll, nutzen Sie nach der Anmeldung Datei verschlüsseln: AES-256-GCM im Stream im Browser, höchstens 5 GB pro Datei, Download als .lock oder .enc. Danach den Vorgang mitschneiden und prüfen, dass die Originaldatei nicht per POST ging. Für kurzen Geheimtext an Kolleginnen und Kollegen, ohne Schlüssel in Server-Logs, kommt die selbstzerstörende Nachricht: lokal verschlüsseln, Schlüssel hinter #, Server nur Chiffretext, Leseseite ohne Registrierung. Hier reicht die Antwort: Nach diesem Klick liegt der Klartext noch in Ihrem Tab?
Der Slogan von PassAfer lautet „Lokal verschlüsselt, sicher unterwegs“. Voraussetzung für „unterwegs“: Die Rechnung läuft in dem Tab, den Sie gerade ansehen — und Sie können das mit dem eingebauten Panel nachprüfen.