Por qué el texto OCR y el Image ID de un alojador de capturas son más peligrosos que un hash de contraseña

Responde a la intención de búsqueda en una frase

El riesgo de meter una contraseña en un alojador de capturas no es «si el acceso está hasheado». Es si el fotograma y el texto extraído de ese fotograma salen de tu equipo como campos propios. El hash cubre una columna: la contraseña de la cuenta. El texto OCR, el Image ID, la IP de subida, el User-Agent y la ubicación EXIF son otro conjunto. Cuando esos datos se filtran, una captura no listada deja de apoyarse en «nadie puede adivinar el enlace», y la contraseña de la imagen ya no exige romper un hash primero.

Esta nota es para desarrolladores, operaciones y quien sigue capturando un error, una consola o la ventana del gestor de contraseñas, la suelta en un alojador y reenvía el enlace. No sustituye el aviso de ningún operador y no es una guía para «desactivar las capturas». Lo que te llevas es qué capa cubre el hash publicado, qué modelo de privacidad tumba un Image ID, por qué el OCR se busca más fácil que los píxeles, y cómo contrastar el contenido antes de subirlo.

Qué capas separó este aviso del alojador

El 16 de septiembre de 2026, el operador de Gyazo publicó un aviso en inglés de Helpfeel y, el mismo día, una versión en japonés. La cronología: el 11 de septiembre un tercero aprovechó una vulnerabilidad del servidor de subida de imágenes para ejecutar comandos arbitrarios; esa noche detectaron actividad anómala; antes del amanecer del 12 cortaron la vía de acceso y corrigieron la vulnerabilidad; el 14 confirmaron que los datos habían salido y pausaron parte de la distribución; el 15 informaron a la Comisión de Protección de Datos Personales de Japón y reanudaron la entrega de imágenes subidas de nuevo tras la corrección.

El aviso del 16 de septiembre divide el alcance confirmado en dos bloques. El primero son unos 23,62 millones de registros relacionados con usuarios: el nombre o apodo que escribió la persona, correo, hash de contraseña, ID de usuario, ID de dispositivo, ID de sesión, un token de integración de X si estaba conectado, un correo de Google SSO si estaba vinculado, perfil, idioma, fechas de alta y último acceso, plan de suscripción y estado de facturación. El aviso indica que no incluye números de tarjeta ni otros medios de pago. Esos 23,62 millones también incluyen cuentas anónimas sin correo registrado; el número de personas distintas sigue en investigación.

El segundo bloque son metadatos de imagen. Helpfeel indicó que la mayor parte son unos 490 millones de filas registradas en enero de 2019 o antes (alrededor del 14,4 % de todos los datos relacionados con imágenes), más unos 2,4 millones de filas extraídas con otro filtro. Los campos incluyen: el Image ID con el que se construye la URL de la imagen, la IP de origen de la subida, el User-Agent, la ubicación EXIF si el archivo la traía, el texto OCR extraído de la imagen, el título, la URL de origen y un hash de la contraseña de las imágenes privadas. En ese aviso, «imagen» incluye capturas, GIF y vídeo. Helpfeel y Cosense usan sistemas distintos; a esa fecha no habían confirmado una filtración de esos dos. Las páginas que incrustan una imagen de Gyazo pueden no cargar porque la distribución se pausó.

Esto no es otra noticia de «se llevaron los hash de acceso de un sitio». El hash, el ID de sesión, el Image ID y el texto OCR son cuatro canales en paralelo. Cambiar solo la contraseña del alojador cubre el primero, y no detiene un ID de sesión que ya salió: el aviso dice que invalidaron y restringieron la información de autenticación, y pidieron cambiar la contraseña de Gyazo y la misma o una similar reutilizada en otros servicios.

El hash de acceso no cubre el texto en claro de la pantalla

Un hash de contraseña se diseña para que, si se llevan la tabla de usuarios, el atacante no lea la contraseña de acceso en claro y aún tenga que gastar cómputo en adivinarla. El algoritmo, la sal y el número de iteraciones deciden lo dura que es esa capa. No deciden si otra contraseña que metiste en la captura está segura. La contraseña de la cuenta del alojador y la de la base de producción que sale en la imagen nunca fueron la misma columna.

Cuando un desarrollador captura un terminal, un campo de contraseña del navegador, una consola en la nube o la ventana del gestor, el alojador recibe píxeles. Muchos alojadores corren después un reconocimiento de texto y guardan una cadena OCR buscable para encontrar «esa captura con el error». En cuanto el resultado entra en la base, las contraseñas, las cadenas de conexión y los tokens ya no viven solo en los bytes de la imagen. Se convierten en un campo que se filtra por palabra clave. Este aviso listó «texto OCR extraído de la imagen» como un campo de metadatos filtrado por sí mismo. No es una conjetura de un hilo. Es una columna formal.

Así que «las contraseñas se guardan como hash» solo sostiene una afirmación estrecha: la contraseña de acceso de este alojador no está en claro en la tabla de usuarios. No sostiene: que una clave SSH privada de la captura aún exija romper un hash; que en la tabla OCR no se pueda buscar BEGIN OPENSSH o AKIA; que una imagen privada solo la abras tú. Esas últimas frases piden otra prueba: si los metadatos incluyen OCR e Image ID, y si en la pantalla, antes de subir, había un secreto legible.

Por qué un Image ID tumba el modelo del «enlace no listado»

Muchos alojadores implementan «no compartir en público» así: no ponen la imagen en tu perfil y te dan un enlace directo que parece una cadena aleatoria. La hipótesis de seguridad es que, sin el ID, nadie puede armar la URL. Eso es una dirección oculta, no un control de acceso. Quien tenga el ID puede construir la misma dirección con la misma regla.

El aviso de Helpfeel llama al Image ID «información usada para construir la URL de la imagen» y dice que un tercero podría usarla para ver las imágenes correspondientes. Por eso desactivaron temporalmente la visualización de parte de ellas. El aviso también confirma que se llevaron un listado que identificaba imágenes privadas, y no pueden descartar del todo que algunas se vieran. Un listado más los ID retira la hipótesis de «solo yo conozco este enlace».

Aunque una imagen privada tuviera su propia contraseña, el aviso lista un «hash de esa contraseña». El hash añade un paso de descifrado a esa frase. No quita automáticamente los píxeles a quien ya tiene el ID mientras el alojador siga sirviendo por ID. Pausar la distribución es una compuerta del operador. No prueba que el ID nunca salió de la base. Escribir «nunca pegué el enlace en un grupo» como «la imagen no está en el almacén» mezcla la visibilidad de la interfaz con la visibilidad de la capa de almacenamiento.

La ubicación EXIF, la IP de subida y el User-Agent son una tercera capa de contexto. Una foto del móvil de una pantalla o de un puesto puede llevar GPS. La petición de subida lleva una dirección de salida y un identificador de cliente. Aunque los píxeles no muestren un número de portal, los metadatos pueden reconstruir quién subió una imagen, desde dónde y con qué cliente. Algunas herramientas de captura quitan la ubicación; otras no. «Usé una captura, no el carrete» no prueba que el EXIF esté vacío.

Por qué el OCR se reutiliza más fácil que los píxeles

Un PNG entero todavía necesita a una persona, o a un modelo de visión, para encontrar un campo de contraseña en un escritorio lleno. El texto OCR ya es una cadena recortada. Tras una filtración, buscar password, BEGIN , sk- o un hostname interno es un orden de magnitud más rápido que pasar 490 millones de imágenes. El aviso no publica la precisión del reconocimiento, y no hace falta: en cuanto el almacén guarda «texto extraído de la imagen», el atacante mira un campo de texto, no solo miniaturas.

Por eso «la puse como no listada» no detiene la capa OCR. El interruptor de visibilidad controla si la página del producto lista la imagen. El OCR controla si el alojador convirtió el fotograma en palabras. Las dos cosas pueden ser ciertas a la vez: no listada en la interfaz, y un título, una cadena OCR y un ID en la base. Un volcado se lleva la base, no el estado de tu botón de compartir.

Esto no es la misma afirmación que «el destinatario hizo una captura de una página de un solo uso». Una nota anterior cubre una copia en el dispositivo de quien recibe, que el anfitrión no borra al eliminar el texto cifrado. Esta nota cubre que el emisor entrega los píxeles a un alojador, que luego extrae texto y asigna un ID. Un lado es «se quedó con una copia». El otro es «tú lo entregaste primero». Ninguno se cancela con «el enlace caducó» o «las contraseñas iban hasheadas».

Contrasta el fotograma antes de subir, y luego la petición

Un eslogan no es prueba. Los pasos siguientes solo contrastan dos cosas que controlas tú: si los píxeles que van a salir de este equipo contienen un canario, y si el cuerpo de la petición de una herramienta local debería llevar la frase original. No envíes una contraseña real de producción a ningún alojador «para comprobarlo».

1. Prepara un canario desechable, por ejemplo canary-fp-20260920-gyazo-ocr. Escríbelo en un bloc en blanco o en un HTML local y captura eso. No mezcles un hostname real ni una clave.
2. Amplía la captura y mírala píxel a píxel: ¿el canario entra entero? ¿Hay una notificación de la barra, otro campo de contraseña o un comando viejo en un terminal alrededor? Cualquier palabra que una persona pueda leer, el OCR puede guardarla como texto.
3. Si aun así usas un alojador: abre Network en las herramientas para desarrolladores, marca Preserve log y sube. Busca el canario en el cuerpo de la petición. Una subida al alojador lleva bytes de imagen, así que el canario entra en el archivo. No entra en la columna «hash de contraseña». Justo por eso: el hash no cubre esta imagen.
4. Compara el otro canal. Abre Burn-Link, escribe el mismo canario como texto y genera un enlace. Busca otra vez en Network: el cuerpo de POST /secrets debería llevar texto cifrado, caducidad y número de lecturas, no la frase original ni la clave que va tras la almohadilla. La forma del enlace es s.html?id={id}#{key}; la clave solo va detrás de #. RFC 9110 indica que el URI de destino de la petición no incluye el fragmento.

Los tres primeros pasos muestran que, en el canal de la captura, el secreto sale de este equipo como píxeles —y como texto que el alojador puede extraer—. El cuarto muestra que el mismo canario puede ir por «AES-256-GCM en este dispositivo, solo se sube texto cifrado». No mezcles los dos caminos: no subas primero al alojador y luego pegues ese enlace directo en un Burn-Link, y no captures la URL completa del Burn-Link para devolver esa imagen al alojador.

Tres formas de leer de más «el alojador es seguro»

Primero, tratar «no listada» como control de acceso. Que la interfaz no la muestre solo significa que el producto no la puso en una lista pública. Si el Image ID está en el almacén y la regla del enlace directo es pública, una imagen no compartida se puede armar igual. «Se llevaron un listado de imágenes privadas» en este aviso es un contraejemplo de esa lectura, no un detalle exclusivo de un proveedor.

Segundo, tratar el cambio de contraseña como la rotación de los secretos de la captura. El acceso al alojador, el ID de sesión, un token OAuth de un tercero y una clave de producción del fotograma pertenecen a sistemas distintos. La petición oficial de cambiar la contraseña de Gyazo y cualquier contraseña reutilizada cubre solo las primeras. Si capturaste una consola de producción, aún tienes que revocar claves, rotar cuentas de base e invalidar códigos de recuperación en el sistema original. El comprobador de contraseñas local solo contrasta una lista pública de contraseñas débiles frecuentes. No puede demostrar que una cadena nunca entró en la tabla OCR de un alojador.

Tercero, tratar «capturé un error, no una contraseña» como un fotograma limpio. Una cadena de conexión en el terminal, un token= en la barra de direcciones, un código de verificación en una notificación o la bandeja de correo de la ventana de al lado entran en la misma imagen. El OCR no filtra por tu intención. Antes de subir solo puedes inspeccionar el fotograma que vas a enviar, píxel a píxel. Ponerle de nombre error.png no ayuda.

Preguntas frecuentes

Si el alojador guarda las contraseñas como hash, ¿la contraseña de la captura también está segura?

No es la misma capa. El hash de acceso protege la contraseña de la cuenta, y aún así depende del algoritmo y de si lleva sal. En cuanto subes la captura, el alojador puede guardar además texto OCR, Image ID, IP de subida y EXIF. La contraseña, la clave o la cadena de conexión que aparecen en pantalla suelen ser ya texto en claro buscable en la columna OCR.

Si la captura no está listada y no la he compartido, ¿solo yo puedo abrirla?

«No listada» suele significar que la interfaz no la pone en una página pública. No significa que nadie más pueda armar la dirección. El Image ID es la información con la que se construye la URL de la imagen. Cuando ese ID sale con los metadatos, el enlace directo no listado deja de apoyarse en «nadie puede adivinarlo». Que el operador pause la distribución solo significa que algunos ID no pueden pedir píxeles por ahora. No significa que los metadatos históricos nunca se copiaran.

Si cambio la contraseña del alojador, ¿tengo que rotar también lo que salía en las capturas?

Trátalo como dos trabajos. Cambiar la contraseña del alojador solo corta el acceso a esa cuenta y no detiene un ID de sesión que ya se filtró. Las contraseñas de base de datos, API Key, claves SSH privadas y códigos de recuperación que aparecieron en una captura hay que rotarlos en el sistema original. Cambiar la contraseña del alojador no sustituye eso. Si reutilizaste la misma o una similar, cámbiala también, como pidió el operador.

¿Puedo hacer una captura de una contraseña de un solo uso y enviársela a un compañero?

No metas una contraseña viva en un alojador de capturas ni en el álbum de un chat. Cifra el texto corto en esta pestaña con AES-256-GCM y envíalo por Burn-Link, con la clave detrás de #. La forma es s.html?id={id}#{key}. Crear y leer están listos para usar, sin cuenta. Si el material supera 32 KB, pásalo a la caja de cifrado: un archivo de hasta 5 GB, salida .lock / .enc. No uses un Burn-Link como disco.

Pasa el mismo canario por un canal listo para usar

Si quieres una página que deja por escrito el límite de cálculo, abre el Burn-Link de FastPwd. Sin registro. Pega el canario de arriba, deja el recuento de lecturas en 1, genera y contrasta Network como en el cuarto paso: el cuerpo debería llevar texto cifrado, no la frase original ni la clave que va tras la almohadilla. Usa este canal solo cuando una contraseña corta tenga que llegar a un compañero. No la captures antes.

Si el fotograma aún tiene texto de un ticket, un teléfono o un número de documento, pasa primero un enmascarado por reglas en la limpieza de privacidad y después decide si envías algo. La limpieza ocurre en este dispositivo. El texto original no se sube como dato de negocio y no se escribe en analytics. Puedes generar antes una contraseña aleatoria en el generador de contraseñas, en local, de 6–128 caracteres, 16 por defecto; por debajo de 8 se marca como menos segura. La generación no se sube. Si un archivo de captura entero aún tiene que salir, cífralo primero en la caja de cifrado y manda la contraseña por Burn-Link aparte. No la escribas en el título del alojador.

Antes de la próxima captura, quédate con tres hechos. Primero, el hash cubre el acceso al alojador, no el fotograma ni el OCR. Segundo, un Image ID significa que un enlace directo no listado no es control de acceso. Tercero, la observación repetible es un pase píxel a píxel antes de subir, y buscar el canario en Network cuando cambias al canal de texto cifrado. Esas tres frases sí pueden ir en una nota de relevo. «El alojador dijo que las contraseñas van hasheadas, así que la captura no pasa nada» no.

Lecturas relacionadas

Un enlace de un solo uso borra el texto cifrado del servidor. No prueba que el destinatario no hiciera una captura: véase Por qué un enlace de un solo uso puede demostrar que el servidor borró el texto cifrado, pero no que el destinatario no hizo una captura. Una contraseña ZIP antes de subir a la nube no oculta los nombres y no es AES-GCM local: véase Qué bloquea una contraseña ZIP antes de subir a la nube, y por qué no es AES-GCM local. «Cifrado local, no se sube» no es prueba hasta que buscas un canario en Network: véase Cómo comprobar que el cifrado local del navegador no envió el original.