使用char数组而不是String

时间:2015-07-07 22:50:45

标签: java jdbc

正如标题所说,我正在寻找一种方法来使用char []数组来建立JDBC连接,而不是从char []数组创建一个新的String对象,并使用它来建立连接。 / p>

因为char []数组是more secure than Strings in java,所以我一直希望在处理JPasswordFields时尽可能保证安全。

在这种特殊情况下,我正在获取JPasswordField的char []数组内容并尝试建立与数据库的JDBC连接。它运行得很好,但是我必须从char []数组创建一个新的String对象来实际调用 getConnection 方法。

有没有办法确保至少某些安全性这样做,或者我只是被迫创建String对象并继续在方法中使用它?

这是我的代码:

/**
 * Construct a new DataManager object with it's own
 * connection to the database.
 *
 * @param ipAddress The IP address to the server on which MySQL is running.
 * @param port The port to use when connecting to MySQL.
 * @param databaseName The database name of the database to connect to.
 * @param username The username for a MySQL account with access to the specified database.
 * @param password The password for the MySQL account specified by the specified username.
 */
public DataManager(final String ipAddress, final String port, final String databaseName, final String username, final char[] password) throws ClassNotFoundException, IllegalAccessException, InstantiationException, SQLException {
    Class.forName("com.mysql.jdbc.Driver").newInstance();
    String url = "jdbc:mysql://" + ipAddress + ":" + port + "/" + databaseName + "?noAccessToProcedureBodies=true"; //?noAccessToProcedureBodies=true is required for using the stored procedures.
    dbConnection = DriverManager.getConnection(url, username, new String(password));
}

很抱歉格式化,但线条有点长,它们会换行。

我正在使用的

Here's the Java docs for the DriverManager class。我已经检查过,似乎没有一种方法可以使用char[]代替String,这就是提示这篇文章的内容。

感谢您提供任何帮助/提示。

1 个答案:

答案 0 :(得分:2)

正如@DavidS在评论中所说,我不确定使用char []是否真的以有意义的方式更安全,但我确实深入研究了{{1}来源,看看是否有可能使用。

如果您查看the getConnection() method you're using,您会看到它(以及其他参数变体)正在收集java.util.Properties中提供的所有连接信息,这实际上是一个字符串 - &gt ;字符串哈希表。然后,属性对象是passed to the needed driver的方法,该方法被定义为长期存在的一部分(因此不太可能改变)java.sql.Driver interface,其任何实现显然都依赖于驱动程序。

在那一点上,我认为你必须自动假设某个地方的人要么提供所提供的密码字符串的副本,要么将其包含在更大字符串的组合中,这样你就不能依靠反射去了返回并清除缓冲区。例如,在PostgreSQL JDBC驱动程序中,根据您的身份验证设置,密码可能只是sitting out as an encoded byte[],甚至可能消化它的设置(我看起来太过分了,而且我还没有...不要试图在这里敲PostgreSQL)让这个摘要开放被挖出来。

即使没有人制作过密码字符串的副本并且摘要完全无法触及,你仍然要担心在你的驱动程序中有对它的悬空引用(通过Properties对象)&#39 ; s堆栈,事情可能以意想不到的方式破坏。

无论好坏,我认为我们现在非常致力于将数据库密码存储为字符串,但我真的不相信这是一个大问题。我不认为历史经验是程序员更容易安全地管理敏感对象的生命周期而不是垃圾收集器。如果Java为我们提供了一种方法来注释一个对象作为更积极修剪的目标,那么它会很好,但也可能没有必要。

写这篇文章,我不得不经历~8级方法调用和对象创建,所以我想知道密码字符串是否真的足够短,能够手动擦除它会大大减少攻击面积。我认为Java数据处理的人机工程学方便性让我们忘记了幕后发生了多少事情。