先記結論：圖床登入密碼的雜湊，擋不住截圖裡已經變成文字的口令，也擋不住用 Image ID 拼出來的直連。改掉圖床密碼只處理這一家的登入；截圖裡出現過的有效金鑰，必須按原系統輪換。能當場核對的是：即將送出的像素裡有沒有可辨識的口令，而不是公告裡有沒有「雜湊」兩個字。
一句話先回答搜尋意圖
把密碼截進圖床，危險不在「登入密碼是不是雜湊」，而在「畫面本身以及從圖裡抽出來的文字」會不會作為獨立欄位離開你的電腦。雜湊只覆蓋帳號口令這一欄；OCR 文字、Image ID、上傳 IP、User-Agent 和 EXIF 位置是另一組欄位。後者一旦外洩，未公開截圖不再靠「連結猜不到」，畫面裡的口令也不再需要先暴力破解雜湊。
這篇文章給開發者、維運，以及習慣把錯誤畫面、主控台、密碼管理員視窗截進圖床再轉給同事的人——在台灣，這條路常常再經過 LINE 相簿或工作群。它不代替任何一家圖床的事故通報，也不寫成「怎麼關掉截圖」。你要帶走的是：公告裡的雜湊覆蓋哪一層、Image ID 讓哪一種隱私模型失效、OCR 為什麼比像素更容易被搜尋，以及上傳前怎麼對照即將送出的內容。
這次圖床揭露拆開了哪幾層
2026 年 9 月 16 日，Gyazo 營運方 Helpfeel 發布英文通報，並同期發布日文版。時間線寫明：9 月 11 日，第三方利用圖片上傳伺服器的漏洞執行任意指令；當晚發現異常，12 日凌晨前切斷入侵路徑並完成漏洞修復；14 日確認資料已外洩並暫停部分圖片發送；15 日向日本個人情報保護委員會提交報告，並恢復「完成處置後新上傳」圖片的發送。
通報在 9 月 16 日確認的範圍分兩塊。第一塊是使用者相關紀錄約 2362 萬筆，含使用者自行填寫的名稱或暱稱、電子郵件、密碼雜湊、使用者 ID、裝置 ID、登入工作階段 ID、已連結時的 X 整合權杖、Google SSO 關聯電子郵件、個人資料、語言、註冊與最近登入時間、訂閱方案和計費狀態。通報寫明不含信用卡號等付款方式資訊；這 2362 萬筆裡也包括未登記電子郵件的匿名帳號，實際涉及人數仍在調查。
第二塊是圖片中繼資料。通報稱，主要是 2019 年 1 月及更早登記的約 4.9 億筆（約佔全部圖片相關資料的 14.4%），另外還有依條件另行取出的約 240 萬筆。欄位包括：構成圖片 URL 的 Image ID、上傳來源 IP、User-Agent、圖片內若存在則包含的 EXIF 位置、從圖片抽出的 OCR 文字、圖片標題、取得來源 URL（通報寫成取得元 URL），以及非公開圖片口令的雜湊。通報裡的「圖片」包含截圖、GIF 和影片。Helpfeel 與 Cosense 使用不同系統，截至該日未確認這兩套系統外洩；在它們頁面上嵌了 Gyazo 圖的，可能因發送暫停而打不開。
這不是「又一家網站密碼雜湊被拖走」的重複新聞。雜湊、工作階段 ID、Image ID、OCR 文字是四條平行通道。只改圖床登入密碼，只覆蓋第一條，而且擋不住已經外洩的工作階段 ID——通報寫明他們已對驗證相關資訊做失效和限制，並要求使用者修改 Gyazo 密碼以及在其他服務上複用的相同或相似密碼。
登入密碼雜湊擋不住畫面裡的明文
密碼雜湊的設計目標是：庫被拖走之後，攻擊者不能直接讀出登入口令，還要再花計算去撞。演算法、鹽、迭代次數決定這一層有多難，但不決定「你截進圖裡的另一串口令」安不安全。圖床帳號密碼和截圖裡的正式環境資料庫密碼，從來不是同一欄資料。
開發者把終端機、瀏覽器密碼框、雲端主控台或密碼管理員視窗截下來，圖床收到的是像素。許多圖床會再跑一層光學字元辨識，把像素收成可搜尋的 OCR 文字，方便之後搜「那張寫著錯誤訊息的圖」。辨識結果一旦入庫，口令、連線字串、Token 就不再只活在圖片位元組裡，而變成可以依關鍵字過濾的欄位。這次通報把「影像的 OCR 文字」單獨列進外洩中繼資料，說明它不是留言區的猜測，而是庫裡的正式欄。
所以「密碼以雜湊保存」只能支持很窄的結論：圖床這一家的登入口令，在使用者表裡不是明文。它不能支持：截圖裡的 SSH 私鑰還要先破解雜湊；OCR 庫裡搜不到 BEGIN OPENSSH 或 AKIA；非公開圖只有你打得開。後幾句要另找證據：看中繼資料有沒有 OCR 和 Image ID，以及你上傳前畫面上有沒有可辨識的秘密。
不要用真實口令、API Key 或未遮蔽的連線字串做實驗。準備一句只有這次才有的測試文字，或一張只含這句文字的截圖。核對的是即將送出的像素和請求裡有沒有這句金絲雀，不是把憑證再送進圖床。
Image ID 為什麼讓「未公開連結」失效
不少圖床把「不公開分享」做成：不把圖片列進個人主頁，只給你一條看起來像亂數字元的直連。安全假設是：不知道 ID，就拼不出 URL。這是隱藏網址，不是存取控制。誰拿到 ID，誰就能依同一規則拼出網址。
Helpfeel 的通報把 Image ID 寫成「用來構造圖片 URL 的資訊」，並寫明第三者可能用這些資訊存取對應圖片。他們為此暫時關閉了部分圖片的瀏覽。通報還確認，非公開圖片的檔案清單已被取走，不能完全排除部分非公開圖已被查看。清單加 ID，等於把「只有我知道這條連結」這條假設拆掉。
非公開圖即使另設了口令，通報列出的也是「雜湊化的口令」。雜湊讓口令本身多走一步破解；它不讓已經知道 ID、並且圖床仍在依 ID 出圖的人，自動失去像素。圖床暫停發送，是營運側的臨時閘門，不是 ID 從未離開過資料庫的證明。把「連結沒發過 LINE 群」寫成「圖不在庫裡」，是把產品介面的可見性和儲存層的可見性混成一句。
EXIF 位置、上傳 IP 和 User-Agent 是第三層脈絡。手機拍的螢幕或工位環境照，可能帶 GPS；上傳請求會帶出口位址和瀏覽器識別。即使像素裡沒有門牌號碼，中繼資料也能把「誰、從哪、用什麼用戶端傳了一張圖」拼回去。截圖工具有的會去掉位置資訊，有的不會；不能把「我用的是截圖而不是相簿」當成 EXIF 一定為空。
OCR 為什麼比像素更容易被二次利用
一整張 PNG 要人工翻、要跑視覺模型，才能從雜亂桌面裡找出密碼框。OCR 文字是已經切好的字串。外洩之後，搜尋 password、BEGIN 、sk- 或內網主機名稱，比翻 4.9 億張圖快一個數量級。通報沒有公布辨識準確率，也不需要：只要庫裡存了「從圖抽出的文字」，攻擊者面對的就是文字欄位，不是只能看縮圖。
這也解釋了為什麼「我設了非公開」擋不住 OCR 這一層。可見性開關管的是產品頁把不把圖列出來；OCR 管的是圖床有沒有把畫面收成字。兩者可以同時為真：介面上未公開，庫裡卻有標題、OCR 和 ID。拖庫拿走的是庫，不是你的分享按鈕狀態。
和閱後即焚裡「對方截了你的螢幕」不是同一件事。上一篇寫的是接收方裝置上的副本，託管方刪密文也擦不掉。這一篇寫的是發送方自己把像素交給圖床，圖床再抽出文字、編上 ID。一邊是「對方留下了」，一邊是「你先交出去了」。兩邊都不能用「連結失效」或「密碼已雜湊」一筆勾掉。
| 你看見的說法 | 能支持的結論 | 不能支持的結論 |
|---|---|---|
| 公告寫密碼以雜湊保存 | 圖床登入口令在使用者表裡不是明文 | 截圖裡的口令也要先破解雜湊 |
| 圖片設為未公開、沒發過分享 | 產品頁多半沒有把它列進公開清單 | 不知道 ID 的人永遠拼不出直連 |
| 改掉了圖床登入密碼 | 這一家的登入口令已輪換 | 截圖裡的資料庫口令和 API Key 也失效了 |
| 圖床暫停了部分圖片瀏覽 | 現在依部分 ID 暫時取不到像素 | OCR 文字和歷史中繼資料從未離開過庫 |
| 截的是錯誤畫面，不是密碼管理員 | 你以為畫面裡沒有口令框 | OCR 一定抽不出 Token、連線字串或內網位址 |
| 工作階段 ID 已由營運方失效 | 這一家目前工作階段可能已不能重放 | X 權杖、Google SSO 關聯和複用密碼都安全 |
當場對照：上傳前看畫面，送出後看請求
口號不能當證據。下面只核對應由你控制的兩件事：即將離開本機的像素裡有沒有金絲雀；以及若你改走本地工具，請求體裡應不應出現原文。不要把真實正式環境口令送進任何圖床做驗證。
- 準備一句可丟棄的金絲雀，例如
canary-fp-20260920-gyazo-ocr。把它打在一個空白記事本或本地 HTML 裡，截圖。不要混入真實主機名稱或金鑰。 - 放大截圖，依像素核對：金絲雀是否完整入畫，周圍有沒有狀態列通知、另一個密碼框、終端機裡的舊指令。能讀出來的字，OCR 都可能收成文字。
- 若你仍要走圖床：開啟開發者工具的 Network，勾選 Preserve log，再上傳。用金絲雀搜請求體。圖床上傳的是圖片位元組，金絲雀會進檔案，不進「密碼雜湊」那一欄。這恰好證明：雜湊覆蓋不了這張圖。
- 對照另一條通道。開啟 閱後即焚，把同一句金絲雀寫成文字，產生連結。再搜 Network：
POST /secrets的請求體裡應只有密文、過期時間和閱讀次數，不應出現原文，也不應出現井號後的金鑰。連結形態是s.html?id={id}#{key}，金鑰只在#後面；RFC 9110 規定請求目標 URI 不含 fragment。
前三步證明：截圖通道上，秘密以像素（以及圖床可能抽出的文字）離開本機。第四步證明：同一句金絲雀可以改走「本機 AES-256-GCM，只上傳密文」。兩條通道不要混用——不要先截進圖床，再把圖床直連貼進焚鏈；也不要把焚鏈的完整 URL 再截一張圖傳回圖床。
完整連結和密文不要走同一條渠道。圖床傳的是像素，閱後即焚傳的是密文加 # 金鑰。把鑰匙截進同一張圖，或把 s.html?id=…#… 整串寫進圖片標題，井號後的保護對「能看見這張圖或這筆中繼資料的人」已經沒了。
三種把「圖床很安全」讀過頭的情況
第一，把「未公開」當成存取控制。介面不展示，只說明產品沒有把它放進公開清單。Image ID 在庫裡，直連規則又是公開的，未分享過的圖仍然可能被拼出來。通報裡「非公開清單已被取走」是這條誤讀的反例，不是這一家獨有的實作細節。
第二，把改密碼當成輪換截圖裡的秘密。圖床登入口令、工作階段 ID、第三方 OAuth 權杖、畫面裡的正式環境金鑰，分屬不同系統。官方要求修改 Gyazo 密碼以及複用過的相同密碼，只覆蓋前幾項。截過正式環境主控台的，還要去原系統作廢金鑰、輪換資料庫帳號、作廢復原碼。本地 密碼檢測 只能對照公開高頻弱密碼名單，不能證明某串口令沒進過圖床 OCR。
第三，把「我截的是錯誤畫面，不是密碼」當成畫面乾淨。終端機裡的連線字串、瀏覽器網址列裡的 token=、通知裡的驗證碼、隔壁視窗的電子郵件，都會進同一張圖。OCR 不依你的意圖過濾。上傳前只能逐像素看即將送出的那一張，不能靠「檔名寫成 error.png」。
常見問題
圖床說密碼以雜湊保存，截圖裡的口令是不是也安全？
不是同一層。登入密碼雜湊保護的是帳號口令本身，還要看演算法和有沒有加鹽。截圖一旦上傳，圖床還可以另存 OCR 文字、Image ID、上傳 IP 和 EXIF。畫面裡的口令、金鑰、連線字串，在 OCR 庫裡常常已經是可搜尋明文。
未公開、沒分享過的截圖，是不是只有我打得開？
「未公開」通常只表示產品介面沒有把它列進公開頁，不等於別人拼不出網址。Image ID 是構成圖片 URL 的資訊。ID 一旦隨中繼資料離開圖床，未公開直連不再靠「猜不到」。營運方暫停發送，只說明現在部分 ID 暫時取不到像素，不說明歷史中繼資料沒被拷走過。
改掉圖床登入密碼，截圖裡的口令還要不要輪換？
要分開處理。改圖床密碼只切斷這一家的登入口令，且擋不住已經外洩的工作階段 ID。截圖裡出現過的資料庫口令、API Key、SSH 私鑰和復原碼，必須按原系統輪換，不能用改圖床密碼代替。複用過的相同或相似密碼，依官方建議一併改掉。
一次性口令能不能截圖傳給同事？
不要把有效口令截進圖床或聊天相簿。短文字應在目前分頁用 AES-256-GCM 加密後走 閱後即焚，金鑰放在連結的 # 後面，形態是 s.html?id={id}#{key}。建立和閱讀都開啟即用，無需帳號。超過 32 KB 的材料改走 檔案加密盒，單檔案不超過 5 GB，輸出 .lock / .enc，不要把焚鏈當雲端硬碟。
把同一句金絲雀改走開啟即用的通道
若你希望用一個把計算邊界寫清楚的頁面來練習，開啟 FastPwd 的 閱後即焚 即可，無需註冊。寫入上面那句金絲雀，閱讀次數留 1，產生後按第四節對照 Network：請求體裡應只有密文，不應出現原文或井號後的金鑰。必須把短口令交給同事時，才走這條通道，不要先截圖。
畫面裡如果還有工單正文、手機號碼或身分證字號，先在 隱私清洗 裡做規則遮蔽，再決定要不要送出。清洗在本機完成，原文不作為業務資料上傳，也不寫入 analytics。亂數口令可以先在 密碼產生器 裡本地產生，長度 6–128 字元、預設 16 字元；低於 8 字元會提示安全性較低。產生過程不上傳。整份截圖檔若仍要外送，先在檔案加密盒收成密文再傳，口令單獨走焚鏈，不要寫進圖床標題。
下次截圖前記住三件事。第一，雜湊覆蓋的是圖床登入口令，不是畫面和 OCR。第二，Image ID 讓「未公開直連」不再等於存取控制。第三，能重複的觀察是上傳前逐像素核對，以及改走密文通道時用金絲雀搜 Network。能寫進交接說明的，只能是這三句，不能是「圖床說密碼是雜湊，所以截圖沒事」。
延伸閱讀
閱後即焚燒掉的是伺服器上的密文，證明不了接收方沒截圖，見 閱後即焚能證明伺服器刪了密文，為什麼證明不了對方沒截圖。雲端硬碟上傳前只給壓縮檔加密碼，擋不住檔名，也不是本機 AES-GCM，見 雲端硬碟上傳前，壓縮檔密碼能擋住什麼，為什麼它不是本機 AES-GCM。「本地加密、不上傳」不能當證據，要用金絲雀搜 Network，見 瀏覽器本地加密怎麼核對明文沒有離開本機。