在哪里存储哈希，盐，钥匙在桌面应用程序 [英] Where to store hashes, salts, keys in Desktop Applications

问题描述

我想弄清楚在何处或如何我应该存储在桌面应用程序中的应用程序的秘密和密钥。

例如，一个Facebook应用程序键或Dropbox的密钥和密码。


所以我读过，我应该哈希，盐，加密等等等等这些值。这是为了防止有人通过反向工程我的代码，看到钥匙。


的都是好的，很好，但所有这些方法，我只是存储盐或散列值，而不是某个地方的密钥本身，到底。当然，如果一个黑客可以获取到盐/散列和可能的源代码，他们将能够解密加密的密钥，并获得我的密码/键/秘密呢？



的一种选择我读过有关这似乎是最安全的是不存储在桌面应用程序这个价值可言，但是调用Web服务来获取密钥（加密可能）。
但我的问题是，即使在这种情况下，一个体面的黑客一定会只是做一个内存转储或东西，看看从Web服务返回的值，然后我们又回到了起点1。

I am trying to figure out where or how i should store application secrets and keys inside a desktop application.
For example a facebook app key or dropbox key and secret.

So I've read that i should hash, salt, encrypt etc etc these values. This is to prevent someone from reverse engineering my code and seeing the keys.

The is all good and well, but with all these methods, i'm just storing a salt or hash value somewhere instead of the key itself, in the end. Surely if a hacker can get to the salt/hash and possibly the source code, they will be able to decrypt the encrypted key and get my password/key/secret anyway?

One option I've read about that seems the most secure is to not store this value in the desktop app at all, but to call a web service to obtain the key (probably encrypted). But my question is, even in this case, a decent hacker will surely just do a memory dump or something to see what the value returned from the web service is, and then we're back at square 1.

接下来最好的选择似乎是默默无闻。

The next best alternative seems to be obscurity.

我失去的东西完全？

在一个侧面说明，有什么用会的Facebook / Twitter的/的Dropbox在/ etc键/秘诀是黑客呢？
当然，他们仍然需要用户的凭据或访问令牌才能这样用？

On a side note, what use will a facebook/twitter/dropbox/etc key/secret be to a hacker anyway? Surely they would still need a user's credentials or access token to be able to use it anyway?

任何意见或建议将不胜感激。

Any advice or suggestions will be appreciated.

推荐答案

有关每个用户帐户生成应用程序新的访问令牌，当他们成功登录到您的服务。您的登录服务应设计很像一个网站登录：

For each user account generate a new access token for the application when they successfully log into your service. Your login service should be designed much like a login for a website:

• 的API应该只允许一组号码（如5）错误的登录尝试，报告回到桌面客户端的用户名/密码不匹配。


• 的API应该返回仅与该用户相关联的令牌当用户成功登录。


• 使用SSL和本地化的散列方法对用户密码传递给您的API

这验证令牌所提供的API将只对个人帐户的工作，因此应仅允许用户执行操作以他们的个人帐户。因此，例如，如果用户想要执行操作它们必须能够以完成操作提供有效的身份验证令牌。使用这种方法的攻击者将仍然能够获得一个auth键，但AUTH密钥将仅能够执行用于在其中产生的帐户。它不能对任何人的帐户执行操作。这里的想法是让他们惹的数据，但保持划分以一个帐户坏的活动。

This auth token provided by your API will only work for the individual account and as such should only allow the user to perform operations to their individual account. So for instance, if a user wants to perform an operation they must be able to provide a valid auth token in order to complete the action. Using this method attackers will still be able to obtain an auth key, but that auth key will only be able to perform operations for the account in which it is generated. It will not be able to perform operations on anyone else account. The idea here is to let them mess with data but to keep the bad activity compartmentalized to one account.

在这里，如果你有通用的API调用（比如图像搜索），从多个帐户访问数据确保你永远不会返回或允许任何帐户访问全部的系统中的数据顾左右而言他。提供唯一的记录的数量有限。在这种情况下，系统仍然执行其工作，但在没有点允许在系统中的所有记录进行访问。

From there, if you do have generic API calls (say an image search) that accesses data from multiple accounts make sure that you are never returning or allowing for any account to access all the data in your system outright. Provide only a limited number of records. In this case the system is still performing its job, but at no point allows all the records in your system to be accessed.

我通常实现这样的服务：

I typically implement a service like this:

• 在用户登录并获得一个身份验证令牌。我店说，与该用户相关的数据库的身份验证令牌。


• 用户调用与身份验证令牌的Web服务。我通过查找用户帐户的 的发送的验证令牌和用户ID（两种形式的身份验证），并使用所发现的用户帐户来执行所有操作。我不只是假设用户ID是正确的，它必须是一个身份验证令牌身份验证的反对。


• 如果用户需要执行精致像重置密码的操作，我的应用程序将打开应用程序，用户可以请求并管理重置浏览器窗口或浏览器的任务。我可以更容易的未知客户端上的安全比一个Web应用程序。

• User logs in and gets an auth token. I store said auth token in a database associated with that user.
• User calls web service with auth token. I lookup user account by the transmitted auth token and User ID (two forms of authentication) and use the discovered user account to perform all operations. I don't just assume the User ID is correct, it has to be the one the auth token authenticated against.
• If a user needs to perform a delicate operation like reset a password, my app opens a browser window or browser task in the app where the user can request and administer a reset. I can more-easily secure a web application than one on an unknown client.

使用这些方法，你应该能够作出充分运行桌面应用程序。有离群这个功能，如果你有他们的任何张贴在评论中，我们可以进一步深入到这个问题，看看这个解决方案仍然可以为你工作。

Using these methods you should be able to make a fully operational desktop application. There are outliers to this functionality, if you have any post them up in the comments and we can dive further into the problem and see if this solution can still work for you.

这篇关于在哪里存储哈希，盐，钥匙在桌面应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！