关于Java:保护源代码的部分

Protecting Sections of Source Code

本问题已经有最佳答案,请猛点这里访问。

我正在编写一个Java类,它连接到一个服务器并读取给定队列中的消息。

我想保护用户名和密码,它现在在源代码中显示为纯文本。

我想知道的是,做这件事的好方法是什么?如果我在文本文件中加密用户名和密码,我不需要将密钥以纯文本的形式存储在任何访问该文件的源代码中吗?然后任何其他决定使用我的类的人都可以访问这些字段。

也没有提示在哪里可以输入密钥,因为这个类将由系统自动使用。

编辑:这将成为一个Java LIB文件。但是这些文件很容易被反编译,因此基本上都是原始类文件,对吧?而被保护的人是其他系统的开发人员,他们可以访问这个lib文件。

我的最终目标是:让用户名和密码字符串在任何地方都不显示为纯文本,并且使它们尽可能难以破解。


这是不可能的。即使您加密了登录名/密码并将其存储在某个地方(可能是您的类或外部文件),您仍然需要将加密密钥保存在纯文本的某个地方。实际上,这比用纯文本保存用户名/密码要好得多,事实上,我会避免这样做,因为这样会产生一种错误的安全感。

因此,我建议您的类将用户名/密码作为参数,并且使用类的系统必须注意保护凭据。它可以通过要求最终用户输入凭据或将其存储到一个外部文件中来实现,该外部文件只能供运行进程的操作系统用户读取。

编辑:您还可以考虑使用一些机制,例如使用令牌而不是密码的OAuth。令牌的使用寿命有限,并且与某个特定目的相关联,因此它们是访问凭据的一个很好的替代方案。因此,最终用户可以获得一个带有Windows凭据的访问令牌,然后在类中使用该凭据来调用受保护的服务。


这是一个经典的身份验证问题,除了这里,Eve可以像穿西装一样穿着Bob的皮肤。这是在延伸比喻吗?我不确定。

简短的回答是,没有真正的答案,因为你想要的是一些基本上违反信息理论的东西,因为任何可传递的东西都是可复制的,因此任何可访问的东西都不再是唯一的。即使你有一个魔盒,他们也可以通过一些严重的JVM黑客攻击将魔盒猛拉出来。

长期的答案是,有一些解决方案几乎是相当不错的,使它非常困难。我建议您阅读链接的文章,了解SRP背后的思想,以及规范所包含的漏洞,并尝试找出如何获得使用和实现它的权利。但问题仍然存在。你需要一个系统来确保鲍勃永远不会成为一辆肉身战车,或者堕落到黑暗面。

从根本上说,你违反了第十条法律。我同意库尔克的观点,没有解决方案能真正做到你想要的,因为你试图用一个技术上的壮举来解决一个社会问题,这几乎是不可能的。


我知道这个问题早就被抛弃了,但我想指出的是,当然,您可以通过在运行时要求输入凭据来做到这一点,但只能存储密码的散列值。当然,它必须是一个非常好的哈希。用一个标准的,不要自己编。散列的全部要点是,即使您将散列结果以纯文本的形式显示,也没有其他人能够想出产生散列的字符串,即使他们知道散列是如何计算的。

当然,用户可以尝试蛮力攻击,因为他们知道他们想要的结果,所以可以快速运行,所以您需要使用高度安全的密码。


不清楚哪些代码必须知道用户名和密码。这些凭证是否仅用于正在读取的队列?如果是这样,只有服务器代码才需要知道它们。在这种情况下,您可以将它们存储在一个服务器文件中,该文件的权限仅允许服务器代码读取它们。然后,文件权限将由服务器操作系统强制执行,服务器操作系统在安全性方面比大多数程序员都强得多。


有几种方法可以解决这个问题。正如您所指出的,挑战是将一个帐户与这个自动化过程关联起来。所以,这里有一些可能性(从最不安全到更安全):

  • 用计算出的密钥加密用户名和密码。
    • 计算出的密钥是基于客户机和服务器都可以推断出的内容(如计算机名和IP地址)
  • 将身份验证令牌与客户端关联(OAuth样式)。
    • 令牌由一次性用户交互协商以设置客户端
    • 协商令牌用于所有将来的请求
    • 协商令牌仅对使用该用户帐户的计算机上的客户端有效(服务器使用套接字信息来确定匹配)
  • 使用多种形式的身份验证
    • OAuth样式标记
    • 基于时间+辅助ID计算的令牌(要求客户端和服务器同步到同一时间服务器)
  • 值得注意的是,您的安全措施应该比值得破解的更严格。简言之,如果所有潜在的坏人只会得到你一天的食物偏好,你可能不需要像保护更高的知名度,如银行账户一样守夜。用户名和密码不是唯一的身份验证方法。