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. 下一步

既然我们理解了加密不是银弹,下一个问题是:密码学到底解决什么问题?

在下一篇文章中,我们将探讨密码学的四个基本目标:机密性、完整性、认证和不可否认性——以及为什么用错误的工具解决错误的问题会导致灾难。