Warum OCR-Klartext und Image-IDs nach dem Screenshot-Upload auf einen Bildhoster gefährlicher sind als der Passwort-Hash

Die Suchintention in einem Satz beantworten

Die Gefahr beim Screenshot auf dem Bildhoster liegt nicht bei „ist das Login-Passwort gehasht?“, sondern bei „verlassen Bild und der daraus gezogene Text als eigene Felder dieses Gerät?“. Der Hash deckt die Spalte Kontopasswort. OCR-Text, Image-ID, Upload-IP, User-Agent und EXIF-Ort sind eine andere Gruppe. Sind sie draußen, stützt sich ein ungelisteter Screenshot nicht mehr auf „den Link kann niemand raten“, und das Passwort im Bild braucht keinen Hash-Bruch mehr.

Diese Notiz richtet sich an Entwicklung, Betrieb und alle, die Fehlerbild, Konsole oder das Fenster des Passwortmanagers auf einen Screenshot-Hoster legen und dann weiterleiten. Sie ersetzt keine Störungsmeldung eines Hosters und ist keine Anleitung „Screenshots abschalten“. Mitnehmen sollen Sie: Welche Schicht der Hash in der Mitteilung wirklich deckt, welches Datenschutzmodell die Image-ID kippt, warum OCR leichter zu durchsuchen ist als Pixel – und wie Sie vor dem Upload den Ausgang vergleichen.

Welche Schichten diese Hoster-Mitteilung trennt

Am 16. September 2026 veröffentlichte der Gyazo-Betreiber Helpfeel eine englische Mitteilung und am selben Tag eine japanische Fassung. Die Zeitlinie: Am 11. September nutzte ein Dritter eine Lücke auf dem Upload-Server für beliebige Befehle; noch am Abend fiel die Abweichung auf, vor dem frühen 12. September war der Weg geschlossen und die Lücke geschlossen; am 14. September bestätigte man den Abfluss und hielt einen Teil der Bildauslieferung an; am 15. September ging die Meldung an die japanische Kommission für den Schutz personenbezogener Daten, und neu hochgeladene Bilder nach der Behandlung liefen wieder.

Der bestätigte Umfang vom 16. September hat zwei Blöcke. Erstens rund 23,62 Millionen nutzerbezogene Datensätze: selbst gewählter Name oder Anzeigename, E-Mail, Passwort-Hash, Nutzer-ID, Geräte-ID, Login-Sitzungs-ID, X-Integrations-Token bei bestehender Verbindung, die mit Google-SSO verknüpfte E-Mail, Profil, Sprache, Registrierungs- und letzter Login-Zeitpunkt, Abo und Abrechnungsstatus. Zahlungsdaten wie Kreditkartennummern fehlten laut Mitteilung. In den 23,62 Millionen stecken auch anonyme Konten ohne hinterlegte E-Mail; die Zahl der betroffenen Personen war an dem Tag noch in Klärung.

Zweitens Bildmetadaten. Der Hauptanteil sind rund 490 Millionen Zeilen zu Registrierungen im Januar 2019 und früher, etwa 14,4 Prozent aller bildbezogenen Daten; zusätzlich rund 2,4 Millionen Zeilen, die unter weiteren Bedingungen gezogen wurden. Die Felder: Image-ID zum Bau der Bild-URL, Quell-IP des Uploads, User-Agent, EXIF-Ort falls vorhanden, aus dem Bild gezogener OCR-Text, Bildtitel, Bezugs-URL und der Hash des Passworts für nicht öffentliche Bilder. „Bild“ umfasst in der Mitteilung Screenshots, GIFs und Videos. Helpfeel und Cosense laufen auf anderen Systemen; bis zu diesem Tag war dort kein Abfluss bestätigt. Seiten, die ein Gyazo-Bild einbetteten, konnten wegen der angehaltenen Auslieferung leer bleiben.

Das ist keine Wiederholung von „wieder ein Website-Passwort-Hash weg“. Hash, Sitzungs-ID, Image-ID und OCR-Text sind vier parallele Kanäle. Nur das Gyazo-Login zu ändern deckt den ersten und hält bereits geleakte Sitzungs-IDs nicht auf. Die Mitteilung schreibt, Authentifizierungsdaten seien ungültig gemacht und beschränkt worden, und Nutzer sollen das Gyazo-Passwort sowie gleiche oder ähnliche Passwörter bei anderen Diensten ändern.

Der Login-Hash hält keinen Klartext im Bild auf

Ein Passwort-Hash hat ein Ziel: Nach dem Diebstahl der Tabelle soll die Angreiferin das Login-Passwort nicht direkt lesen, sondern erst rechnen. Algorithmus, Salt und Iterationen bestimmen, wie teuer diese Schicht ist. Sie bestimmen nicht, ob die andere Zeichenkette im Screenshot sicher ist. Hoster-Login und Produktionspasswort im Bild waren nie dieselbe Spalte.

Wer Terminal, Browser-Passwortfeld, Cloud-Konsole oder das Fenster des Passwortmanagers abfotografiert, übergibt Pixel. Viele Hoster ziehen danach Text, speichern das Ergebnis als durchsuchbaren OCR-Text und machen „das Bild mit dem Stacktrace“ auffindbar. Sitzt das Ergebnis in der Tabelle, leben Passwort, Verbindungsstring und Token nicht mehr nur in Bildbytes, sondern als Feld, das sich nach Stichwort filtern lässt. Die Mitteilung listet „OCR-Text des Bildes“ als eigenes geleaktes Metadatenfeld. Das ist keine Vermutung unter dem Artikel, sondern eine Spalte in der Datenbank.

„Passwörter liegen als Hash“ trägt deshalb nur einen engen Satz: Das Login bei diesem Hoster steht in der Nutzertabelle nicht im Klartext. Es trägt nicht: Der private SSH-Schlüssel im Screenshot braucht zuerst einen Hash-Bruch; in der OCR-Tabelle steht kein BEGIN OPENSSH und kein AKIA; das nicht öffentliche Bild öffnet nur Sie. Die späteren Sätze brauchen andere Belege: Stehen OCR und Image-ID in den Metadaten, und stand vor dem Upload ein lesbares Geheimnis im Bild?

Warum die Image-ID den „ungelisteten Link“ kippt

Viele Hoster setzen „nicht öffentlich teilen“ so um: Das Bild steht nicht auf der Profilseite, Sie bekommen nur einen Direktlink aus scheinbar zufälligen Zeichen. Die Sicherheitsannahme lautet: Ohne ID lässt sich die URL nicht bauen. Das ist eine versteckte Adresse, keine Zugriffskontrolle. Wer die ID hat, setzt dieselbe Regel an und hat die Adresse.

Helpfeel schreibt die Image-ID als „Information zum Bau der Bild-URL“ und sagt offen, Dritte könnten damit auf das zugehörige Bild zugreifen. Deshalb wurde ein Teil der Bildansicht vorübergehend geschlossen. Die Mitteilung bestätigt außerdem: Die Dateiliste nicht öffentlicher Bilder ist abgeholt worden; es lasse sich nicht vollständig ausschließen, dass ein Teil dieser Bilder angesehen wurde. Liste plus ID zerlegt die Annahme „nur ich kenne diesen Link“.

Hat ein nicht öffentliches Bild ein eigenes Passwort, listet die Mitteilung „das gehashte Passwort“. Der Hash zwingt beim Passwort selbst einen weiteren Rechenschritt. Er nimmt niemandem die Pixel, der die ID schon kennt und der Hoster die Datei noch über diese ID ausliefert. Eine angehaltene Auslieferung ist ein Betriebsschalter. Sie beweist nicht, dass die ID die Datenbank nie verlassen hat. „Den Link habe ich nie in die Gruppe gelegt“ als „das Bild liegt nicht in der Datenbank“ zu schreiben, vermengt Sichtbarkeit in der Oberfläche mit Sichtbarkeit in der Speicherschicht.

EXIF-Ort, Upload-IP und User-Agent sind die dritte Kontextebene. Ein Handyfoto vom Bildschirm oder vom Arbeitsplatz kann GPS tragen; die Upload-Anfrage trägt Ausgangsadresse und Browserkennung. Auch ohne Hausnummer in den Pixeln lassen sich „wer, von wo, mit welchem Client“ wieder zusammenziehen. Manche Screenshot-Werkzeuge streichen Ortsdaten, andere nicht. „Ich habe einen Screenshot gemacht, kein Albumfoto“ heißt nicht, EXIF sei leer.

Warum OCR leichter ein zweites Mal zu nutzen ist als Pixel

Ein ganzes PNG muss jemand durchblättern oder ein Bildmodell laufen lassen, bis im unaufgeräumten Desktop das Passwortfeld auffällt. OCR-Text ist bereits eine geschnittene Zeichenkette. Nach dem Abfluss ist die Suche nach password, BEGIN , sk- oder einem internen Hostnamen eine Größenordnung schneller als 490 Millionen Bilder zu wenden. Die Mitteilung nennt keine Erkennungsquote. Sie muss das auch nicht: Sobald die Tabelle „aus dem Bild gezogenen Text“ hält, steht die Angreiferin vor einem Textfeld, nicht vor Vorschaubildern.

Deshalb hält „ich habe nicht öffentlich gestellt“ diese Schicht nicht auf. Der Sichtbarkeitsschalter steuert, ob die Produktseite das Bild auflistet. OCR steuert, ob der Hoster das Bild in Wörter gezogen hat. Beides kann zugleich wahr sein: in der Oberfläche ungelistet, in der Tabelle Titel, OCR und ID. Ein Dump holt die Tabelle, nicht den Zustand Ihres Teilen-Knopfes.

Das ist nicht dieselbe Sache wie „die Empfangsseite hat Ihren Bildschirm fotografiert“ beim Einmal-Link. Die frühere Notiz betrifft die Kopie auf dem anderen Gerät; löscht der Host den Chiffretext, bleibt diese Kopie. Diese Notiz betrifft den Fall, dass Sie die Pixel selbst an den Hoster geben und der Hoster Text zieht und eine ID vergibt. Einmal „die Gegenseite hat behalten“, einmal „Sie haben zuerst abgegeben“. Weder „der Link ist tot“ noch „Passwörter sind gehasht“ streicht beide Sätze.

Vor Ort vergleichen: vor dem Upload das Bild, danach die Anfrage

Slogans sind kein Beleg. Unten prüfen Sie nur zwei Dinge, die Sie steuern: Steht im Pixel, das dieses Gerät verlassen soll, ein Canary? Und wenn Sie auf ein lokales Werkzeug wechseln – darf der Anfragekörper den Originalsatz enthalten? Legen Sie kein echtes Produktionspasswort in einen Bildhoster, um das zu prüfen.

1. Schreiben Sie einen wegwerfbaren Canary, etwa canary-fp-20260920-gyazo-ocr. Setzen Sie ihn in einen leeren Editor oder in eine lokale HTML-Datei und machen Sie einen Screenshot. Keine echten Hostnamen, keine echten Schlüssel.
2. Vergrößern Sie das Bild und prüfen Sie pixelweise: Steht der Canary vollständig im Rahmen? Liegt daneben eine Statusleiste, ein zweites Passwortfeld, ein alter Befehl im Terminal? Was Sie lesen können, kann OCR als Text ablegen.
3. Wenn Sie den Hoster trotzdem nutzen: Öffnen Sie in den Entwicklerwerkzeugen Network, aktivieren Sie Preserve log und laden Sie hoch. Suchen Sie den Canary im Anfragekörper. Der Upload trägt Bildbytes. Der Canary landet in der Datei, nicht in der Spalte „Passwort-Hash“. Genau das zeigt: Der Hash deckt dieses Bild nicht.
4. Vergleichen Sie den anderen Kanal. Öffnen Sie den Einmal-Link, schreiben Sie denselben Canary als Text und erzeugen Sie den Link. Suchen Sie erneut in Network: Der Körper von POST /secrets soll Chiffretext, Ablauf und Lesezahl tragen – nicht den Originalsatz und nicht den Schlüssel hinter der Raute. Die Form ist s.html?id={id}#{key}; der Schlüssel sitzt nur hinter #. RFC 9110 schließt das Fragment aus der Ziel-URI der Anfrage aus.

Die ersten drei Schritte zeigen: Auf dem Screenshot-Kanal verlässt das Geheimnis dieses Gerät als Pixel – und als Text, den der Hoster ziehen kann. Der vierte Schritt zeigt: Derselbe Canary kann „lokal AES-256-GCM, nur Chiffretext hochladen“ gehen. Mischen Sie die Kanäle nicht. Laden Sie nicht zuerst auf den Hoster und kleben Sie dann den Direktlink in den Einmal-Link. Fotografieren Sie auch nicht die vollständige Einmal-URL und laden Sie sie zurück auf den Hoster.

Drei Arten, „der Bildhoster ist sicher“ zu weit zu lesen

Erstens: „Nicht öffentlich“ als Zugriffskontrolle lesen. Die Oberfläche zeigt das Bild nicht – das heißt nur, das Produkt hat es nicht in die öffentliche Liste gelegt. Liegt die Image-ID in der Tabelle und ist die Direktlink-Regel bekannt, lässt sich ein nie geteiltes Bild trotzdem bauen. „Die nicht öffentliche Liste ist abgeholt“ in der Mitteilung ist das Gegenbeispiel, kein Gyazo-Sonderfall.

Zweitens: Ein neues Hoster-Passwort als Rotation der Geheimnisse im Screenshot schreiben. Hoster-Login, Sitzungs-ID, Drittanbieter-OAuth-Token und Produktionsschlüssel im Bild gehören zu verschiedenen Systemen. Die offizielle Aufforderung, Gyazo-Passwort und wiederverwendete gleiche Passwörter zu ändern, deckt die vorderen Punkte. Wer die Produktionskonsole abfotografiert hat, muss im Ursprungssystem Schlüssel widerrufen, Datenbankkonten rotieren und Wiederherstellungscodes ungültig machen. Die lokale Passwortprüfung vergleicht nur eine öffentliche Liste häufiger schwacher Passwörter. Sie beweist nicht, dass eine Zeichenkette nie in der Hoster-OCR stand.

Drittens: „Ich habe den Fehlerdialog fotografiert, nicht das Passwort“ als sauberes Bild lesen. Verbindungsstring im Terminal, token= in der Adresszeile, Einmalcode in der Benachrichtigung, das E-Mail-Fenster daneben – alles landet im selben Frame. OCR filtert nicht nach Ihrer Absicht. Vor dem Upload bleibt nur das eine Bild, das Sie senden wollen, pixelweise. Der Dateiname error.png trägt das nicht.

Häufige Fragen

Der Bildhoster speichert Passwörter als Hash – sind Passwörter im Screenshot dann auch geschützt?

Nein, das sind zwei Schichten. Der Login-Hash schützt das Kontopasswort selbst, und selbst dort zählen Algorithmus und Salt. Nach dem Upload kann der Hoster zusätzlich OCR-Text, Image-ID, Upload-IP und EXIF speichern. Passwort, Schlüssel und Verbindungsstring im Bild sind in der OCR-Tabelle oft bereits durchsuchbarer Klartext.

Ist ein ungelisteter, nie geteilter Screenshot nur für mich erreichbar?

„Nicht öffentlich“ heißt meist: Die Produktseite listet das Bild nicht. Es heißt nicht, dass niemand die Adresse zusammensetzen kann. Die Image-ID ist die Information, aus der die Bild-URL gebaut wird. Verlässt die ID mit den Metadaten den Hoster, stützt sich der ungelistete Direktlink nicht mehr auf „nicht ratbar“. Eine angehaltene Auslieferung heißt nur: Einige IDs liefern derzeit keine Pixel. Sie heißt nicht, historische Metadaten seien nie kopiert worden.

Reicht es, das Login-Passwort beim Bildhoster zu ändern, oder müssen Passwörter im Screenshot extra rotiert werden?

Getrennt behandeln. Ein neues Hoster-Passwort schneidet nur den Login bei diesem Dienst ab und hält bereits geleakte Sitzungs-IDs nicht auf. Datenbankpasswort, API-Key, privater SSH-Schlüssel und Wiederherstellungscode aus dem Screenshot müssen im Ursprungssystem rotiert werden. Das Hoster-Passwort ersetzt das nicht. Gleiche oder ähnliche wiederverwendete Passwörter ändern Sie nach der offiziellen Empfehlung mit.

Darf ich ein Einmalpasswort als Screenshot an Kolleginnen und Kollegen schicken?

Legen Sie kein lebendes Passwort in einen Bildhoster oder ins Chat-Album. Kurzen Text in diesem Tab mit AES-256-GCM verschlüsseln und über den Einmal-Link senden; der Schlüssel sitzt hinter #, Form s.html?id={id}#{key}. Erstellen und Lesen sind sofort nutzbar, ohne Konto. Material über 32 KB gehört in Datei verschlüsseln, eine Datei höchstens 5 GB, Ausgabe .lock / .enc. Behandeln Sie den Einmal-Link nicht als Laufwerk.

Denselben Canary über einen sofort nutzbaren Kanal schicken

Wenn Sie an einer Seite üben möchten, die die Rechengrenze offen schreibt, öffnen Sie den Einmal-Link von FastPwd. Kein Konto nötig. Schreiben Sie den Canary oben, lassen Sie die Lesezahl bei 1, erzeugen Sie den Link und führen Sie den Network-Vergleich aus dem Prüfabschnitt zu Ende. Der Anfragekörper soll Chiffretext tragen, nicht den Originalsatz und nicht den Schlüssel hinter der Raute. Nutzen Sie diesen Weg nur, wenn ein kurzes Passwort eine andere Person erreichen muss – nicht zuerst den Screenshot.

Stehen im Bild noch Tickettext, Telefonnummer oder Ausweisnummer, maskieren Sie zuerst regelbasiert unter Tracking entfernen und entscheiden Sie dann, ob überhaupt etwas weggeht. Die Schwärzung endet auf diesem Gerät; der Ausgangstext wird nicht als Fachdaten hochgeladen und nicht in Analytics geschrieben. Ein Zufallspasswort erzeugen Sie zuerst im Passwort-Generator, Länge 6–128, Standard 16; unter 8 Zeichen gilt als schwächer. Die Erzeugung wird nicht hochgeladen. Soll die ganze Screenshot-Datei trotzdem raus, zuerst in Datei verschlüsseln zum Chiffretext, die Passphrase allein über den Einmal-Link – nicht in den Bildtitel des Hosters.

Vor dem nächsten Screenshot drei Sätze behalten. Erstens: Der Hash deckt das Hoster-Login, nicht Bild und OCR. Zweitens: Die Image-ID macht aus einem ungelisteten Direktlink keine Zugriffskontrolle. Drittens: Wiederholbar ist nur der pixelweise Blick vor dem Upload und die Canary-Suche in Network, wenn Sie auf den Chiffretext-Kanal wechseln. In Ihre Übergabenotizen gehören nur diese drei Sätze – nicht „der Hoster hasht Passwörter, also ist der Screenshot harmlos“.

Weiterlesen

Der Einmal-Link verbrennt den Chiffretext auf dem Server und beweist nicht, dass die Empfangsseite keinen Screenshot gemacht hat: Warum ein Einmal-Link beweisen kann, dass der Server den Chiffretext gelöscht hat – aber nicht, dass niemand einen Screenshot gemacht hat. Ein ZIP-Passwort vor dem Cloud-Upload hält Dateinamen nicht auf und ist kein lokales AES-GCM: Was ein ZIP-Passwort vor dem Cloud-Upload abdeckt – und warum das kein lokales AES-GCM ist. „Lokal verschlüsselt, nichts hochgeladen“ ist kein Beleg, bis Sie Network mit einem Canary durchsuchen: So prüfen Sie, dass browserlokale Verschlüsselung keinen Klartext sendet.