EMAIL · 需要在客服场景取回
aria@example.com → enc:AES-GCM:••••加密存储 · KMS 管密钥；有权限时才能还原。
数据与服务 · 账号与安全
加密Encryption
按数据要不要取回决定保护手段：要取回的敏感字段用密钥可逆加密；密码只需验证，使用慢哈希 + salt 并重哈希比对；浏览器到服务端的传输交给 TLS。
把账号资料安全地送过发布门禁
先处理同一份新用户资料：邮箱需要取回所以加密，密码只需验证所以选慢哈希；故意选错会让发布被阻止，并可在原对象上恢复。
发布前检查 · 新用户资料
选择密码的存储方式，让账号资料可以安全上线
account / new-signup同一份资料，不同保护目的
PASSWORD · 登录只需要验证
orchid-pine → 待决定 · 还不能上线请选择存法：这里的目标是验证，不是取回原密码。
IN TRANSIT · 浏览器到服务端
HTTPS / TLS → 会话密钥保护传输传输走 TLS，不在应用里自造“整包加密”。
现在处理 PASSWORD：它只需判断登录输入是否相同，不需要把原文取回。
发布门禁等待密码方案
先完成密码保护决策。
键盘：按 Tab 定位方案，再按 Enter 选择。结果会直接写回资料记录与发布门禁；颜色只加强“待定 / 阻止 / 就绪”的文字状态。
工作台刚刚证明的三条判断
不是“敏感数据一律加密”，而是按是否需要取回和所处链路来决定。
- 需要取回的敏感字段才用可逆加密。邮箱、实名或业务上需要恢复的卡号等可用受审库的 AES-GCM；密钥交给 KMS / secret manager，解密权限最小化。
- 密码必须是单向慢哈希，不是加密。使用 argon2id、bcrypt 或 scrypt 加独立 salt；登录只把输入重哈希后比较摘要，从设计上不存在“解密密码”的按钮。
- 传输交给 TLS / HTTPS。TLS 以非对称机制建立会话，再用对称会话密钥传数据；不要自己拼算法、随机数或应用层“整包加密”。
什么时候用：先问“以后要取回吗？”
这个问题能把加密、哈希和传输保护分开，避免把“不可读”误当成一种万能手段。
- 要取回：采用带认证的加密（如 AES-GCM），密钥从 KMS / secret manager 读取、可轮换和撤销；记录敏感解密访问。
- 只验证：采用慢哈希 + salt；普通 SHA-256 太快，不能替代密码哈希。API secret 等校验值也要按其验证模型设计，别默认做成可逆。
- 在传输中：强制 HTTPS / TLS、HSTS 和安全的 Cookie / token 配置；不要把凭据放进 URL、日志或前端 bundle。
从资料清单到可验证实现
把分类、算法与密钥来源写进同一份可审计的方案。
- 列出每个敏感字段，标注“要取回 / 只验证 / 仅传输”；不要用“加密一下”作为需求。
- 需要取回的字段使用受审库的 AES-GCM，密钥只以标识引用并交给 KMS / secret manager 管理。
- 密码使用 argon2id / bcrypt + 独立 salt 和合适 cost；测试断言登录流程只会重哈希比对，不会还原密码。
- 在 TLS 下传输，测试篡改拒绝、密钥轮换与日志脱敏；不要自己实现加密、哈希或 TLS。
同一目标“存登录密码”：只改存法，风险就不同
两种方案都让数据库里看不到明文，但只有一种符合“不需要取回”的目标。
stored = argon2id(password, salt)登录时重哈希比较摘要。即使数据库泄漏，也没有可用来还原密码的解密路径；慢哈希和独立 salt 会抬高暴试成本。
stored = AES-GCM(password, key)它让密码变得可以取回，这是不必要的能力。密钥或解密权限一旦泄漏，风险会从单个账户扩大到整库密码。
快速自测
支付资料需要按权限取回完整号码，登录密码只需判断对不对；两者应如何处理？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。
用到这个知识点的案例
看看真实的项目蓝图里，加密是怎么被用上的。