在Swing中,密码字段有一个getPassword()(returns char[])方法,而不是通常的getText()(return String)方法。同样,我也遇到了一个建议,不要使用String来处理密码。

为什么字符串对密码安全构成威胁?使用char[]感觉不方便。


当前回答

简单明了的答案是因为char[]是可变的,而String对象不是可变的。

Java中的字符串是不可变的对象。这就是为什么它们一旦创建就不能被修改,因此从内存中删除它们的内容的唯一方法就是垃圾收集。只有当对象释放的内存可以被覆盖时,数据才会消失。

现在,Java中的垃圾收集不会在任何保证的时间间隔内发生。因此,字符串可以在内存中保存很长时间,如果在此期间进程崩溃,字符串的内容可能会在内存转储或某些日志中结束。

使用字符数组,您可以读取密码,尽快完成处理,然后立即更改内容。

其他回答

除非您在使用后手动清理,否则char数组不会为您提供字符串,我还没有看到有人真正这样做。所以对我来说,char[]和String的偏好有点夸张。

看看这里广泛使用的SpringSecurity库,问问你自己——SpringSecurity的家伙们是无能还是字符密码根本没有意义。当一些讨厌的黑客从你的RAM中获取内存转储时,即使你使用复杂的方法隐藏密码,也要确保他/她会得到所有密码。

然而,Java一直在变化,一些可怕的特性,如Java8的字符串重复数据消除特性,可能会在您不知情的情况下实习字符串对象。但这是一个不同的对话。

字符串是不可变的。这意味着一旦创建了String,如果另一个进程可以转储内存,那么在垃圾收集开始之前,就没有办法(除了反射之外)清除数据。

使用数组,您可以在完成后显式擦除数据。您可以用任何您喜欢的内容覆盖数组,并且密码不会出现在系统中的任何位置,甚至在垃圾收集之前。

是的,这是一个安全问题,但即使使用char[]也只会减少攻击者的机会窗口,而且只针对这种特定类型的攻击。

如注释中所述,垃圾收集器移动的数组可能会在内存中留下数据的零散副本。我认为这是特定于实现的——垃圾收集器可以在运行时清除所有内存,以避免这种情况。即使这样,char[]仍有一段时间包含实际字符作为攻击窗口。

是否应该使用String或Char[]来实现这一目的是有争议的,因为两者都有各自的优点和缺点。这取决于用户需要什么。

由于Java中的字符串是不可变的,所以每当有人试图操纵字符串时,它会创建一个新的Object,而现有的字符串不会受到影响。这可以被视为将密码存储为字符串的一个优点,但即使在使用后,该对象仍保留在内存中。因此,如果有人以某种方式获得了对象的内存位置,那么此人可以很容易地跟踪存储在该位置的密码。

Char[]是可变的,但它的优点是在使用后,程序员可以显式地清理数组或重写值。因此,当它被使用后,它会被清理干净,没有人会知道你存储的信息。

基于以上情况,我们可以根据他们的需求来决定是使用String还是使用Char[]。

字符数组(char[])可以在使用后通过将每个字符设置为零而不设置为字符串来清除。如果有人能够以某种方式看到内存映像,那么如果使用字符串,他们可以看到纯文本的密码,但是如果使用char[],则在用0清除数据后,密码是安全的。

答案已经给出了,但我想与大家分享一下我最近在Java标准库中发现的一个问题。尽管他们现在非常小心地将密码字符串替换为随处可见的char[](这当然是一件好事),但在从内存中清除密码时,其他安全关键数据似乎被忽略了。

我正在考虑例如PrivateKey类。考虑一个场景,您将从PKCS#12文件加载一个专用RSA密钥,并使用它执行一些操作。现在,在这种情况下,只要对密钥文件的物理访问受到适当限制,单独嗅探密码对您没有多大帮助。作为一名攻击者,如果您直接获得密钥而不是密码,您的情况会更好。所需的信息可能是多方面的泄漏,核心转储、调试器会话或交换文件只是一些示例。

事实证明,没有任何东西可以让您从内存中清除PrivateKey的私有信息,因为没有API可以让您擦除构成相应信息的字节。

这是一个糟糕的情况,因为本文描述了这种情况如何被潜在利用。

例如,OpenSSL库在释放私钥之前会覆盖关键内存段。由于Java是垃圾收集的,所以我们需要显式方法来清除Java密钥的私有信息并使其无效,这些私有信息将在使用密钥后立即应用。