密码修改须前端哈希（如sha-256）加动态salt（如userid+timestamp）后传输，禁用base64、md5/sha-1、url传参等不安全方式，并配合https、csrf防护与操作审计。

用户修改密码时，前端不能直接明文传输密码，必须加密后再发送。核心原则是：密码在传输前加密，服务端解密或校验；但更推荐的是前端加盐哈希（非对称加密仅用于特定场景），避免密码明文经过网络。

优先使用 HTTPS + 前端哈希（推荐方案）

HTTPS 已解决传输层窃听问题，此时重点应是防止服务端日志、数据库泄露导致密码明文暴露。因此，前端应在提交前对密码做不可逆哈希（如 SHA-256），并加入动态 salt（如用户唯一 ID 或时间戳拼接）：

• 调用修改密码接口前，用 CryptoJS 或 Web Crypto API 对新密码进行哈希处理，例如：sha256(userId + newPassword + timestamp)
• 将哈希结果作为 newPasswordHash 字段传给后端，原始密码不上传
• 后端收到后，用相同规则重新计算哈希，并与用户当前密码哈希比对（验证旧密码）；再将新哈希存入数据库
• 注意：salt 必须参与前后端一致的计算逻辑，且不能固定（避免彩虹表攻击）

敏感场景下补充非对称加密（如无 HTTPS 或合规要求高）

若环境无法保证 HTTPS（如内网老旧系统），可引入 RSA 加密增强安全性：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 页面加载时，向服务端请求公钥（如 /api/auth/public-key），缓存至内存（不存 localStorage）
• 用户点击“确认修改”后，用公钥加密新密码（需先转为 UTF-8 字节数组，再加密），生成密文字符串
• 将密文传给修改接口，服务端用私钥解密后，再做常规校验与存储
• 注意：RSA 有长度限制（如 2048 位公钥最多加密 245 字节），长密码需先哈希再加密，或改用 AES+RSA 混合加密

必须规避的错误做法

以下方式看似“加密”，实则严重降低安全性，应禁止：

• 仅用 Base64 编码密码——本质是编码，不是加密，等同于明文
• 前端硬编码固定 salt 或密钥——密钥泄露即全站密码可被破解
• 用 MD5/SHA-1 哈希原始密码——已被证明不安全，且无 salt 时极易被撞库
• 在 URL 参数中传递密码字段——可能被代理、CDN、浏览器历史记录留存

配套建议：提升整体安全性

加密传输只是环节之一，还需配合其他措施：

• 接口启用 CSRF Token 验证，防止跨站修改密码请求
• 修改密码前强制验证原密码（哈希比对）或二次认证（短信/邮箱验证码）
• 前端对密码输入做基本强度校验（长度、大小写、数字），减少弱密码提交
• 后端记录修改操作日志（IP、时间、用户 ID），便于审计追溯

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南