Сразу вывод: хеш пароля входа на хостинг не останавливает пароль, который уже стал текстом внутри скриншота, и не останавливает прямую ссылку, собранную из Image ID. Смена пароля хостинга закрывает только этот вход. Действующие ключи, которые попали в кадр, нужно сменить в исходной системе. На этом устройстве можно проверить одно: есть ли в пикселях, которые вы собираетесь отправить, читаемый секрет — а не то, стоит ли в уведомлении слово «хеш».
Сначала одним предложением — ответ на запрос
Риск залить скриншот с паролем на хостинг картинок — не в том, «хешировали ли пароль входа». Риск в том, покидают ли само изображение и вытянутый из него текст ваш компьютер отдельными полями. Хеш закрывает одну колонку: фразу аккаунта. OCR-текст, Image ID, IP загрузки, User-Agent и EXIF-координаты — другой набор. Когда они утекают, непубличный скриншот больше не защищён фразой «ссылку не угадать», а пароль на картинке больше не требует сначала взломать хеш.
Заметка для разработчиков, администраторов и всех, кто до сих пор снимает ошибку, консоль или окно менеджера паролей, кидает файл на хостинг скриншотов и пересылает ссылку. Она не заменяет уведомление ни одного сервиса и не учит «выключить скриншоты». Унести отсюда стоит другое: какой слой закрывает опубликованный хеш, какую модель приватности ломает Image ID, почему OCR искать легче, чем пиксели, и как сверить полезную нагрузку до загрузки.
Какие слои развело это уведомление хостинга
16 сентября 2026 оператор Gyazo опубликовал английское уведомление Helpfeel и в тот же день — японскую версию. Хронология: 11 сентября третья сторона через уязвимость сервера загрузки изображений выполняла произвольные команды; аномалию заметили вечером; к раннему утру 12-го путь доступа перекрыли и уязвимость закрыли; 14-го подтвердили, что данные ушли, и приостановили часть раздачи картинок; 15-го сообщили в Комиссию по защите персональных данных Японии и возобновили раздачу файлов, загруженных уже после устранения.
В уведомлении от 16 сентября подтверждённый объём делится на два блока. Первый — около 23,62 млн пользовательских записей: имя или ник, который вводил сам пользователь, почта, хеш пароля, идентификатор пользователя, идентификатор устройства, идентификатор сессии входа, токен интеграции X при подключении, почта Google SSO при подключении, профиль, язык, время регистрации и последнего входа, тариф и статус оплаты. В уведомлении сказано: номеров карт и других платёжных реквизитов нет. В эти 23,62 млн входят и анонимные аккаунты без зарегистрированной почты; сколько именно разных людей затронуто, ещё выясняют.
Второй блок — метаданные изображений. Helpfeel пишет: в основном это около 490 млн строк, зарегистрированных в январе 2019 или раньше (около 14,4% всех данных, связанных с картинками), плюс ещё около 2,4 млн строк, снятых отдельным фильтром. Поля: Image ID, из которого собирают URL картинки; IP источника загрузки; User-Agent; EXIF-координаты, если они были в файле; OCR-текст, извлечённый из изображения; заголовок; исходный URL; хешированная фраза для закрытых картинок. В том уведомлении «изображения» включают скриншоты, GIF и видео. Helpfeel и Cosense живут на других системах; на ту дату утечку из этих двух не подтвердили. Страницы, куда встроена картинка Gyazo, могли не открываться из-за паузы в раздаче.
Это не очередная новость «украли хеши паролей сайта». Хеш, идентификатор сессии, Image ID и OCR-текст — четыре параллельных канала. Смена только пароля входа на хостинг закрывает первый и не останавливает уже ушедшие идентификаторы сессий: в уведомлении сказано, что данные, связанные с аутентификацией, аннулировали и ограничили, и попросили сменить пароль Gyazo плюс такой же или похожий пароль, если его использовали ещё где-то.
Хеш пароля входа не закрывает открытый текст на экране
Хеш пароля задуман так: после кражи таблицы пользователей атакующий не читает фразу входа напрямую и всё равно тратит вычисления на перебор. Алгоритм, соль и число итераций решают, насколько тяжёл этот слой. Они не решают, безопасна ли другая фраза, которую вы сняли картинкой. Пароль аккаунта хостинга и пароль боевой базы на скриншоте никогда не были одной колонкой.
Когда разработчик снимает терминал, поле пароля в браузере, облачную консоль или окно менеджера паролей, хостинг получает пиксели. Многие сервисы затем запускают распознавание и кладут в базу искомую OCR-строку, чтобы потом найти «тот скриншот с ошибкой». Как только результат распознавания попал в таблицу, пароли, строки подключения и токены живут уже не только в байтах картинки. Они становятся полем, которое фильтруют по ключевому слову. В этом уведомлении «OCR-текст, извлечённый из изображения» перечислен отдельным утёкшим полем метаданных. Это не догадка из комментариев. Это штатная колонка.
Поэтому фраза «пароли хранились в виде хеша» тянет только узкий вывод: фраза входа на этот хостинг в таблице пользователей не лежит открытым текстом. Она не тянет выводы: закрытый SSH-ключ на скриншоте всё ещё нужно сначала взломать как хеш; по таблице OCR нельзя искать BEGIN OPENSSH или AKIA; закрытую картинку откроете только вы. Для последних утверждений нужны другие доказательства: есть ли в метаданных OCR и Image ID и был ли на экране читаемый секрет до загрузки.
Не ставьте опыт на настоящем пароле, API-ключе или незамаскированной строке подключения. Подготовьте одноразовую тестовую фразу или кадр, в котором есть только она. Сверяете исходящие пиксели и запрос на предмет этой канарейки — а не отправляете ещё один секрет на хостинг.
Почему Image ID ломает модель «скрытой ссылки»
Многие хостинги скриншотов делают «не публиковать» так: картинку не ставят в профиль и дают прямую ссылку из символов, похожих на случайные. Допущение безопасности: без идентификатора URL не собрать. Это скрытый адрес, а не контроль доступа. У кого есть ID, тот по тому же правилу собирает тот же адрес.
В уведомлении Helpfeel Image ID назван «информацией, из которой собирают URL картинки», и сказано: третья сторона могла использовать эти данные, чтобы открыть соответствующие изображения. Поэтому просмотр части картинок временно отключили. Там же подтверждено: список, по которому опознают закрытые файлы, забрали, и нельзя полностью исключить, что часть закрытых картинок уже смотрели. Список плюс идентификаторы снимают допущение «эту ссылку знаю только я».
Даже если у закрытой картинки была своя фраза, в уведомлении указана «хешированная фраза». Хеш добавляет шаг перебора для этой фразы. Он сам по себе не забирает пиксели у того, у кого уже есть ID, пока хостинг по-прежнему отдаёт файл по идентификатору. Пауза в раздаче — операторский затвор. Это не доказательство, что ID никогда не покидал базу. Написать «я не кидал ссылку в чат» как «картинки нет в хранилище» — значит смешать видимость в интерфейсе с видимостью на слое хранения.
EXIF-координаты, IP загрузки и User-Agent — третий слой контекста. Снимок экрана или стола с телефона может нести GPS. Запрос загрузки несёт исходящий адрес и идентификатор клиента. Даже если на пикселях нет номера дома, метаданные всё равно могут собрать, кто залил картинку, откуда и каким клиентом. Одни инструменты захвата снимают координаты, другие — нет. «Я снял скриншот, а не фото из галереи» не доказывает, что EXIF пуст.
Почему OCR проще использовать повторно, чем пиксели
Целый PNG всё ещё нужно человеку или модели зрения, чтобы найти поле пароля на захламлённом рабочем столе. OCR-текст — уже нарезанная строка. После утечки поиск password, BEGIN , sk- или внутреннего имени хоста на порядок быстрее, чем листать 490 млн картинок. В уведомлении нет точности распознавания — и она не нужна: как только в хранилище лежит «текст, извлечённый из изображения», атакующий смотрит на текстовое поле, а не только на миниатюры.
Отсюда же: «я поставил непубличный» не останавливает слой OCR. Переключатель видимости решает, покажет ли продуктовая страница картинку в списке. OCR решает, превратил ли хостинг кадр в слова. Оба утверждения могут быть истинны сразу: в интерфейсе непублично, а в базе есть заголовок, OCR-строка и ID. Дамп забирает базу, а не состояние кнопки «поделиться».
Это не то же самое, что «получатель снял экран страницы одноразового чтения». В предыдущей заметке речь о копии на устройстве получателя: хостинг её не сотрёт, удалив шифротекст. Здесь отправитель сам отдаёт пиксели хостингу скриншотов, а тот вытягивает текст и выдаёт идентификатор. С одной стороны — «у них осталась копия». С другой — «вы сами сначала отдали». Ни то ни другое не отменяет фраза «ссылка сгорела» или «пароли были в хеше».
| Что вы видите | Какой вывод это тянет | Какой вывод это не тянет |
|---|---|---|
| В уведомлении: пароли хранились в виде хеша | Вход на хостинг в таблице пользователей не открытый текст | Пароль на скриншоте всё ещё нужно сначала взломать как хеш |
| Картинка непубличная, ссылку не слали | Продуктовая страница, скорее всего, не вывела её в общий список | Без ID прямую ссылку никогда не собрать |
| Вы сменили пароль входа на хостинг | Этот один вход уже сменили | Пароли БД и API-ключи на скриншоте тоже мертвы |
| Хостинг приостановил просмотр части картинок | По части ID пиксели сейчас временно не отдают | OCR-текст и исторические метаданные никогда не покидали хранилище |
| Сняли экран ошибки, а не менеджер паролей | Вы считаете, что в кадре нет поля пароля | OCR не вытянет токен, строку подключения или внутренний адрес |
| Оператор аннулировал идентификаторы сессий | Текущие сессии на этом хостинге, возможно, уже не проиграть | Токены X, связки Google SSO и повторно использованные пароли все в безопасности |
Сверьте кадр до загрузки, затем запрос
Слоган — не доказательство. Дальше проверяются только две вещи, которые вы контролируете: есть ли канарейка в пикселях, которые сейчас покинут это устройство, и должно ли тело запроса локального инструмента содержать исходную фразу. Не отправляйте настоящий боевой пароль ни на какой хостинг скриншотов «для проверки».
- Подготовьте одноразовую канарейку, например
canary-fp-20260920-gyazo-ocr. Наберите её в пустой заметке или локальном HTML и снимите это. Не подмешивайте настоящее имя хоста или ключ. - Увеличьте кадр и пройдите по пикселям: канарейка целиком в кадре? Рядом нет уведомления в строке состояния, другого поля пароля, старой команды в терминале? Любое слово, которое читает человек, OCR может положить как текст.
- Если всё же идёте через хостинг скриншотов: откройте в DevTools панель Network, включите Preserve log, затем загрузите. Ищите канарейку в теле запроса. Загрузка на хостинг несёт байты картинки, поэтому канарейка входит в файл. В колонку «хеш пароля» она не входит. В этом и смысл: хеш эту картинку не закрывает.
- Сравните другой путь. Откройте самоуничтожающуюся ссылку, напишите ту же канарейку текстом и создайте ссылку. Снова ищите в Network: в теле
POST /secretsдолжны быть шифротекст, срок и число прочтений — не исходная фраза и не ключ после решётки. Форма ссылки —s.html?id={id}#{key}; ключ стоит только после#. RFC 9110 говорит: целевой URI запроса не включает fragment.
Первые три шага показывают: на пути скриншота секрет покидает это устройство пикселями — и текстом, который хостинг может вытянуть. Четвёртый показывает: ту же канарейку можно провести как «AES-256-GCM на этом устройстве, на сервер уходит только шифротекст». Не смешивайте пути: не заливайте кадр на хостинг и потом не вставляйте эту прямую ссылку в одноразовую; и не снимайте полный URL одноразовой ссылки, чтобы снова отправить картинку на хостинг.
Полную ссылку и шифротекст не ведите одним каналом. Хостинг скриншотов несёт пиксели. Самоуничтожающаяся ссылка несёт шифротекст плюс ключ после #. Если ключ попал в тот же кадр или полную строку s.html?id=…#… вписали в заголовок картинки, защита после решётки уже не действует для того, кто видит это изображение или эту строку метаданных.
Три способа перечитать «хостинг в безопасности»
Первое: принять «непубличный» за контроль доступа. То, что интерфейс картинку не показывает, значит только: продукт не поставил её в общий список. Если Image ID лежит в хранилище, а правило прямой ссылки известно, нерасшаренную картинку всё равно можно собрать. Фраза «забрали список закрытых изображений» в этом уведомлении — контрпример такому чтению, а не особенность одного вендора.
Второе: принять смену пароля за ротацию секретов на скриншоте. Вход на хостинг, идентификатор сессии, чужой OAuth-токен и боевой ключ в кадре принадлежат разным системам. Официальная просьба сменить пароль Gyazo и любой повторно использованный пароль закрывает только первые пункты. Если сняли боевую консоль, ключи всё равно нужно отозвать, учётки базы сменить, коды восстановления аннулировать в исходной системе. Локальная проверка пароля сверяет только публичный список частых слабых паролей. Она не доказывает, что строка никогда не попадала в таблицу OCR хостинга.
Третье: принять «я снял ошибку, а не пароль» за чистый кадр. Строка подключения в терминале, token= в адресной строке, код из уведомления или входящие в соседнем окне входят в ту же картинку. OCR не фильтрует по вашему намерению. До загрузки можно осмотреть только тот кадр, который уйдёт, пиксель за пикселем. Имя файла error.png не помогает.
Частые вопросы
Хостинг пишет, что пароли хранятся в виде хеша. Значит ли это, что пароль на скриншоте тоже в безопасности?
Это разные слои. Хеш пароля входа защищает саму фразу аккаунта — и то насколько хорошо, зависит от алгоритма и соли. После загрузки скриншота хостинг может отдельно хранить OCR-текст, Image ID, IP загрузки и EXIF. Пароли, ключи и строки подключения в кадре часто уже лежат в колонке OCR как открытый текст, по которому можно искать.
Если скриншот непубличный и я никому ссылку не слал, открыть его могу только я?
«Непубличный» обычно значит: интерфейс не вывел картинку на общую страницу. Это не значит, что адрес нельзя собрать. Image ID — информация, из которой собирают URL картинки. Как только идентификатор уходит вместе с метаданными, скрытая прямая ссылка больше не держится на том, что её «не угадать». Пауза в раздаче у оператора значит только: по части ID пиксели сейчас временно не отдают. Это не значит, что исторические метаданные никогда не копировали.
Если я сменил пароль входа на хостинг, нужно ли ещё менять секреты со скриншотов?
Это разные задачи. Смена пароля хостинга обрывает только этот вход и не останавливает уже утёкшие идентификаторы сессий. Пароли БД, API-ключи, закрытые SSH-ключи и коды восстановления, которые попали в кадр, нужно сменить в исходной системе. Замена пароля хостинга это не заменяет. Если использовали тот же или похожий пароль ещё где-то, смените и его — как просил оператор.
Можно ли отправить коллеге одноразовый пароль скриншотом?
Не кладите действующий пароль на хостинг скриншотов и не кидайте его в альбом чата. Короткий текст зашифруйте в этой вкладке алгоритмом AES-256-GCM и передайте самоуничтожающейся ссылкой: ключ стоит после # в адресе. Форма — s.html?id={id}#{key}. Создавать и читать можно сразу, аккаунт не нужен. Материал больше 32 КБ — в шифрование файлов, один файл до 5 ГБ, на выходе .lock / .enc. Не используйте одноразовую ссылку как диск.
Проведите ту же канарейку по пути, который сразу готов
Если нужна страница, где граница вычислений написана открыто, откройте самоуничтожающуюся ссылку FastPwd. Регистрация не нужна. Вставьте канарейку выше, число прочтений оставьте 1, создайте ссылку и сверьте Network как в четвёртом шаге: в теле должен быть шифротекст, а не исходная фраза и не ключ после решётки. Этим путём пользуйтесь только когда короткий пароль должен дойти до коллеги. Сначала не снимайте кадр.
Если в кадре ещё есть текст тикета, телефон или номер документа, сначала прогоните маскирование по правилам в очистке ссылок и только потом решайте, отправлять ли что-то. Очистка идёт на этом устройстве. Исходный текст не уходит как рабочие данные и не пишется в аналитику. Случайный пароль можно сначала собрать локально в генераторе паролей: длина 6–128, по умолчанию 16; короче 8 — пометка, что защита слабее. Генерация не загружается. Если уходить должен весь файл скриншота, сначала зашифруйте его в шифровании файлов, а фразу отправьте отдельной одноразовой ссылкой. Не пишите её в заголовок на хостинге.
Перед следующим кадром оставьте себе три факта. Первое: хеш закрывает вход на хостинг, не кадр и не OCR. Второе: Image ID значит, что скрытая прямая ссылка — это не контроль доступа. Третье: повторяемая проверка — пройти пиксели до загрузки и поискать канарейку в Network, когда переходите на путь шифротекста. Эти три предложения можно положить в памятку для передачи смены. «Хостинг написал, что пароли в хеше, значит скриншот можно» — нельзя.
Что ещё почитать
Самоуничтожающаяся ссылка удаляет шифротекст на сервере. Она не доказывает, что получатель не сделал скриншот: см. Почему самоуничтожающаяся ссылка доказывает, что сервер удалил шифротекст, но не то, что получатель не сделал скриншот. Пароль архива перед загрузкой в облако не прячет имена и это не локальный AES-GCM: см. Что закрывает пароль архива перед загрузкой в облако и почему это не локальный AES-GCM. «Локальное шифрование, ничего не загружается» — не доказательство, пока не поищете канарейку в Network: см. Как проверить, что локальное шифрование в браузере не отправило открытый текст.