因为Java字符串对象是不可变的并且垃圾收集器是异步的，所以将认证信息存储在字符串中会阻止一种安全性，有利于线程安全。
安全地处理这些信息需要可变性，即将先前用于存储敏感信息的存储器清零。
假设您使用的是带有HeartBleed漏洞的openssl版本。
是不是天真的身份验证实现可能导致JVM内存中充斥着用户名和密码？
如果您不能确定信息不敏感的先验信息，是否应该完全避免使用java.lang.string？
作为一个侧面问题，Jvm可以做些什么来降低风险？我没有意识到切换是一个急切的零填充回收内存。 ＆＃34;
答案 0 :(得分：3)
我不是一个加密专家，但我认为这取决于你对威胁模型的评估。
如果你可以认为攻击者可以读取内存的随机部分，我真的不确定如何设计加密安全系统。毕竟，攻击者可能会在将其提取到内存后立即提取您的密钥。如果你认为攻击者可以做到这一点，那么尽可能快地提供额外的保护以清除内存并不会改变你的系统仍然容易受到攻击的事实。对系统时间有任何预先了解的攻击者可能会闯入它。
如果您不认为攻击者可以执行此操作，那么将旧字符串保留在内存中的安全性问题就不那么重要了。 Java的语言级安全功能应该确保可能危及JVM的攻击者无法看到过期的字符串对象。如果你不相信Java的实现来保护它，那么我不认为JVM的错误比使用字符串对象更多。
更一般地说，我认为要问的第一个问题是你可以假设攻击者可以做什么。如果您认为您的系统可能容易受到扫描RAM内容的人的攻击，那么我认为您有一个比垃圾收集器运行速度不够快的问题。如果您认为某人可能能够运行任意Java代码，那么我认为这不是问题。如果你认为某人可能冻结计算机并将其带到实验室检查RAM，我认为你需要担心更大的问题。
希望这有帮助！