Luke a Pro

Luke Sun

Developer & Marketer

🇺🇦
EN||

為什麼「加密」不是你以為的那樣安全

| , 2 minutes reading.

1. 為什麼要關心這個問題?

你的資料庫用了 AES-256 加密。你的 API 走 HTTPS。你的密碼都做了雜湊處理。系統一定是安全的,對吧?

不一定。

2011 年,索尼 PlayStation Network 被攻破。他們有加密。2017 年,Equifax 洩露了 1.47 億筆記錄。他們也有加密。問題不在於缺少加密演算法——而在於其他所有環節。

加密是工具,不是解決方案。 在錯誤的地方、用錯誤的方式使用它,或者不理解你真正面對的威脅,就像在一棟窗戶大開的房子上裝銀行保險庫的門一樣。

2. 定義

加密 是使用演算法和金鑰將可讀資料(明文)轉換為不可讀格式(密文)的過程,只有持有正確金鑰的授權方才能逆轉這個過程。

關鍵特性:

  • 可逆性: 與雜湊不同,加密被設計為可逆的(可解密)
  • 金鑰依賴: 安全性依賴於金鑰的保密性,而非演算法的保密性
  • 用途特定: 不同的演算法解決不同的問題

3. 「已加密」與「安全」之間的鴻溝

加密 ≠ 安全

考慮這個場景:

# "安全的"使用者資料儲存
encrypted_data = aes_encrypt(user_data, key)
database.store(encrypted_data)

# 但是金鑰存在哪裡?
key = "hardcoded_in_source_code"  # 災難

資料確實加密了,但是:

  • 金鑰在原始碼裡(任何有儲存庫存取權限的人都能看到)
  • 所有使用者用同一個金鑰(一次洩露 = 全部資料暴露)
  • 沒有金鑰輪換機制
  • 日誌可能在加密前就記錄了明文

如果金鑰管理是破的,加密強度就毫無意義。

什麼是威脅模型?

威脅模型 要回答:「我們在保護什麼,防誰,在什麼條件下?」

問題含義
什麼資料需要保護?決定加密什麼
攻擊者是誰?腳本小子 vs 國家級攻擊者需要不同的防禦
他們的存取層級是什麼?外部攻擊者 vs 惡意內部人員
攻擊面是什麼?網路、實體存取、社交工程
洩露的影響是什麼?決定在安全上投入多少

沒有威脅模型,你只是在隨機新增加密,然後祈禱它有用。

為什麼「加密強度」不是唯一指標

AES-256 在當前技術下被認為是不可破解的。但攻擊者不會攻擊演算法——他們攻擊:

  1. 金鑰管理: 金鑰儲存在哪裡,如何傳輸
  2. 實作: 側通道攻擊、時序攻擊
  3. 人為因素: 釣魚取得憑證、社交工程
  4. 系統架構: 資料加密了但明文記錄在日誌裡
  5. 維運安全: 備份、除錯日誌、錯誤訊息
攻擊難度:
破解 AES-256:████████████████████(幾乎不可能)
竊取金鑰:    ████░░░░░░░░░░░░░░░░(容易得多)
釣魚管理員:  ██░░░░░░░░░░░░░░░░░░(輕而易舉)

4. 現實世界的失敗案例

案例 1:Adobe(2013)

Adobe 加密了 1.53 億個密碼。聽起來不錯,對吧?

問題所在:

  • 使用了 ECB 模式(密文中可見模式)
  • 所有密碼用同一個金鑰
  • 密碼提示以明文儲存在加密密碼旁邊

結果:攻擊者可以透過找到相同的密文區塊來識別常見密碼。提示資訊讓這變得更容易。

案例 2:WEP 協定

WEP(有線等效保密)使用 RC4 加密。演算法本身不是問題。

問題所在:

  • 24 位元 IV(初始化向量)太短
  • IV 以明文傳輸
  • 大約 5000 個封包後,IV 會重複
  • 重複的 IV 允許統計攻擊

結果:無論密碼多複雜,WEP 都可以在幾分鐘內被破解。

案例 3:Heartbleed(2014)

OpenSSL 正確實作了 TLS 加密。加密本身沒問題。

問題所在: 心跳擴充功能中的緩衝區過讀漏洞洩露了伺服器記憶體——包括私鑰、使用者密碼和工作階段權杖。

結果:如果實作有漏洞,最安全的加密也沒用。

5. 建立安全直覺

像攻擊者一樣思考

評估系統安全性時,問自己:

  • 「如果我想竊取這些資料,我會攻擊加密… 還是找更簡單的方法?」
  • 「這個鏈條中最薄弱的環節是什麼?」
  • 「金鑰在哪裡?誰有存取權限?」

安全層次

┌─────────────────────────────────────┐
│           實體安全                  │  ← 資料中心存取
├─────────────────────────────────────┤
│           網路安全                  │  ← 防火牆、VPN
├─────────────────────────────────────┤
│          應用程式安全               │  ← 輸入驗證、認證
├─────────────────────────────────────┤
│          密碼學安全                 │  ← 加密、簽章
├─────────────────────────────────────┤
│          金鑰管理                   │  ← HSM、輪換、存取控制
├─────────────────────────────────────┤
│          維運安全                   │  ← 日誌、監控、回應
└─────────────────────────────────────┘

加密只是其中一層。任何一層被突破都可能危及整個系統。

6. 常見誤區

誤區現實
「256 位元加密是不可破解的」演算法可能是,但你的實作很可能不是
「HTTPS 意味著我的應用程式是安全的」HTTPS 保護傳輸,不保護儲存、邏輯漏洞或認證缺陷
「我加密了資料庫,我們合規了」合規 ≠ 安全;沒有金鑰管理的加密只是表演
「更多加密 = 更多安全」錯誤的加密、錯誤的位置 = 浪費資源和虛假的安全感
「開源加密不夠安全」恰恰相反——審查能發現漏洞;隱蔽只是隱藏它們

7. 實踐要點

新增加密前,先問:

  1. 我在緩解什麼具體威脅?
  2. 金鑰將儲存在哪裡?
  3. 誰需要解密存取權限?
  4. 金鑰如何輪換?
  5. 如果金鑰洩露會怎樣?

正確的心態

不要想:「我怎麼加密這些資料?」
要想:「什麼可能出錯,我如何防止它?」

8. 本章小結

三點要記住:

  1. 加密是必要的,但不充分。 它是全面安全策略中的一個工具,而不是魔法解決方案。

  2. 攻擊者走阻力最小的路。 他們不會破解 AES-256;他們會竊取你的金鑰、釣魚你的管理員、或利用你的漏洞。

  3. 從威脅建模開始。 在選擇工具之前,先理解你在保護什麼以及防誰。

9. 下一步

既然我們理解了加密不是銀彈,下一個問題是:密碼學到底解決什麼問題?

在下一篇文章中,我們將探討密碼學的四個基本目標:機密性、完整性、認證和不可否認性——以及為什麼用錯誤的工具解決錯誤的問題會導致災難。