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

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

1> William Bren..：

---

切勿将密码硬编码到代码中.这是最近在25个最危险的编程错误中提出的:

对于熟练的逆向工程师来说,将秘密帐户和密码硬编码到您的软件中非常方便.如果所有软件的密码相同,那么当密码不可避免地被人知晓时,每个客户都会变得脆弱.而且因为它是硬编码的,所以修复起来非常痛苦.

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

有关此常见错误的更多信息,请阅读CWE-259文章.本文包含更全面的定义,示例以及有关该问题的许多其他信息.

在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文件并读取登录凭据,但这不是安全风险,因为用户知道要开始的凭据.

第二种情况:尝试隐藏用户的登录凭据

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

正确案例:使用多层架构

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

每个用户都有自己的用户名和密码,可以在本地存储在首选项文件中,不存在任何安全风险.这称为三层体系结构(层是数据库服务器,业务逻辑服务器和客户端应用程序).它更复杂,但它确实是最安全的方式来做这种事情.

基本操作顺序是:

客户端使用用户的个人用户名/密码对业务逻辑层进行身份验证.用户名和密码是用户已知的,并且以任何方式与数据库登录凭据无关.

如果身份验证成功,则客户端向业务逻辑层发出请求,要求从数据库中获取某些信息.例如,产品清单.请注意,客户端的请求不是SQL查询; 它是一个远程过程调用,如getInventoryList.

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

业务逻辑层将库存清单发送回客户端应用程序.

客户端向用户显示库存清单.

请注意,在整个过程中,客户端应用程序永远不会直接连接到数据库.业务逻辑层接收来自经过身份验证的用户的请求,处理客户端对库存列表的请求,然后才执行SQL查询.

---

如果您正在向用户部署(示例)数据库编辑应用程序,并且您不希望他们知道数据库用户名和密码,那么您已经构建了错误的解决方案,并且客户端软件应该与服务器进行通信(通过例如,执行数据库内容的Web服务.

---

这究竟是如何阻止某人获取用户名/密码的？你不能只是从文件中读取它吗？

2> Keltia..：

---

将密码放入应用程序将读取的文件中.切勿在源文件中嵌入密码.期.

Ruby有一个鲜为人知的模块,名为DBI :: DBRC,用于此类用途.我毫不怀疑Java有一个等价物.无论如何,写一个并不难.

---

虽然这使得稍后更改密码更容易,但它无法解决基本的安全问题.

---

好的,所以文件只能由运行程序的用户读取.大.这解决了什么.:-)我,我们试图保密密码的用户,可以像应用程序一样轻松地阅读它...