java实现禁止使用最近的密码_Java中提高密码的安全性（禁止直接使用String），Spring Boot中有哪些现实的方案？...

String还是String，但不能让明文的密码在服务器的任何地方活过一个请求的生命周期，并且不能让它在网线里以明文的形式传输。Spring怎么处理我不知道，但是不管什么语言什么框架，大致思路都是一样的：传输层要用TLS，且证书必须由受信任的CA签过名。cipher推荐使用ECDHE-RSA-AES256-GCM-SHA384或DHE-RSA-AES256-GCM-SHA384，如果你的web app的客户端有手机或物联网设备，还可以加入ECDHE-RSA-CHACHA20-POLY1305，保证数据在网络里传输时不会被窃听和被篡改。而且上述几个cipher有前向保密(forward secrecy)的特性，保证即使某个请求的密钥泄漏了，也只影响到这一个请求，不会影响过去或未来的请求。为了达到相同的加密强度，ECDHE比DHE使用更小的key，因此更节省内存和CPU。

服务器接受到的密码还是原始密码，然后服务器必须把密码散列化(hashing)后存入数据库。散列算法推荐使用Argon2d，退而求其次可以用BCrypt，绝对不要用MD5和SHA1，甚至不要用SHA256，PBKDF2在可以显卡辅助运算的今天也已经被认为不够强了。为了防内贼，对密码绝对不要用“加密”(可以解得回来的那种)，而是用“散列化”(就算有密钥也解不回来的那种)。

确保用户的密码，无论是明文的还是散列化后的，都不会出现在任何HTTP响应里。

确保用户的密码，无论是明文的还是散列化后的，都不会出现在任何日志(log)里。

勘误：

DH-xxx 和 ECDH-xxx 不能保证前向保密，因为它们的密钥不保证是每次连接随机生成的。请用改良后的DH和ECDH，即DHE和ECDHE版本的cipher。

另外，TLS 1.3 已经抛弃了所有不支持前向保密的cipher，所以如果有条件请务必使用TLS 1.3

更新：如果不需要降级到TLS 1.2，你可以直接用TLS 1.3的cipher。

TLS 1.2 中证书校验可以使用ECDSA代替RSA，理由也是密钥长度可以从2048减小到256，从而节省内存和CPU

对称加密+签名可以用CHACHA20-POLY1305来替代AES256-GCM，因为AES存在被cache-timing attack的漏洞，而CHACHA20没有，另外CHACHA20的计算采用位运算，对CPU比较友好，而AES用得是查表，对没有硬件提速的CPU(例如安卓手机)不太友好。

结论：目前较好的TLS 1.3的cipher是 TLS_CHACHA20_POLY1305_SHA256，TLS 1.2的cipher是 ECDHE-ECDSA-CHACHA20-POLY1305