Spring Security使用String处理密码是否存在Java安全风险？

在查看Spring Security的DaoAuthenticationProvider实现逻辑时，我发现框架将凭据信息以String类型存储，对应示例代码如下：

String presentedPassword = authentication.getCredentials().toString();

根据安全开发最佳实践，Java中String具备不可变性，密码这类敏感信息应当使用字节数组/字符数组类型处理，避免安全隐患。想了解Java String是否存在特殊的安全设计，使得Spring Security的该实现不存在安全问题？

首先明确结论：Java String没有任何特殊的安全设计可以抵消不可变性带来的敏感信息泄露风险，Spring Security这么写本质是在通用场景下做的实用性权衡，不是因为String本身有什么安全黑魔法。

先回顾下为什么安全规范不推荐用String存密码：String是不可变对象，一旦创建完成，直到被垃圾回收器回收之前，代码层面没有任何办法主动修改它存储的内容。如果用char[]或者byte[]存密码，在密码校验逻辑完成后，可以立刻把数组的每个元素覆写为空值或者随机乱码，大幅缩短敏感明文在内存中停留的时间窗口；但String做不到主动清零，只要没被GC回收，明文就会一直留在内存里，如果攻击者拿到进程的内存dump，很容易就能提取到明文密码。

Spring Security选择用String处理密码，核心原因有三个：

• 绝大多数场景下，敏感信息在进入Spring Security逻辑之前就已经是String类型了。不管是Web表单提交还是JSON请求传参，Web容器、JSON解析框架默认都会把密码参数解析成String，等请求走到DaoAuthenticationProvider这一层的时候，密码明文早就以String的形式在内存里存在了，这时候再转成char[]没有任何实际的安全收益，属于无效操作。
• 框架本身做了兜底的敏感信息擦除逻辑。DaoAuthenticationProvider在密码校验流程完成后，会主动把Authentication对象中存储的credentials引用置空，帮助垃圾回收器尽快回收这个存储了密码的String对象，尽可能缩短敏感信息在内存中的停留时长。
• 生态兼容性考虑。Spring Security的核心密码编码器接口PasswordEncoder的matches、encode方法入参都是CharSequence类型，String本身就是CharSequence的标准实现，直接使用String不需要做额外的类型转换，不会和第三方实现的密码编码器产生兼容问题。

如果你的应用属于安全等级要求极高的场景（比如金融、涉密类系统），完全可以通过自定义扩展规避这个问题：在请求解析阶段就把密码参数解析为char[]，自定义Authentication实现将凭据存储为char[]类型，替换默认的DaoAuthenticationProvider逻辑，在密码校验完成后主动覆写char[]数组的内容。Spring Security本身预留了足够的扩展点支持这类高安全需求，只是默认实现选择了覆盖99%通用业务场景的权衡方案，并不是不知道String存储敏感信息的风险。

内容的提问来源于stack exchange，提问作者Piotr Januszek