Pourquoi le texte OCR et les Image ID d’un hébergeur de captures sont plus dangereux qu’un hash de mot de passe

Répondre à l’intention de recherche en une phrase

Le risque de capturer un mot de passe vers un hébergeur d’images n’est pas « le mot de passe de connexion était-il hashé ». C’est de savoir si le cadre lui-même, et le texte extrait de ce cadre, quittent votre machine comme des champs autonomes. Un hash couvre une colonne : la phrase secrète du compte. Le texte OCR, les Image ID, les IP d’envoi, les User-Agent et la localisation EXIF en forment une autre. Une fois ces champs partis, une capture non listée n’est plus protégée par « personne ne peut deviner le lien », et un mot de passe dans l’image n’a plus besoin qu’on casse d’abord un hash.

Cette note s’adresse aux développeurs, à l’exploitation, et à quiconque capture encore une erreur, une console ou une fenêtre de gestionnaire de mots de passe, la dépose chez un hébergeur, puis transmet le lien. Elle ne remplace l’avis d’aucun opérateur, et ce n’est pas un guide pour « couper les captures ». Ce qu’il faut emporter : quelle couche le hash publié couvre, quel modèle de confidentialité une Image ID casse, pourquoi l’OCR se cherche plus facilement que des pixels, et comment comparer la charge avant l’envoi.

Ce que cet avis d’hébergeur a séparé

Le 16 septembre 2026, l’opérateur de Gyazo a publié un avis anglais de Helpfeel, avec une version japonaise le même jour. La chronologie : le 11 septembre, un tiers a utilisé une faille du serveur d’envoi d’images pour exécuter des commandes arbitraires ; une activité inhabituelle a été repérée le soir ; avant l’aube du 12, le chemin d’accès a été coupé et la faille corrigée ; le 14, ils ont confirmé que des données étaient parties et ont suspendu une partie de la diffusion ; le 15, ils ont signalé l’incident à la Commission japonaise de protection des informations personnelles et repris la diffusion des images nouvellement envoyées après correction.

L’avis du 16 septembre scinde le périmètre confirmé en deux blocs. Le premier concerne environ 23,62 millions d’enregistrements liés aux utilisateurs : un nom ou un surnom saisi, l’e-mail, le hash de mot de passe, l’identifiant utilisateur, l’identifiant d’appareil, l’identifiant de session, un jeton d’intégration X si connecté, un e-mail Google SSO si connecté, le profil, la langue, les dates d’inscription et de dernière connexion, l’offre d’abonnement et l’état de facturation. L’avis indique qu’il ne contient pas de numéros de carte ni d’autres moyens de paiement. Ces 23,62 millions d’enregistrements incluent aussi des comptes anonymes sans e-mail enregistré ; le nombre de personnes distinctes est encore à l’étude.

Le second bloc, ce sont les métadonnées d’images. Helpfeel a indiqué que la plus grande part correspond à environ 490 millions de lignes enregistrées en janvier 2019 ou avant (environ 14,4 % de toutes les données liées aux images), plus environ 2,4 millions de lignes supplémentaires tirées avec un autre filtre. Les champs comprennent : l’Image ID utilisée pour construire l’URL de l’image, l’IP source de l’envoi, le User-Agent, la localisation EXIF si le fichier en contenait, le texte OCR extrait de l’image, le titre, l’URL d’origine, et une phrase secrète hashée pour les images privées. Dans cet avis, « images » inclut captures, GIF et vidéos. Helpfeel et Cosense utilisent d’autres systèmes ; à cette date, ils n’avaient pas confirmé de fuite de ces deux-là. Les pages qui embarquent une image Gyazo peuvent échouer à charger parce que la diffusion a été suspendue.

Ce n’est pas une énième histoire « les hash de mots de passe d’un site ont été volés ». Le hash, l’identifiant de session, l’Image ID et le texte OCR sont quatre canaux parallèles. Changer seulement le mot de passe de connexion de l’hébergeur couvre le premier canal, et n’arrête pas les identifiants de session déjà partis — l’avis dit qu’ils ont invalidé et restreint les données d’authentification, et demandé de changer le mot de passe Gyazo ainsi que le même mot de passe, ou un mot proche, réutilisé ailleurs.

Un hash de connexion ne couvre pas le texte en clair à l’écran

Un hash de mot de passe est conçu pour que, une fois la table utilisateurs emportée, un attaquant ne puisse pas lire la phrase secrète de connexion directement et doive encore dépenser du calcul pour la deviner. L’algorithme, le sel et le nombre d’itérations décident de la difficulté de cette couche. Ils ne décident pas si une autre phrase secrète que vous avez capturée dans une image est sûre. Le mot de passe du compte chez l’hébergeur et le mot de passe de la base de production dans la capture n’ont jamais été la même colonne.

Quand un développeur capture un terminal, un champ mot de passe du navigateur, une console cloud ou une fenêtre de gestionnaire, l’hébergeur reçoit des pixels. Beaucoup d’hébergeurs lancent ensuite une reconnaissance de texte et stockent une chaîne OCR interrogeable, pour retrouver « cette capture avec l’erreur ». Une fois le résultat en base, les mots de passe, chaînes de connexion et jetons ne vivent plus seulement dans les octets de l’image. Ils deviennent un champ filtrable par mot-clé. Cet avis a listé « le texte OCR extrait de l’image » comme champ de métadonnées fuité à part entière. Ce n’est pas une hypothèse de fil de commentaires. C’est une colonne formelle.

Donc « les mots de passe étaient stockés en hash » soutient une affirmation étroite : la phrase secrète de connexion de cet hébergeur n’est pas en clair dans la table utilisateurs. Elle ne soutient pas : une clé privée SSH dans une capture exige encore de casser un hash ; une table OCR ne peut pas être cherchée pour BEGIN OPENSSH ou AKIA ; une image privée ne s’ouvre que par vous. Ces dernières phrases demandent d’autres preuves : si les métadonnées incluent OCR et Image ID, et si un secret lisible était à l’écran avant l’envoi.

Pourquoi une Image ID casse le modèle du « lien non listé »

Beaucoup d’hébergeurs de captures implémentent « ne pas partager publiquement » ainsi : l’image n’apparaît pas sur votre profil, et on vous remet un lien direct qui ressemble à des caractères aléatoires. L’hypothèse de sécurité est que, sans l’identifiant, personne ne peut assembler l’URL. C’est une adresse cachée, pas un contrôle d’accès. Quiconque a l’identifiant peut construire la même adresse avec la même règle.

L’avis de Helpfeel nomme l’Image ID « information utilisée pour construire l’URL de l’image », et indique qu’un tiers pourrait s’en servir pour consulter les images correspondantes. Ils ont temporairement désactivé la consultation de certaines images pour cette raison. L’avis confirme aussi qu’une liste identifiant des images privées a été emportée, et qu’ils ne peuvent pas exclure entièrement que certaines images privées aient été consultées. Une liste plus des identifiants retire l’hypothèse « moi seul connais ce lien ».

Même si une image privée avait sa propre phrase secrète, l’avis liste une « phrase secrète hashée ». Un hash ajoute une étape de cassage pour cette phrase. Il ne retire pas automatiquement les pixels à quelqu’un qui a déjà l’identifiant tant que l’hébergeur sert encore par identifiant. Suspendre la diffusion est une vanne côté opérateur. Ce n’est pas la preuve que l’identifiant n’a jamais quitté la base. Écrire « je n’ai jamais collé le lien dans un groupe » comme « l’image n’est pas dans le magasin » mélange la visibilité de l’interface et la visibilité de la couche de stockage.

La localisation EXIF, l’IP d’envoi et le User-Agent forment une troisième couche de contexte. Une photo de téléphone d’un écran ou d’un bureau peut porter du GPS. La requête d’envoi porte une adresse de sortie et un identifiant de client. Même quand les pixels n’affichent aucun numéro de rue, les métadonnées peuvent encore reconstituer qui a envoyé une image, d’où, et avec quel client. Certains outils de capture retirent la localisation ; d’autres non. « J’ai utilisé une capture, pas le pellicule » ne prouve pas que l’EXIF est vide.

Pourquoi l’OCR se réutilise plus facilement que des pixels

Un PNG entier demande encore une personne, ou un modèle de vision, pour trouver un champ mot de passe dans un bureau encombré. Le texte OCR est déjà une chaîne découpée. Après une fuite, chercher password, BEGIN , sk- ou un nom d’hôte interne est d’un ordre de grandeur plus rapide que de feuilleter 490 millions d’images. L’avis ne publie pas le taux de reconnaissance, et n’en a pas besoin : une fois que le magasin détient « le texte extrait de l’image », l’attaquant fait face à un champ texte, pas seulement à des miniatures.

C’est aussi pourquoi « je l’ai mis en non listé » n’arrête pas la couche OCR. L’interrupteur de visibilité contrôle si la page produit liste l’image. L’OCR contrôle si l’hébergeur a transformé le cadre en mots. Les deux peuvent être vrais en même temps : non listé dans l’interface, et un titre, une chaîne OCR et un identifiant en base. Un dump emporte la base, pas l’état de votre bouton de partage.

Ce n’est pas la même affirmation que « le destinataire a fait une capture d’une page à lecture unique ». Une note précédente couvre une copie sur l’appareil du destinataire, que l’hôte ne peut pas effacer en supprimant le texte chiffré. Cette note couvre l’expéditeur qui remet des pixels à un hébergeur, lequel extrait ensuite du texte et attribue un identifiant. D’un côté : « ils ont gardé une copie ». De l’autre : « vous l’avez d’abord remis ». Ni l’un ni l’autre n’est annulé par « le lien a expiré » ou « les mots de passe étaient hashés ».

Contrôler le cadre avant l’envoi, puis la requête

Un slogan n’est pas une preuve. Les étapes suivantes ne contrôlent que deux choses que vous tenez : si les pixels sur le point de quitter cet appareil contiennent un canari, et si le corps de requête d’un outil local doit contenir la phrase d’origine. N’envoyez pas un vrai mot de passe de production vers un hébergeur de captures pour « vérifier » cela.

1. Préparez un canari jetable, par exemple canary-fp-20260920-gyazo-ocr. Saisissez-le dans un bloc-notes vide ou un HTML local, puis capturez. N’y mélangez ni vrai nom d’hôte ni vraie clé.
2. Agrandissez la capture et contrôlez pixel par pixel : le canari est-il entièrement dans le cadre, et y a-t-il une notification de barre d’état, un autre champ mot de passe, ou une ancienne commande de terminal autour ? Tout mot qu’une personne peut lire, l’OCR peut le stocker comme texte.
3. Si vous utilisez encore un hébergeur : ouvrez Network dans les outils de développement, activez Preserve log, puis envoyez. Cherchez le canari dans le corps de requête. Un envoi vers l’hébergeur porte les octets de l’image, donc le canari entre dans le fichier. Il n’entre pas dans la colonne « hash de mot de passe ». C’est précisément le point : le hash ne couvre pas cette image.
4. Comparez l’autre chemin. Ouvrez Burn-Link, écrivez le même canari comme texte, et générez un lien. Cherchez à nouveau dans Network : le corps de POST /secrets doit contenir le texte chiffré, l’expiration et un nombre de lectures — pas la phrase d’origine, et pas la clé après le dièse. La forme du lien est s.html?id={id}#{key} ; la clé n’est qu’après #. La RFC 9110 indique que l’URI cible de la requête n’inclut pas le fragment.

Les trois premières étapes montrent que, sur le chemin capture, le secret quitte cet appareil comme pixels — et comme texte que l’hébergeur peut extraire. La quatrième montre que le même canari peut emprunter « AES-256-GCM sur cet appareil, seul le texte chiffré est envoyé ». Ne mélangez pas les deux chemins : ne capturez pas vers un hébergeur pour coller ensuite ce lien direct dans un lien auto-destructeur, et ne capturez pas l’URL complète du lien auto-destructeur pour renvoyer cette image vers un hébergeur.

Trois façons de trop lire « l’hébergeur est sûr »

Première : traiter « non listé » comme un contrôle d’accès. Que l’interface ne l’affiche pas signifie seulement que le produit ne l’a pas mis sur une liste publique. Si l’Image ID est dans le magasin et que la règle du lien direct est publique, une image jamais partagée peut encore être assemblée. « Une liste d’images privées a été emportée » dans cet avis est un contre-exemple à cette lecture, pas une bizarrerie propre à un seul éditeur.

Deuxième : traiter un changement de mot de passe comme le renouvellement des secrets de la capture. La connexion à l’hébergeur, l’identifiant de session, un jeton OAuth tiers et une clé de production dans le cadre appartiennent à des systèmes différents. La demande officielle de changer le mot de passe Gyazo et tout mot de passe réutilisé ne couvre que les premiers. Si vous avez capturé une console de production, il reste à révoquer des clés, renouveler des comptes de base et invalider des codes de récupération sur le système d’origine. Le testeur de mot de passe local ne peut que comparer une liste publique de mots trop fréquents. Il ne peut pas prouver qu’une chaîne n’est jamais entrée dans la table OCR d’un hébergeur.

Troisième : traiter « j’ai capturé une erreur, pas un mot de passe » comme un cadre propre. Une chaîne de connexion dans un terminal, un token= dans la barre d’adresse, un code de vérification dans une notification, ou une boîte mail dans la fenêtre voisine entrent tous dans la même image. L’OCR ne filtre pas selon votre intention. Avant l’envoi, vous ne pouvez inspecter que le cadre que vous allez envoyer, pixel par pixel. Nommer le fichier error.png n’y change rien.

Questions fréquentes

Si l’hébergeur stocke les mots de passe en hash, ceux de mes captures sont-ils sûrs aussi ?

Ce n’est pas la même couche. Un hash de mot de passe de connexion protège la phrase secrète du compte, et encore faut-il regarder l’algorithme et le sel. Une fois la capture envoyée, l’hébergeur peut aussi stocker le texte OCR, les Image ID, les IP d’envoi et l’EXIF. Les mots de passe, clés et chaînes de connexion dans le cadre sont souvent déjà du texte en clair interrogeable dans la colonne OCR.

Si une capture est non listée et que je ne l’ai jamais partagée, suis-je le seul à pouvoir l’ouvrir ?

« Non listé » signifie en général que l’interface n’a pas mis l’image sur une page publique. Cela ne veut pas dire que personne d’autre ne peut assembler l’adresse. Une Image ID est l’information qui sert à construire l’URL de l’image. Une fois cet identifiant parti avec les métadonnées, un lien direct non listé n’est plus protégé par « on ne peut pas le deviner ». Qu’un opérateur suspende la diffusion signifie seulement que certains identifiants ne récupèrent plus les pixels pour l’instant. Cela ne signifie pas que les métadonnées historiques n’ont jamais été copiées.

Si je change le mot de passe de l’hébergeur, dois-je encore renouveler les secrets apparus dans les captures ?

Traitez-les comme des tâches séparées. Changer le mot de passe de l’hébergeur ne coupe que cette connexion, et n’arrête pas les identifiants de session déjà partis. Les mots de passe de base, clés API, clés privées SSH et codes de récupération apparus dans une capture doivent être renouvelés sur le système d’origine. Changer le mot de passe de l’hébergeur ne remplace pas cela. Si vous avez réutilisé le même mot de passe, ou un mot proche, changez-les aussi, comme l’opérateur l’a demandé.

Puis-je capturer un mot de passe à usage unique et l’envoyer à un collègue ?

N’envoyez pas un mot de passe vivant vers un hébergeur de captures ni vers un album de chat. Chiffrez le texte court dans cet onglet avec AES-256-GCM et passez par Burn-Link, avec la clé après # dans l’URL. La forme est s.html?id={id}#{key}. Créer et lire sont prêts à l’emploi ; aucun compte. Au-delà de 32 Ko, le matériau appartient au chiffrement de fichier, un fichier jusqu’à 5 Go, sortie .lock / .enc. Ne traitez pas un lien auto-destructeur comme un disque.

Déplacer le même canari vers un chemin prêt à l’emploi

Si vous voulez une page qui écrit la frontière de calcul, ouvrez Burn-Link de FastPwd. Aucune inscription. Collez le canari ci-dessus, laissez le nombre de lectures à 1, générez, puis comparez Network comme à la quatrième étape : le corps doit contenir le texte chiffré, pas la phrase d’origine ni la clé après le dièse. N’empruntez ce chemin que lorsqu’un mot de passe court doit atteindre un collègue. Ne le capturez pas d’abord.

Si le cadre contient encore le texte d’un ticket, un numéro de téléphone ou un numéro de pièce, faites un masquage par règles dans le nettoyage de confidentialité avant de décider d’envoyer quoi que ce soit. Le nettoyage se fait sur cet appareil. Le texte source n’est pas envoyé comme donnée métier et n’est pas écrit dans analytics. Vous pouvez d’abord générer un mot de passe aléatoire dans le générateur de mots de passe, en local, longueur 6–128, 16 par défaut ; en dessous de 8, un avertissement indique une sécurité plus faible. La génération n’est pas envoyée. Si un fichier de capture entier doit encore partir, chiffrez-le d’abord dans le chiffrement de fichier, puis envoyez la phrase secrète seule par un lien auto-destructeur. Ne l’écrivez pas dans un titre d’hébergeur.

Avant la prochaine capture, retenez trois faits. Premier : le hash couvre la connexion à l’hébergeur, pas le cadre ni l’OCR. Deuxième : une Image ID signifie qu’un lien direct non listé n’est pas un contrôle d’accès. Troisième : le contrôle répétable, c’est une passe pixel par pixel avant l’envoi, et une recherche Network du canari quand vous passez par un chemin de texte chiffré. Ces trois phrases peuvent entrer dans une note de passation. « L’hébergeur a dit que les mots de passe sont hashés, donc la capture va bien » ne le peut pas.

Pour aller plus loin

Un lien auto-destructeur supprime le texte chiffré sur le serveur. Il ne prouve pas que le destinataire n’a pas fait de capture : voir Pourquoi un lien auto-destructeur peut prouver que le serveur a supprimé le texte chiffré, mais pas que le destinataire n’a pas fait de capture d’écran. Un mot de passe ZIP avant un envoi vers un disque ne cache pas les noms de fichiers et n’est pas de l’AES-GCM local : voir Ce qu’un mot de passe ZIP bloque avant un envoi dans le cloud, et pourquoi ce n’est pas de l’AES-GCM local. « Chiffrement local, rien n’est envoyé » n’est pas une preuve tant que vous n’avez pas cherché un canari dans Network : voir Vérifier que le chiffrement local n’envoie pas le texte en clair.