【问题标题】:Store encrypted password and decrypt it at runtime [duplicate]存储加密密码并在运行时解密[重复]
【发布时间】:2017-03-10 01:14:30
【问题描述】:

我正在编写一个使用登录名和密码连接到服务器的工具。该工具的用户必须在运行时提供该工具的登录名和密码才能连接到服务器以获取一些信息。

但是,我正在为我的工具进行一些集成测试,因此测试应该能够连接到服务器。我可以使用通用服务器的帐户来执行此操作。
但我想自动化这些集成测试,所以我需要将通用凭据加密存储在某处,集成测试在执行时解密它们(即使它们是通用的,它们仍然是凭据,所以我不舒服存储它们未加密)。

解决这个问题的方法是什么?如果该工具能够解密密码,则意味着它将持有一些主密钥,我认为这是错误的。
我是否应该公开一些我正在向其发送加密值的外部服务以对其进行解密,以便在工具外部处理加密/解密?

谢谢

【问题讨论】:

  • 你想测试什么?互联网还在吗?或者您的客户仍然使用正确的协议?或者密码仍然有效?这是您应该首先找到答案的问题。
  • 也许您可以解释一下您设想的坏人会窃取凭据的场景,因为尚不清楚您为什么要保护这些测试凭据,或者来自谁。凭据肯定不会在软件的生产版本中提供吗?那么您是否保护他们免受其他开发人员的侵害?如果是这样,他们难道不能简单地在某处放置一个断点来查看解密的凭据吗?
  • @wallenborn 我正在测试该工具在实时系统前的行为是否正确(与我存根服务器的单元测试相比)。
  • @PaulG 我可能确实在这里推动了一点安全性,因为这是一个通用凭据,不会被运送到生产中。我仍然发现有趣的安全问题值得讨论。

标签: java encryption cryptography


【解决方案1】:

我认为这个问题没有真正的解决方案。最后,无论如何必须是解密密码的算法或密钥。所以我可能会使用加密key + obfuscationkey + code in a language that cant be reverse engineered

【讨论】:

  • 这就是为什么我想把加密和解密从工具中分离出来
  • Speration 会很有用,因为 java 很容易受到尊重。但是好的混淆也很强大
  • 混淆只是对我隐藏了值(比如用 * 替换字符),因此无法取回原始值。也许我当时没有完全理解你的答案?
  • 再次好吧:您通过任何常见的加密使用密钥(盐)加密密码,并将密钥作为算法(一些花哨的东西)存储在代码中。然后你混淆你的整个代码,这样没有人可以对你的java代码进行逆向工程。这样,您的密钥(盐)就尽可能安全(在纯 java 中)
  • 不存在通过默默无闻的安全性...
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-03-20
  • 2011-04-18
  • 2021-08-09
  • 2013-03-30
  • 2011-07-14
  • 2014-06-23
  • 1970-01-01
相关资源
最近更新 更多