在桌面应用程序中存储哈希,盐,键的位置

时间:2015-01-31 13:00:03

标签: java c# android c++ ios

我试图找出应该在桌面应用程序中存储应用程序机密和密钥的位置或方式。
例如facebook app键或Dropbox键和秘密。

所以我读过我应该哈希,加盐,加密等这些值。这是为了防止有人对我的代码进行逆向工程并查看密钥。

这一切都很好,但是通过所有这些方法,我只是在某处存储salt或hash值而不是密钥本身。当然,如果黑客可以获得salt / hash和可能的源代码,他们将能够解密加密的密钥并获得我的密码/密钥/秘密吗?

我读过的一个选项似乎最安全的是根本不将此值存储在桌面应用程序中,而是调用Web服务来获取密钥(可能是加密的)。 但我的问题是,即使在这种情况下,一个体面的黑客肯定只会进行内存转储,或者看看从Web服务返回的值是什么,然后我们回到第1方。

下一个最好的选择似乎是默默无闻。

我完全错过了什么吗?

另一方面,facebook / twitter / dropbox / etc密钥/秘密对黑客的用处是什么? 当然他们仍然需要用户的凭证或访问令牌才能使用它?

任何意见或建议都将受到赞赏。

1 个答案:

答案 0 :(得分:2)

对于每个用户帐户,当应用程序成功登录到您的服务时,会为该应用程序生成新的访问令牌。您的登录服务的设计应该与登录网站非常相似:

  • API应该只允许一组(例如5次)错误的登录尝试,向桌面客户端报告用户名/密码不匹配。
  • 当用户成功登录时,API应返回仅与该用户关联的令牌。
  • 使用SSL和本地化哈希方法将用户密码传递给API

您的API提供的此身份验证令牌仅适用于个人帐户,因此应仅允许用户对其个人帐户执行操作。因此,例如,如果用户想要执行操作,则他们必须能够提供有效的身份验证令牌以完成操作。使用此方法,攻击者仍然可以获取身份验证密钥,但该身份验证密钥只能执行生成密钥的帐户的操作。它将无法对其他任何帐户执行操作。这里的想法是让他们搞乱数据,但要将坏活动划分为一个帐户。

从那里开始,如果你有通用API调用(例如图像搜索)来访问来自多个帐户的数据,请确保您永远不会返回或允许任何帐户访问所有中的数据你的系统完全。仅提供有限数量的记录。在这种情况下,系统仍在执行其工作,但绝不允许访问系统中的所有记录。

我通常会实现这样的服务:

  • 用户登录并获取身份验证令牌。我将所述身份验证令牌存储在与该用户关联的数据库中。
  • 用户使用身份验证令牌调用We​​b服务。我通过发送的身份验证令牌和用户ID(两种身份验证形式)查找用户帐户,并使用发现的用户帐户执行所有操作。我不只是假设用户ID是正确的,它必须是验证身份验证令牌的那个。
  • 如果用户需要执行精致操作(如重置密码),我的应用会在应用中打开浏览器窗口或浏览器任务,用户可以在其中请求并管理重置。我可以更轻松地保护Web应用程序,而不是未知客户端上的应用程序。

使用这些方法,您应该能够创建一个完全可操作的桌面应用程序。这个功能有异常值,如果你在评论中有任何发布,我们可以深入研究问题,看看这个解决方案是否仍然适合你。