返回部落格
隱私安全技術科普

2026 一次性連結真的安全嗎？閱後即焚的密碼學原理與 4 種實作比較

發佈於16 min read
分享文章

很多人忽略了：「閱後即焚」不等於「安全」

閱後即焚（burn-after-read）功能在近幾年越來越流行。從傳送密碼到分享私密照片，很多人把一次性連結當作安全的代名詞。但你可能不知道——不同服務的「閱後即焚」實現方式差異巨大，有些在技術上根本無法保證資料被真正銷毀。若你關心的是照片中 EXIF 洩漏的風險，可以先看 EXIF 隱私風險與防護方法，兩者往往要搭配使用才能完整防護。

這篇從密碼學與系統架構的角度，拆解一次性連結的三種主要實現方式，分析各自的安全強度和弱點。

一次性連結的三種實現模式

模式一：純伺服器端刪除（Token-Based）

這是最簡單也最常見的實現方式：

  1. 使用者上傳內容，伺服器儲存原始資料並生成一個唯一的 Token（通常是 UUID 或隨機字串）
  2. 伺服器返回包含 Token 的連結（例如 https://example.com/view/abc123）
  3. 第一個訪問者開啟連結時，伺服器返回內容並標記該 Token 為已使用
  4. 後續訪問者再用同一個連結，伺服器回傳「已過期」

安全分析：

這種模式的根本問題是伺服器持有明文資料。在內容被「銷毀」之前，以下角色都能存取原始內容：

  • 伺服器管理員
  • 資料庫管理員
  • 任何取得伺服器存取權限的攻擊者
  • 備份系統（如果有定期備份，「已刪除」的資料可能仍存在於備份中）
  • 法院傳票或政府機關要求

務必注意：即使伺服器端在「閱讀後」執行了刪除操作，在現代儲存系統中，「刪除」通常只是標記為可覆寫，資料在被物理覆寫之前仍可恢復。SSD 的 TRIM 操作和磁碟的磁性殘留都是已知的資料恢復途徑。

模式二：客戶端加密（Encryption-Based / Zero-Knowledge）

這是安全性最高的實現方式，以 PrivNote 和 Firefox Send（已停止服務）為代表：

  1. 使用者在瀏覽器中輸入內容
  2. 瀏覽器端生成一個隨機的 AES-256 金鑰
  3. 使用該金鑰在瀏覽器端加密內容
  4. 加密後的密文上傳到伺服器
  5. 伺服器儲存密文，但不持有金鑰
  6. 金鑰附加在連結的 URL fragment（# 之後的部分）中

例如：https://example.com/view/abc123#encryption-key-here

關鍵的密碼學設計：URL fragment（# 後面的內容）不會被傳送到伺服器。這代表伺服器始終只看到密文，永遠不知道金鑰，因此無法解密內容。這就是所謂的零知識架構（Zero-Knowledge Architecture）。

接收者開啟連結後：

  1. 瀏覽器從伺服器取得密文
  2. 從 URL fragment 取得金鑰
  3. 在瀏覽器端解密
  4. 伺服器刪除密文

安全分析：

這種模式下，即使伺服器被入侵，攻擊者取得的也只是無法解密的密文。但仍存在以下威脅：

  • 瀏覽器擴充功能：惡意擴充功能可能讀取完整的 URL（包含 fragment）
  • 瀏覽歷史紀錄：完整的 URL（含金鑰）可能被記錄在瀏覽器歷史中
  • Referrer Header 洩漏：如果頁面包含外部資源，部分瀏覽器可能在 Referrer 中洩漏 URL fragment（現代瀏覽器已大幅改善此問題）
  • JavaScript 供應鏈攻擊：如果加密邏輯的 JS 檔案被竄改，金鑰可能被偷偷傳送到攻擊者的伺服器

模式三：混合模式（Hybrid）

結合伺服器端控制和客戶端加密：

  1. 客戶端加密（同模式二）
  2. 伺服器端設定存取限制（一次性 Token + 存取密碼 + 過期時間）
  3. 多重認證（例如需要輸入密碼才能取得密文）
  4. 伺服器在存取後刪除密文，同時記錄稽核日誌（但不記錄內容）

這種模式在安全性和可用性之間取得了最佳平衡。

威脅模型分析：閱後即焚防不住什麼？

不論使用哪種實現方式，以下威脅是閱後即焚機制無法防禦的：

截圖與螢幕錄影

這是最根本的限制。只要內容被渲染在接收者的螢幕上，任何防護都無法阻止截圖、拍照或螢幕錄影。部分服務嘗試用 JavaScript 禁止右鍵或截圖快捷鍵，但這些措施在技術上是完全可以被繞過的，只能防止最不具技術知識的使用者。

CDN 和代理快取

如果一次性連結的內容透過 CDN 分發，CDN 節點可能快取了內容副本。即使源伺服器已刪除資料，CDN 快取可能仍在 TTL（存活時間）內保留副本。這是很多服務忽略的隱患。

正確的做法是對一次性內容設定 Cache-Control: no-store, no-cache, must-revalidate 和 CDN-Cache-Control: no-store，確保 CDN 不快取這類內容。

瀏覽器快取

瀏覽器可能將已解密的內容快取在本地磁碟。圖片尤其容易被快取——瀏覽器的圖片快取機制通常獨立於頁面快取控制。

網路監控（中間人攻擊）

如果使用的是純 Token 模式（模式一），且連線未使用 HTTPS，網路中的任何中間人（ISP、公司防火牆、惡意 WiFi 熱點）都能看到明文內容。

即使使用 HTTPS，企業環境中的 SSL Inspection 設備可能會解密並記錄流量。客戶端加密模式（模式二）可以防禦這種情況，因為即使 HTTPS 被攔截，攻擊者取得的仍然只是密文。

伺服器端日誌

即使內容本身被正確刪除，伺服器的存取日誌可能記錄了 URL、IP 位址、時間戳記和 User-Agent。在純 Token 模式下，這些日誌可以用來關聯「誰在什麼時候從哪裡存取了什麼連結」。

主流閱後即焚服務的安全性比較

根據各服務公開的技術文件和原始碼分析，以下是截至 2026 年 3 月的比較：

服務 加密模式 開源 金鑰存放位置 伺服器是否能讀取明文 密碼保護 最大限制
PrivNote 客戶端 AES 否 URL fragment 否（零知識） 否 純文字
1ty.me 伺服器端 否 伺服器 是 可選 純文字
Snappass (Pinterest) 伺服器端 AES 是 URL path 是（金鑰經過伺服器） 可選 純文字
hat.sh 客戶端 XChaCha20 是 URL fragment 否（零知識） 否 檔案
OnionShare 客戶端 + Tor 是 本地產生 否 可選 檔案
Yopass 客戶端 OpenPGP 是 URL fragment 否（零知識） 否 純文字 + 檔案

值得注意的是，開源是判斷安全性的重要指標。非開源的服務可以聲稱使用客戶端加密，但使用者無法驗證。開源的服務至少允許技術社群審計其加密實現是否正確。

一次性連結的正確使用方式

基於以上分析，以下是實際使用一次性連結時的建議：

適合使用一次性連結的場景

  • 傳送一次性密碼或存取憑證
  • 分享敏感但時效性短的資訊
  • 不希望內容長期存在於聊天記錄中的溝通

不適合使用一次性連結的場景

  • 涉及高度機密的商業資訊（應使用端對端加密通訊）
  • 需要法律等級不可否認性的場景（一次性連結銷毀後無法舉證）
  • 涉及國家安全等級的敏感資訊（應使用離線傳輸）
  • 歐盟使用者個資處理（仍需符合 GDPR 圖片合規 要求）

強烈建議的安全實踐

  1. 優先選擇客戶端加密的服務——確保伺服器無法讀取你的內容
  2. 優先選擇開源的服務——可驗證其安全聲明
  3. 搭配密碼保護——即使連結被截獲，沒有密碼也無法存取
  4. 使用不同管道傳送連結和密碼——例如連結透過 Email，密碼透過 LINE
  5. 不要在公司網路中傳送極敏感的內容——SSL Inspection 可能解密你的流量

lpic.cc 的密碼保護功能

在圖片分享的場景中，lpic.cc 提供了密碼保護功能——上傳圖片時設定密碼，只有輸入正確密碼的人才能查看圖片。

需要誠實說明的是，lpic.cc 的密碼保護功能屬於伺服器端存取控制（類似上述模式一），而非客戶端零知識加密（模式二）。這意味著：

  • 伺服器端仍持有原始圖片資料
  • 密碼保護的作用是存取控制，不是端對端加密
  • 適合「不希望任意人都能打開連結」的日常隱私需求
  • 不適合需要密碼學等級安全保證的高敏感場景

如果你的需求是日常圖片分享中避免連結被隨意傳閱，lpic.cc 的密碼保護是方便且實用的選擇。但如果你需要的是軍事等級的安全性，應該使用專門的端對端加密工具。若要進一步確認你選的圖床是否會偷偷保留 EXIF，可以參考 各圖床 EXIF 保留實測 的逐欄位結果。

常見問題 FAQ

Q1：閱後即焚連結被開啟後，資料真的不可恢復嗎？

取決於實現方式。純伺服器端刪除模式下，資料可能仍存在於備份、CDN 快取或未覆寫的磁碟區塊中。客戶端加密模式下，即使密文未被完全刪除，只要金鑰已銷毀（URL 不再存在於任何地方），密文在密碼學上是不可恢復的。但接收者螢幕上已渲染的內容無法被追回。

Q2：瀏覽器的無痕模式能增加一次性連結的安全性嗎？

可以在一定程度上幫助。無痕模式不會保留瀏覽歷史、Cookie 和本地快取，這意味著包含金鑰的 URL 不會被記錄在本機。但無痕模式不防禦網路層的監控（ISP、企業防火牆），也不防禦螢幕截圖。

Q3：「自毀倒數」功能（例如 30 秒後自動關閉）真的有用嗎？

安全效果有限。自毀倒數只是在瀏覽器端用 JavaScript 計時後清除頁面內容，任何人都可以在倒數結束前截圖，或直接用瀏覽器開發者工具（DevTools）停止計時器。它的主要價值是心理層面——提醒接收者「這是敏感內容」，而非技術層面的安全防護。

Q4：一次性連結能防止轉發嗎？

不能。只要接收者在存取前把連結轉發給其他人，其他人就能代替原本的接收者開啟內容。搭配密碼保護可以降低這個風險（轉發者需要同時知道連結和密碼），但仍無法阻止接收者在開啟後截圖或複製內容再轉發。

Q5：企業環境中使用一次性連結傳送密碼安全嗎？

比明文傳送好得多，但要注意企業環境的特殊風險。許多企業部署了 SSL Inspection（TLS 解密重加密），意味著 IT 部門可以看到 HTTPS 流量的內容。如果使用客戶端加密模式的服務，內容經過額外一層加密，即使 TLS 被解密，IT 部門看到的仍是密文。建議在企業環境中優先使用 Yopass、hat.sh 等客戶端加密的開源方案。

參考資料

#閱後即焚#一次性連結#密碼學#資料安全#隱私保護
K

作者

Kevin Wu

資安顧問

關注隱私保護與資料安全，幫你避開圖片分享的隱藏風險。