账号凭证须加密存储+脱敏展示：存用aes-256等加密，日志和前端对手机号等敏感字段掩码处理（如138**5678），并严控内存、传输、授权及配置泄露风险。

账号凭证这类信息一旦泄露，极易导致账户被盗、数据被拖库甚至身份冒用。保护它们不能只靠“藏起来”，得靠加密存储 + 脱敏展示双保险：存的时候加密，用的时候解密，显示或日志里则必须脱敏。

一、凭证存储必须加密，不能明文落盘

API密钥、数据库密码、用户登录口令等，绝不能以明文形式写进配置文件、数据库字段或SharedPreferences中。哪怕文件权限设为私有，Root或ADB调试环境下仍可能被读取。

• 优先使用平台级安全组件：如Android的Keystore（绑定硬件加密芯片）、Java的JCEKS密钥库、Spring Boot集成的Jasypt或自定义AES-256加解密工具类
• 数据库字段级加密推荐AES-256-CBC或GCM模式，每次加密生成独立IV，并与密文拼接存储（如前16字节为IV，后续为密文）
• 密钥管理是关键：避免硬编码密钥；生产环境应对接KMS（密钥管理服务），支持密钥轮换与权限审计

二、日志和前端展示必须脱敏，防止“无意泄露”

很多安全事件不是来自黑客攻击，而是开发人员在日志里打印了完整token，或接口返回了未处理的手机号。

• 日志中自动过滤：用正则匹配并替换常见凭证格式（如Bearer [a-zA-Z0-9\-_]+、password=.*?），替换成[REDACTED]
• 后端响应脱敏：对敏感字段（如phone、idCard、email）统一加注解（如@Sensitive），通过AOP拦截返回体，执行掩码逻辑（如手机号→138****5678，邮箱→u***@d***.com）
• 前端展示不依赖后端“自觉”：前端也应做二次脱敏（尤其在调试或mock场景下），避免因接口未处理导致信息暴露

三、凭证使用过程要最小化暴露面

加密和脱敏只是防线的一环，凭证在内存中、传输中、授权范围内的管控同样重要。

• 内存中避免长期持有明文：解密后仅在必要时短暂使用，用完立即清空byte[]数组（不要依赖String，它不可变且可能驻留堆中）
• 传输全程走HTTPS/TLS：禁止HTTP传token，禁止URL参数携带密钥（应放Authorization Header或加密body）
• 按需授权：用RBAC或ABAC控制谁能在何时调用哪个凭证相关接口；高危操作（如重置密钥）强制二次认证（MFA）

四、别忽略配置与代码中的“影子风险”

凭证常在不经意间从开发流程中泄露——Git提交、IDE缓存、Docker镜像、错误提示都可能是突破口。

• .gitignore必须包含application-secret.yml、keystore.jks、.env.local等敏感配置文件
• 禁止在异常堆栈或HTTP错误响应中返回原始凭证信息（如“Invalid token: abc123...” → 应统一返回“认证失败”，不透露细节）
• Docker构建时用多阶段构建，确保最终镜像不含密钥文件；CI/CD流水线中凭证通过Secret Manager注入，而非写入脚本