通过 Java 中的内存转储缓解凭证泄漏答案

【问题标题】：Mitigate credential leaks via memory dumps in Java通过 Java 中的内存转储缓解凭证泄漏
【发布时间】：2019-03-22 08:14:37
【问题描述】：

我们都知道，Java 中的密码/凭据应存储为 char 数组。它的缓解，而不是保护。

我始终保持我的凭据不使用不可变对象，但迟早我需要将它传递给某个需要 String 的类（来自我们使用的所有第 3 个库）。不是所有的努力都没有了吗？例如：如果我想设置授权标头，标头值由 org.apache.http.message.BasicHeader 类存储为字符串。另一个例子（可能不是那么好）：我使用一个处理密码的服务（存储密码或其他东西）。它要求它们作为 POST 请求的主体。我创建 HttpPost 并将 StringEntity 添加为正文。它已经存储为字符串，可以再次转储。

您是否设法让您的凭据相对安全地避免内存转储？

谢谢

【问题讨论】：

如果有人可以在本地访问您的进程，那么他们就是王者，可以看到他们想要的任何内容。您唯一能做的就是通过混淆他们可能想要查看的内容来减慢他们的速度。
@xtratic 您的评论将是一个很好的答案。那么这个问题就可以关闭了。
第三方库是问题（可能）...如果您对密码的内存安全性很认真，您将不会使用任何违反该安全性的第三方库。如果开发速度/成本是您的首要任务而不是使用，那么不要担心这个特定的安全层。您必须根据正在构建的应用程序类型来选择优先级。您正在构建密码管理器吗？如果是，您需要注意您的程序是否在内存中公开凭据......不太重要的事情可能不是......
大家好，感谢您的帮助！关于@xtratic 评论。我的问题是您成功地在生产中管理此规则。我不想讨论它是否毫无意义，如果我不清楚，请原谅。关于 DarkMatter，感谢您的宝贵时间，您的回答更详细。我不确定是否存在人们根本不使用 3rd 方库的公司。毕竟我的例子是一个非常广泛使用的组件。在具体情况下，我谈论的是商业软件，而不是密码管理器，但我认为这并不重要。
顺便说一句，为什么这个问题得到了小数一分？我是否使用了错误的组件或者我提出了不清楚的问题，这样的问题可能有什么问题。还是不明白的人给了-1？

标签： java security memory-dump

【解决方案1】：

在联系了该领域的一些安全专家后，得到了如下答复：

在 Java 中将凭据存储为 char[] 是第二道防线。第一个是不允许他们进行内存转储。
如果通过了第一级，我们可以减少他们在内存中找到的凭据数量。
现在几乎不可能不使用第 3 方库。但是，在我的所有示例中，第 3 方库都会在短时间内引用我的密码。他们将其存储为 String 的事实并不意味着我们不应该正确存储它。我们的目标是不要将凭证存储为字符串，尤其是在缓存或其他对该对象的引用被保留很长时间的地方。

【讨论】：