java - 如何保护 MySQL 用户名和密码不被反编译？

Question

Java .class 文件可以很容易地反编译。如果我必须在代码中使用登录数据，我该如何保护我的数据库？

Answer 1

切勿将密码硬编码到您的代码中。这是最近在 Top 25 Most Dangerous Programming Mistakes 中提出的:

Hard-coding a secret account and password into your software is extremely convenient -- for skilled reverse engineers. If the password is the same across all your software, then every customer becomes vulnerable when that password inevitably becomes known. And because it's hard-coded, it's a huge pain to fix.

您应该将配置信息(包括密码)存储在应用程序启动时读取的单独文件中。这是防止密码因反编译而泄漏的唯一真正方法(永远不要将其编译为二进制文件)。

有关此常见错误的更多信息，您可以阅读 CWE-259 article 。这篇文章包含更全面的定义、示例以及有关该问题的许多其他信息。

在 Java 中，最简单的方法之一是使用 Preferences 类。它旨在存储各种程序设置，其中一些可能包括用户名和密码。

import java.util.prefs.Preferences;

public class DemoApplication {
  Preferences preferences = 
      Preferences.userNodeForPackage(DemoApplication.class);

  public void setCredentials(String username, String password) {
    preferences.put("db_username", username);
    preferences.put("db_password", password);
  }

  public String getUsername() {
    return preferences.get("db_username", null);
  }

  public String getPassword() {
    return preferences.get("db_password", null);
  }

  // your code here
}

在上面的代码中，您可以在显示用户名和密码的对话框询问后调用 setCredentials 方法。当您需要连接到数据库时，您只需使用 getUsername 和 getPassword 方法来检索存储的值。登录凭据不会硬编码到您的二进制文件中，因此反编译不会带来安全风险。

重要说明: 首选项文件只是纯文本 XML 文件。确保采取适当的步骤来防止未经授权的用户查看原始文件(UNIX 权限、Windows 权限等)。至少在 Linux 中，这不是问题，因为调用 Preferences.userNodeForPackage 将在当前用户的主目录中创建 XML 文件，无论如何其他用户都无法读取该文件。在 Windows 中，情况可能有所不同。

更重要的注意事项: 在这个答案和其他人的评论中已经有很多关于这种情况下正确架构的讨论。最初的问题并没有真正提到应用程序的使用上下文，所以我将谈谈我能想到的两种情况。第一种情况是使用程序的人已经知道(并被授权知道)数据库凭据。第二种情况是您，开发人员，试图对使用该程序的人保密数据库凭据。

第一种情况:用户被授权知道数据库登录凭据

在这种情况下，我上面提到的解决方案将起作用。 Java Preference 类将以纯文本形式存储用户名和密码，但首选项文件只能由授权用户读取。用户可以简单地打开首选项 XML 文件并读取登录凭据，但这不会带来安全风险，因为用户一开始就知道凭据。

第二种情况:试图对用户 隐藏登录凭据

这是更复杂的情况:用户不应该知道登录凭据，但仍需要访问数据库。在这种情况下，运行应用程序的用户可以直接访问数据库，这意味着程序需要提前知道登录凭据。我上面提到的解决方案不适用于这种情况。您可以将数据库登录凭据存储在首选项文件中，但他的用户将能够读取该文件，因为他们将是所有者。事实上，真的没有什么好方法可以安全地使用这种情况。

正确案例:使用多层架构

正确的做法是在数据库服务器和客户端应用程序之间设置一个中间层，用于验证单个用户并允许执行一组有限的操作。每个用户都有自己的登录凭据，但不是数据库服务器的登录凭据。凭据将允许访问中间层(业务逻辑层)，并且每个用户都不同。

每个用户都有自己的用户名和密码，可以本地存储在首选项文件中，没有任何安全风险。这称为 three-tier architecture(层是您的数据库服务器、业务逻辑服务器和客户端应用程序)。它更复杂，但它确实是做这种事情的最安全的方式。

基本的操作顺序是:

客户端使用用户的个人用户名/密码向业务逻辑层进行身份验证。用户名和密码是用户已知的，并且与数据库登录凭据没有任何关系。

如果认证成功，客户端向业务逻辑层发出请求，要求从数据库中获取一些信息。例如，产品库存。注意客户端的请求不是SQL查询；它是一个远程过程调用，例如 getInventoryList 。

业务逻辑层连接到数据库并检索请求的信息。业务逻辑层负责根据用户的请求形成安全的SQL查询。应清理 SQL 查询的任何参数以防止 SQL 注入(inject)攻击。

业务逻辑层将 list 列表发送回客户端应用程序。

客户端向用户显示库存 list 。

请注意，在整个过程中， 客户端应用程序从未直接连接到数据库 。业务逻辑层接收来自经过身份验证的用户的请求，处理客户对库存 list 的请求，然后才执行 SQL 查询。