在Java中，使用char[]代替String来存储密码还有意义吗？

Question

我了解到使用char[]在comp.lang.java.*的Usenet天存储密码。

搜索StackOverflow也可以很容易地找到这样的高投票率问题：为什么char[]比String更适合密码？这与我很久很久以前学到的是一致的。

我仍然编写我的API以使用字符[]作为密码。但现在，这仅仅是空洞的理想吗？

例如，看看Atlassian Jira的Java API:LoginManager。authenticate，它将您的密码作为字符串。

或者是泰雷兹的Luna Java API:all people的LunaSlotManager中的login()方法，这是一家HSM厂商，使用字符串作为HSM槽密码。

我想我还在某个地方读到过URLConnection的内部结构（以及许多其他类）在内部使用字符串来处理数据。因此，如果您发送密码（尽管密码是由TLS通过网络加密的），它将在服务器内存中的字符串中。

访问服务器内存是一个很难实现的攻击因素吗？现在可以将密码存储为String了吗？或者，由于其他人编写的类，您的密码将以String结尾，这就是泰雷兹这样做的原因。

Answer 1

这不是通过网络传输的时刻的想法。确实，您确实最好使用String，因为它只是更方便地用于通过网络发送，当然要确保它已正确加密。

对于在应用程序中使用密码，由于堆栈转储和逆向工程以及字符串不可变的问题而有所不同：如果输入了密码，即使对变量的引用被更改为另一个字符串，也不确定垃圾收集器何时会真正从堆中删除字符串。因此，能够看到转储的黑客也将能够看到密码。使用char数组可以防止这种情况，因为您可以直接更改数组中的数据，而无需依赖垃圾收集器。

现在你可能会说：那么当它以字符串形式通过网络发送时，它仍然是可见的，不是吗？是的，但这就是为什么在发送之前加密它很重要。尽可能不要通过网络发送纯文本密码。

Answer 2

首先，让我们回顾一下推荐使用char[]而不是String的原因：Strings是不可变的，因此一旦创建了字符串，对字符串内容的控制就会受到限制，直到（可能是在）内存被垃圾收集。可以转储进程内存的攻击者因此可以潜在地读取密码数据。同时，char[]对象的内容可以在创建后被覆盖。假设GC在此期间没有将对象移动到另一个物理内存位置，这意味着密码内容可以在使用后被（某种程度上）确定性地销毁。在该点之后读取进程内存的攻击者将无法获取密码。

因此，使用char[]而不是String可以防止非常特定的攻击场景：攻击者可以完全访问进程内存，但仅限于特定的时间点，而不是持续的。即使在这种场景下，使用char[]也不能阻止攻击，它只是降低了攻击成功的机会（如果攻击者碰巧在创建和擦除密码之间读取了进程内存，他们可以读取它）。

我不知道有任何证据表明（a）这种情况有多频繁，也不知道（b）使用char[]在多大程度上改变了这种情况下的成功概率。据我所知，这纯粹是猜测。

事实上，在大多数系统上，这种情况可能根本不存在：可以访问其他进程内存的攻击者也可以获得完全跟踪访问权。例如，在Linux和Windows上，任何可以读取另一个进程内存的进程也可以向该进程注入任意逻辑（例如，通过LD_PRELOAD和类似机制¹）。所以我想说，使用char[]最多只能带来有限的好处，而且可能根本没有好处。

…事实上，我可以想到一个具体的反例：加载不受信任的插件库的应用程序。一旦通过传统方式（即在同一内存空间中）加载该库，它就可以访问父应用程序。在这种情况下，如果在加载插件之前处理密码，则使用char[]而不是String可能是有意义的。但是更好的解决方案是不要将不受信任的插件加载到同一内存空间中。一个常见的替代方案是在单独的进程中启动它并通过IPC进行通信。

¹虽然LD_PRELOAD特别要求攻击者不仅可以访问另一个进程，还可以启动该进程或访问其父进程。