如何确保在 Java 中销毁 String 对象？

Question

我公司的一名员工需要通过我制作的程序修改 SQL Server 数据库中的数据。该程序最初使用 Windows 身份验证，我要求 DBA 授予该特定用户对所述数据库的写入权限。

他们不愿意这样做，而是授予对 my Windows 用户帐户的写入权限。

由于我信任这个人，但不足以让他在我的会话打开的情况下工作 90 分钟，我将在我的程序中添加一个登录提示，要求输入用户名和密码组合，然后使用它登录 SQL Server .我会登录并相信我的应用程序会让他只做他需要做的事情。

但是，这会带来很小的安全风险。 SunOracle 网站上的 password fields tutorial 声明密码应在内存中保留所需的最短时间，为此，getPassword 方法返回一个 char[] 数组，您可以将其归零完成后。

但是，Java 的 DriverManager 类只接受 String 对象作为密码，所以我无法在完成密码后立即处理它。而且由于我的应用程序在分配和内存要求上偶然非常低，谁知道它会在内存中存活多久？如上所述，该程序将运行相当长的时间。

当然，我无法控制 SQL Server JDBC 类用我的密码做什么，但我希望我可以控制 我用我的密码做什么。

有没有一种万无一失的方法可以用 Java 销毁/清零 String 对象？我知道两者都有点反对语言（对象破坏是不确定的，String 对象是不可变的），System.gc() 也有点不可预测，但仍然；有什么想法吗？

Answer 1

所以，这是个坏消息。我很惊讶还没有人提到它。使用现代垃圾收集器，甚至整个 char[] 概念都被打破了。无论您使用 String 还是 char[]，数据最终都会在内存中保存多久。这是为什么？因为现代 jvm 使用分代垃圾收集器，简而言之，将对象复制到所有地方。因此，即使您使用 char[]，它使用的实际内存也可能会被复制到堆中的各个位置，到处留下密码副本（并且没有高性能 gc 会将旧内存归零）。因此，当您将最后拥有的实例清零时，您只是将内存中的最新版本清零。

长话短说，没有万无一失的方法来处理它。你几乎必须信任这个人。

Answer 2

我只能想到一个使用反射的解决方案。您可以使用反射来调用使用共享字符数组的私有构造函数：

  char[] chars = {'a', 'b', 'c'};
  Constructor<String> con = String.class.getDeclaredConstructor(int.class, int.class, char[].class);
  con.setAccessible(true);
  String password = con.newInstance(0, chars.length, chars);
  System.out.println(password);

  //erase it
  Arrays.fill(chars, '\0');
  System.out.println(password);

编辑

对于任何认为这是一种防故​​障甚至有用的预防措施的人，我鼓励您阅读 jtahlborn's answer 至少一个警告。

Answer 3

如果您绝对必须，请保留对字符串的 WeakReference，并继续吞噬内存，直到您强制对字符串进行垃圾收集，您可以通过测试弱引用是否变为空来检测。这可能仍会将字节留在进程地址空间中。可能是垃圾收集器的更多搅动会给你带来安慰吗？所以在你的原始字符串弱引用被清空后，创建另一个弱引用并搅动直到它被清零，这意味着一个完整的垃圾回收周期已经完成。

不知何故，即使我上面的回答完全是认真的，我也必须为此添加 LOL :)

Answer 4

您可以使用反射更改内部char[] 的值。

您必须小心使用相同长度的数组更改它，或者同时更新count 字段。如果您希望能够将其用作集合中的条目或映射中的值，则需要重新计算哈希码并设置hashCode 字段的值。

话虽如此，实现这一点的最少代码是

        String password = "password";

        Field valueField = String.class.getDeclaredField("value");
        valueField.setAccessible(true);
        char[] chars  = (char[]) valueField.get(password);

        chars[0] = Character.valueOf('h');

        System.out.println(password);

Answer 5

我不确定DriverManager 课程。
一般来说，您是对的，建议将密码存储在 char 数组中，并在使用后明确清除内存。
最常见的例子：

KeyStore store = KeyStore. getInstance(KeyStore, getDefaultType()) ;
char[] password = new char[] {'s','e','c','r','e','t'};
store .load(is, password );
//After finished clear password!!!
Arrays. fill(password, '\u0000' ) ;

在 JSSE 和 JCA 中，设计正是考虑到了这一点。这就是 API 期望 char[] 而不是字符串的原因。
众所周知，字符串是不可变的，因此密码符合未来垃圾回收的条件，之后您无法重置密码。窥探内存区域的恶意程序可能会导致安全风险。
我认为在这种情况下，您正在寻找解决办法。
其实这里也有类似的问题：
Why Driver Manager not use char arrays?
但没有明确的答案。
似乎这个概念是密码已经存储在属性文件中（已经有一个 DriverManager 构造函数接受属性），因此文件本身已经比实际将密码从文件加载到字符串中带来了更大的风险。 或者 API 的设计者对访问数据库的机器的安全性有一些假设。
我认为最安全的选择是尝试调查（如果可能）DriverManager 如何使用密码，即它是否保留了内部引用等。

Answer 6

所以一旦我完成密码，我将无法处理它。

为什么不呢？

如果您通过

获得连接

Driver.getConnection 

你只需要传递密码并让它被 gc'ed。

void loginScreen() {
   ... 
   connect( new String( passwordField.getPassword() ) );
   ...
}
...
void connect( String withPassword ) { 
    connection = DriverManager.getConnection( url, user, withPassword );
    ...
}//<-- in this line there won't be any reference to your password anymore.

当控件从connect 方法返回时，您的密码将不再有引用。没有人可以再使用它了。如果您需要创建新会话，则必须使用新密码再次调用“连接”。对保存您信息的对象的引用丢失。

Answer 7

如果字符串没有被 JDBC 驱动程序管理器保存（一个很大的如果），我不会担心强制它的破坏。即使有大量可用内存，现代 JVM 仍然可以相当迅速地运行垃圾收集。问题是垃圾收集是否是有效的“安全擦除”。我怀疑是这样。我猜它只是忘记了对该内存位置的引用，并且不会将任何内容归零。

Answer 8

没有强制垃圾收集的常规方法。可以通过本机调用，但我不知道它是否适用于字符串，因为它们是池化的。

也许另一种方法会有所帮助？我对 SQL Server 不是很熟悉，但在 Oracle 中，做法是让用户 A 拥有数据库对象和一组存储过程，而用户 B 什么都不拥有，但对这些过程具有运行权限。这样密码就不再是问题了。

在您的情况下，您的用户将拥有所有数据库对象和存储过程，而您的员工将需要对存储过程的运行权限，希望 DBA 不太愿意提供这些权限。

Answer 9

有趣的问题。一些谷歌搜索揭示了这一点：http://securesoftware.blogspot.com/2009/01/java-security-why-not-to-use-string.html。根据评论，它不会有所作为。

如果您不将字符串存储在变量中而是通过 new String(char[]) 传递它会发生什么？