如何管理对称算法中的密钥
我正在我的 C# 代码中进行 AES 加密，使用的密钥是使用 PasswordDerivedKey 函数通过传递 password 和 12 的 salt 生成的字节。我已经在应用程序代码中实现了逻辑，“密码”是登录用户的用户名，盐是静态字节数组。
存储密码和盐的最佳方法是什么，因为有人可以轻松确定盐（通过反映我的代码）和一个人的用户名。
我可以采用哪些替代方法来以安全的方式存储密码和盐。我不认为将它们存储在我的应用程序代码中是最好的方法。
编辑：通过密码，我的意思是PBKDF函数中使用的密钥（用于派生加密密钥），而不是用户提供的密码。我正在使用 Windows 身份验证
I am doing an AES encryption in my C# code, using a key which is generated using PasswordDerivedKey function by passing a password and a salt of 12 byte. I have implemented the logic in my application code and the "password" is the username of the logged in user and the salt is a static byte aray.
What is the best way of storing the password and the salt, as someone can easliy determine the salt (by reflecting my code) and the username of a person.
What are the alternatives I can adopt to store the password and the salt in a secure way. I dont think storing them in my application code is the best way of doing it.
Edit: By password, i meant the passkey used in the PBKDF function (to derive an encryption key) and its not the password provided by the user. I am using Windows Authentication
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果密码只是 Windows 用户名的加密版本，为什么需要存储密码？
任何时候您需要加密/解密时，您都知道用户名，因此可以动态生成密钥。
盐永远不应该被视为安全资产。无需隐藏它。您应该始终假设攻击者知道盐。 Salt 只是一种击败彩虹表和其他快速查找的机制。
有什么我没有看到的吗？
编辑时
该问题在问题中表述错误。问题不在于应该存储什么/如何存储。这个答案很简单。切勿存储任何加密数据（盐除外）。
当前的实现根据登录用户的用户名创建加密密钥。问题是这是不安全的，因为确定用户名相当容易。要解决这个问题，需要：
a）接受该实现对于愿意反编译应用程序的人来说是不安全的。
b) ...这不是一个好主意...哈希值可以根据组/角色进行更改
c) 为每个用户使用唯一的秘密密码。
c 是唯一安全的实现，但它需要在加密或解密时提示用户输入密码。
Why would you need to store password if it is merely an encrypted version of the windows username?
Anytime you need to encrypt/decrypt you know name of user thus can generate key dynamically.
Salt should never be considered a secure asset. No need to hide it. You should always assume attacker knows the salt. Salt is simply a mechanism to defeat rainbow tables and other fast lookups.
Is there something I am not seeing?
On Edit
The issue is misstated in the question. The issue isn't what/how should be stored. That answer is simple. Never store any of the cryptographic data (except salt).
The current implementation creates an encryption key from the username of logged in user. The problem is that is insecure as determining username is rather easy. To get around this one would need to either:
a) accept the implementation is insecure to someone willing to decompile app.
b) ... not a good idea ... hash can change based on groups/roles
c) use a unique secret password for each user.
c is the only secure implementation however it requires prompting the user for a passphrase when encrypting or decrypting.
数据必须对谁安全？如果允许当前登录的用户访问数据，但不允许其他 Windows 身份验证用户访问，则您真正想要的是为特定登录用户加密数据。如果您具有配置电脑的访问权限，您也许能够创建一个仅具有所需用户权限的加密文件夹。这不是 100% 安全（如果您具有 root 访问权限，您仍然可以在不同位置拦截数据），但唯一合理的选择是添加另一个密码。
或者，您可以简单地接受保护很弱并提供最小程度的混淆。这取决于数据的价值和可能攻击者的能力。如果您的攻击者有足够的权限来反映您在实际计算机上的程序集，那么他们很可能也是管理员，这意味着无论您做什么，您都会被搞砸。有些工具可以连接到正在运行的进程并监视其内存，这意味着它们可以简单地等待，直到您解密数据并从内存中读取数据。
Against whom must be the data be secure? If the currently logged in user is allowed access to the data, but other Windows Authentication users are not allowed access, what you really want is for the data to be encrypted for the particular logged in user. If you have access rights to configure the PC, you might be able to create an Encrypted folder with permissions only for the desired user. This is not 100% secure (you can still intercept the data at various places if you have root access), but your only other reasonable alternative is to add another password.
Alternately, you can simply accept that the protection is weak and provide minimal obfuscation. It depends on the value of the data and the capabilities of your possible attackers. If your attackers have sufficient privileges to Reflect over your assembly on the actual machine, then it's highly likely that they're also Administrator, which means you're pretty much screwed no matter what you do. There are tools that can connect to a running process and monitor its memory, which means they could simply wait until you've decrypted the data and read it from memory.
保留盐的最佳方法是在运行时生成它，并将其与其他用户内容（例如用户名和密码）一起保存在每个会话中：
完全不建议将 对称加密（甚至非对称加密）作为密码。你不要散列它，这只是一种方式。
Best way to keep the salt is to generate it on runtime and keep it per session along with other user stuff such as username and password:
Symmetric encryption (or even asymmetric) is not at all recommended for passwords. You not to hash it which is just one-way.
我将其添加为第二个答案，因为它是一个不同的解决方案。我今晚才想到这一点，因为我正在使用这个类（试图对 Kindle 加密进行逆向工程）。
您可能需要查看受保护的数据类
http： //msdn.microsoft.com/en-us/library/2c64xe0y(v=VS.90).aspx
这是一个允许您在 Windows 加密存储中存储数据的类。
通过使用保护和取消保护功能，您可以将数据传递到加密存储中或从加密存储中提取数据。
如果您不想强迫用户创建（并记住）加密密钥，您也可以这样做。
1) 检查当前用户是否在商店中有加密密钥。
1a) 如果没有，则创建一个随机加密密钥
2) 使用密钥加密文件并存储
3) 解密从存储中检索密钥。
4) 另一个用户可能能够访问该文件，但无法从商店获取密钥的副本。
有几点需要注意。只有存储密钥的 Windows 用户才能检索密钥。然而，根据环境的不同，这可以被绕过。如果用户没有 Windows 密码（或弱 Windows 密码），则任何有权访问计算机的人都可以以该用户身份运行，并且 Windows 将很乐意交出密钥。在域环境中，任何可以模拟用户并修改密码的人（管理员）都可以访问他们的密钥。如果用户的 Windows 配置文件被丢弃，那么您的加密密钥的唯一副本也会被丢弃。
I added this as an second answer because it is a different solution. I just thought of it tonight because I am working with this class (trying to reverse engineer kindle encryption).
You may want to look into the Protected Data Class
http://msdn.microsoft.com/en-us/library/2c64xe0y(v=VS.90).aspx
This is a class that allows you to store data in the windows cryptographic store.
By using the Protect and Unprotect function you can pass data into and pull data from the cryptographic store.
If you didn't want to force the user to create (and remember) an encryption key you could.
1) Check to see if current user has encryption key in the store.
1a) If not then create a random encryption key
2) Use key to encrypt file and store
3) To decrypt retrieve key from store.
4) Another user may be able to access the file but will be unable to get a copy of the key from the store.
A couple caveats. Only the windows user who stored the key can retreive the key. However this can be bypassed depending on environment. If the user has no windows password (or weak windows password) anyone w/ access to machine can run as the user and windows will gladly hand over the key. In a domain environment anyone (admin) who can impersonate the user and modify password can access they key. If user's windows profile is trashed so is the only copy of your encryption key.