我正在考虑制作一个小工具。 该工具将做什么并不重要。 重要的是，该工具需要在用户的硬盘上存储一些敏感信息。 编辑：将存储的信息是用户的信息 - 我并不是想保护我自己随应用程序分发的内容。
我了解我需要加密此信息。 但是，我应该在哪里安全地存储加密密码呢？ 这是某种无限递归...
那么，有没有一种方法可以加密 Windows 上的信息，并让 Windows 安全地管理密码？ 当我说 Windows 时，我指的是 Windows XP SP2 或更高版本。
我还应该注意，同一系统上的用户不得访问其他用户的信息（即使他们都在运行我的应用程序）。
我正在寻找 .NET 2.0 (C#) 和本机 (C/C++) 解决方案来解决此问题。
I was thinking of making a small tool. It is not important what the tool will do. The important thing, is that the tool will need to store some sensitive information on the user's HDD. EDIT: The information that will be stored is USER'S information - I'm not trying to protect my own content, that I distribute with the app.
I understand that I need to encrypt this information. But then, where do I safely store the encryption password? It's some sort of an infinite recursion...
So, is there a way, to encrypt information on windows, and have windows securely manage the passwords? When I say windows I mean Windows XP SP2 or later.
I should also note, that users on the same system must not have access to other users information (even when they are both running my application).
I'm looking for both - .NET 2.0 (C#) and native (C/C++) solutions to this problem.
发布评论
评论（7）
CryptProtectData：http://msdn。 microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
从 .NET 使用：http://msdn.microsoft.com/en-us/library/aa302402.aspx
历史上，受保护的存储（在 XP 中可用，在vista+): http://msdn.microsoft.com/ en-us/library/bb432403%28VS.85%29.aspx
CryptProtectData: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
Using from .NET: http://msdn.microsoft.com/en-us/library/aa302402.aspx
Historically, Protected Storage (available in XP, read-only in vista+): http://msdn.microsoft.com/en-us/library/bb432403%28VS.85%29.aspx
您应该考虑使用 DPAPI 来实现此目的。 它将使用基于每个用户的特殊（内部）对称密钥加密您的数据。 在这种情况下，您甚至不需要询问密码，因为系统上的不同用户将分配有不同的密钥。
它的缺点可能是，如果用户被删除/Windows 重新安装，您将无法恢复数据（我相信情况就是如此，但不太确定）。 在这种情况下，使用从密码派生的“自生成”密钥对数据进行加密，并将密码存储在使用 DPAPI 加密的注册表/文件中。
You should consider using DPAPI for this purpose. It will encrypt your data with a special (internal) symmetric key which is on per-user basis. You don't even need to ask for passwords in this case, because different users on the system will have different keys assigned to them.
The downside of it might be that you can't recover the data if the user is deleted/Windows reinstalled (I believe that this is the case, not quite sure though). In that case encrypt the data with a "self-generated" key derived from the password and store the password in registry/file encrypted using DPAPI.
您可以使用本机加密工具。 设置文件夹或文件的加密属性（在属性页中，单击“高级”按钮）。 然后您可以设置可以访问该文件的用户（默认情况下仅包括文件创建者）。 该解决方案的一大优点是从应用程序和用户的角度来看它是完全透明的。
要以编程方式执行此操作：使用 Win32 API，调用
EncryptFile()位于要存储敏感的每用户数据的目录中。 从现在开始，此目录中所有新创建的文件都将被加密，并且只能由其创建者（即您应用程序的当前用户）读取。 或者，您可以在创建时对各个文件使用FILE_ATTRIBUTE_ENCRYPTED标志。 您可以在文件属性页上的资源管理器中检查加密信息，并查看应用程序创建的文件是否已正确加密并仅限于其各自的用户。 没有密码可以存储或使用，一切都是透明的。如果您想对所有用户隐藏数据，那么您可以创建一个特殊的特定于应用程序的用户并从您的应用程序中模拟它。 这与 ACL 一起是 Windows 上用于系统服务的幸运技术。
You can use the native encryption facility. Set the encrypt attribute on your folder or file (from the property page, click on the "advanced" button). Then you can set the users that can access the file (by default this only includes the file creator). The big advantage of this solution is that it is totally transparent from the application and the users points of view.
To do it programmatically: using the Win32 API, call
EncryptFile()on the directory where you want to store your sensitive per-user data. From now on all newly created files within this dir will be encrypted and only readable by their creator (that would be the current user of your app). Alternatively you can use theFILE_ATTRIBUTE_ENCRYPTEDflag on individual files at creation time. You can check encryption info from the explorer on the file's property page, and see that app-created files are correctly encrypted and restricted to their respective users. There is no password to store or use, everything is transparent.If you want to hide data from all users then you can create a special app-specific user and impersonate it from your app. This, along with ACLs, is the blessed technique on Windows for system services.
您可能需要查看独立存储，这是一种自动存储每个应用程序数据上的设置和其他数据的方法。
请参阅示例和MSDN。
这是在注册表中存储正常设置的一种替代方法，在很多情况下是更好的选择......我不确定数据如何存储到文件中，但是所以你需要检查，你不会想要它其他用户可以访问，甚至加密。 凭记忆只有应用程序。 创建存储的人可以打开它 - 但这需要检查。
编辑：
根据我上次使用它时的记忆，一个好的方法是编写一个“设置”类来处理应用程序中的所有设置等。 然后，此类具有相当于 Serialize 和 DeSerialize 方法，允许它将所有数据写入isolatedStorage 文件，或再次将它们加载回来。
以这种方式实现的额外优点是您可以使用属性来标记源代码的位，然后可以使用属性网格快速为您提供对设置的用户编辑控制（属性网格在运行时使用反射操作类属性） 。
You might want to look at Isolated Storage, which is a way of storing settings and other data on a per-application data automatically.
See an example and MSDN.
This is an alternative to storing normal settings in the registry, a better one in a lot of cases... I'm not sure how the data is stored to file however so you'd need to check, you wouldn't want it to be accessible, even encrypted, to other users. From memory only the app. that created the storage can open it - but that needs checking.
Edit:
From memory when I last used this, a good approach is to write a "Setting" class which handles all the settings etc. in your app. This class then has the equivalent of Serialize and DeSerialize methods which allow it to write all its data to an IsolatedStorage file, or load them back again.
The extra advantage of implementing it in this way is you can use attributes to mark up bits of the source and can then use a Property Grid to quickly give you user-edit control of settings (the Property Grid manipulates class properties at runtime using reflection).
我建议您查看企业库加密应用程序块。 查看此博客文章。 Windows 具有用于加密数据的内置数据保护 API，但加密应用程序块使其更加简单。
I recommend you look at the Enterprise Library Cryptography Application Block. Check this blog post. Windows has a built in Data Protection API for encrypting data, but the Crypto Application Block makes it more straightforward.
嗯，您想要实现的目标正是 DRM 想要实现的目标。 加密某些内容，然后向用户提供密钥（无论如何混淆）和加密货币。 他们用 DVD 做到了这一点。 他们用蓝光做到了。 他们用 iTunes 做到了。
你打算做的事情永远不会是安全的。 一般的外行人可能无法弄清楚，但任何有足够动机的攻击者都会弄清楚并发现密钥、算法并解密数据。
如果您所做的只是加密用户数据，那么请向用户询问密码。 如果您试图保护您的内部数据免受运行该应用程序的用户的侵害，那么您就太失败了
Um, what you're trying to achieve is exactly what DRM tried to achieve. Encrypt something then give the user the keys (however obfuscated) and the crypto. They did it with DVDs. They did it with Blu-Ray. They did it with iTunes.
What you are proposing to do will never be secure. Your average lay person will probably not figure it out, but any sufficiently motivated attacker will work it out and discover the keys, the algorithm and decrypt the data.
If all you're doing is encrypting user data then ask the user for their password. If you're trying to protect your internal data from the user running the application you're S.O.L.
Erm 对密码进行哈希处理？ 您不需要将真正的交易存储在机器上的任何位置，只需一个散列密码（也可能是加盐的）。 然后，当用户输入密码时，您对其执行相同的操作，并将其与存储在磁盘上的散列密码进行比较。
Erm hash the password? You don't need to store the real deal anywhere on the machine just a hashed password (possibly salted too). Then when the user enters their password you perform the same operation on that and compare it to the hashed one you've stored on disk.