【问题标题】:Protect embedded password保护嵌入式密码
【发布时间】:2010-09-11 06:32:55
【问题描述】:

我在 java 中有一个属性文件,其中存储了我的应用程序的所有信息,例如徽标图像文件名、数据库名称、数据库用户和数据库密码。

我可以将加密的密码存储在属性文件中。但是,可以使用反编译器从 jar 中读取密钥或密码。

有没有办法将 db pass 安全地存储在属性文件中?

【问题讨论】:

    标签: java security passwords embedded-resource copy-protection


    【解决方案1】:

    有多种方法可以管理此问题。如果您可以找到一种方法让用户在应用程序启动时为密钥库提供密码,那么最合适的方法是使用密钥加密所有值,并将此密钥存储在密钥库中。密钥库的命令行界面是使用 keytool。然而,JSE 也有 API 以编程方式访问密钥库。

    如果您无法让用户在启动时手动向密钥库提供密码(例如对于 Web 应用程序),一种方法是编写一个异常复杂的混淆例程,该例程可以混淆密钥和也将其存储在属性文件中。要记住的重要事项是,混淆和反混淆逻辑应该是多层的(可能涉及加扰、编码、引入虚假字符等),并且本身应该至少有一个可以隐藏在应用程序的其他类中的密钥使用不直观的名称。这不是一个完全安全的机制,因为拥有反编译器和相当多的时间和智慧的人仍然可以解决它,但它是我所知道的唯一一个不需要你闯入本机(即不易反编译)代码的机制.

    【讨论】:

      【解决方案2】:

      您将密码的 SHA1 哈希值存储在属性文件中。然后在验证用户密码时,对他们的登录尝试进行哈希处理,并确保两个哈希值匹配。

      这是将为您散列一些字节的代码。您可以使用getBytes() 方法轻松地从字符串中获取字节。

      /**
           * Returns the hash value of the given chars
           * 
           * Uses the default hash algorithm described above
           * 
           * @param in
           *            the byte[] to hash
           * @return a byte[] of hashed values
           */
          public static byte[] getHashedBytes(byte[] in)
          {
              MessageDigest msg;
              try
              {
                  msg = MessageDigest.getInstance(hashingAlgorithmUsed);
              }
              catch (NoSuchAlgorithmException e)
              {
                  throw new AssertionError("Someone chose to use a hashing algorithm that doesn't exist.  Epic fail, go change it in the Util file.  SHA(1) or MD5");
              }
              msg.update(in);
              return msg.digest();
          }
      

      【讨论】:

      • 很好的答案,但不是他的问题。
      • 我想我还没有完全理解这个问题。
      • 他想存储应用程序用来连接数据库的用户名和密码。因此,他需要在连接到数据库之前将其转换回明文。
      • 实际上,数据库中应该存储密码的哈希版本。密码应该是纯文本的唯一情况是用户键入密码以及数据库管理员首次设置密码时。
      【解决方案3】:

      不,没有。即使你加密它,也会有人反编译解密它的代码。

      【讨论】:

      • 如果您将钥匙和锁交给某人,他们可以复制钥匙并在没有您最初给他们的钥匙的情况下访问锁。除非您不提供密钥,否则无法阻止他们获取密钥。这也是 DRM 的根本缺陷。
      【解决方案4】:

      您可以为密码(直接 DB 密码或密钥密码)创建一个单独的属性文件(在 jar 之外),并且不将该属性文件包含在分发中。或者您可以让服务器只接受来自特定机器的登录,这样就需要进行欺骗。

      【讨论】:

        【解决方案5】:

        除了如上所述加密密码外,请将任何密码放在单独的属性文件中,并在部署时尝试为该文件提供尽可能多的锁定权限。

        例如,如果您的应用程序服务器在 Linux/Unix 上以 root 运行,则将密码属性文件设置为 root 拥有的 400/-r-------- 权限。

        【讨论】:

          【解决方案6】:

          在通过某种方式进行身份验证后,您不能让应用通过 https 联系服务器并下载密码吗?

          【讨论】:

            猜你喜欢
            • 2011-11-03
            • 2014-03-12
            • 2010-10-31
            • 1970-01-01
            • 2011-02-01
            • 1970-01-01
            • 2013-09-05
            • 2013-04-26
            • 2016-01-26
            相关资源
            最近更新 更多