【问题标题】:Hide Password Content in Source Code在源代码中隐藏密码内容
【发布时间】:2009-12-31 17:20:48
【问题描述】:

有谁知道如何在 j2me 程序的源代码中隐藏密码内容?也就是说,阅读源代码的人看不到“DBT”作为密码。

public void validateUser(String user, String Password) {     
  if (user.equals("N0203251") && Password.equals("DBT")) {
    switchDisplayable(null, getContinue());
  }
}

【问题讨论】:

标签: java passwords java-me


【解决方案1】:

正如其他人所说。存储哈希值,但您仍需要使用强密码,否则自动猜测器会找到您正在使用的密码。

但是,请注意:

如果您的攻击者有权访问源代码,他/她/它可以更改存储的密码哈希或仅删除密码检查。

所以这个方法用处不大,除非你能验证正在运行的代码的完整性,这是困难

【讨论】:

    【解决方案2】:

    归根结底,您已经在程序中编写了一个后门。这是一件坏事 - 不要这样做。

    正如其他人所说,使用哈希可以做得更好,但忽略了一些关键的事情。当有人猜出密码时,他们就会知道每个已安装软件副本的密码。由于密码是硬编码的,没有人可以更改或撤销它,因此您将在程序中插入一个没有人可以消除的后门。而且,如果您依赖该密码或与其他资源进行任何通信,则永远无法更改它 - 至少,如果没有大量的额外工作,则不会。

    您真正应该做的是将密码放在外部位置,例如硬件安全模块、密码文件或数据库表。然后,实施完整的密码更改和轮换机制 - 老实说,这应该与您在所有密码中使用的机制几乎相同。

    【讨论】:

      【解决方案3】:

      您可以存储密码的哈希值 (MD5 / SHA1),并将其与提供的密码的哈希值进行比较。

      确保您在外部计算哈希,以避免在可执行文件的任何地方提及原始密码。

      【讨论】:

      • 一点额外说明 - 看看使用 Java Cryptograpy 架构执行哈希/摘要java.sun.com/javase/6/docs/technotes/guides/security/crypto/…
      • 你自相矛盾。在第 1 段中,您说存储哈希。在第 2 段中,您说计算哈希。
      • @GregS:这里没有矛盾。在构建时,您从文件或其他不属于源代码的源计算哈希,并从该计算中生成代码,该代码仅将哈希存储在可执行文件中。在运行时计算用户输入的哈希值并将其与程序中存储的正确哈希值(可能在数据段中)进行比较。
      • @Gregs - 它说“计算散列外部”,我的意思是使用源代码之外的另一个工具来生成散列。如果您对如何更好地措辞有任何建议,我愿意接受!
      • @dmckee:谢谢,我误解了。即便如此,我仍然坚持以下声明。
      【解决方案4】:

      使用hashes the password 的函数 - 将密码的哈希值保留在源中,而不是密码本身。

      来自该页面的引用:

      一个相关的应用是密码 确认。密码通常是 不以明文形式存储,显然 原因,而是以摘要形式。 要对用户进行身份验证,请输入密码 由用户呈现的散列和 与存储的哈希值相比。这是 有时称为单向 加密。

      【讨论】:

        【解决方案5】:

        如果您将应用程序存储在用户的移动设备上,您能做的最好的事情就是尝试隐藏密码。我建议使用某种散列算法(可能是 SHA1)或密钥派生算法(如 PBKDF2)并存储结果,而不是与明文密码进行比较。

        【讨论】:

          【解决方案6】:

          存储哈希值而不是密码绝对不会为您带来任何好处。由于现在使用哈希而不是密码进行身份验证,因此读取源代码(或反转目标代码)将揭示哈希并允许攻击者进行身份验证。

          这些问题的答案总是一样的。如果您使用硬编码的客户端机密,无论您做什么,都无法实现任何可衡量的安全性。你能做的最好的就是足够模糊,直到你有一种温暖的模糊感觉,它已经足够好了。

          【讨论】:

          • 如果用户密码输入被散列,知道所需的散列绝对没有好处(假设原始密码“足够强”)。说“散列对你没有任何好处”是完全错误的。如果用户可以修改代码,那么您显然已经被淹没了,但是仅仅知道正确的哈希并不意味着您可以像您暗示的那样简单地提供它。
          • 用户可以总是修改在他们的计算机或设备上运行的代码,而且几乎总是非常容易。散列不会给你带来可衡量的安全性增加,只会给你带来无法衡量的虚假安全感。
          • 在已编译的程序中(我猜这将是 javaese 中的 jar),读取纯文本密码比找到测试并破解它稍微容易一些。适合小姐妹的非常适度的防御。
          • 你在说什么,格雷格?给定密码的哈希值,如果它是一个很好的哈希函数,攻击者就无法构造出与该哈希值匹配的密码。这就是 Unix 长期存储密码的方式(加上盐渍,但这不是本次讨论的重点)
          • @eli: 是的,我知道。仔细重新阅读原始代码而不是草草下结论,我发现我的答案没有意义。我没有对其进行编辑,而是将其作为可耻的纪念碑留在那里。除了“N0203251”之外的用户能够获得 switchDisplayable(...) 的好处,哈希并没有给你带来任何好处,但不是出于我所说的原因。
          猜你喜欢
          • 1970-01-01
          • 2017-03-12
          • 2014-02-21
          • 1970-01-01
          • 1970-01-01
          • 2018-03-15
          • 2011-09-14
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多