反射器时代的 C# 加密

发布于 2024-07-28 22:17:26 字数 276 浏览 3 评论 0原文

我有一个程序,其中数据库的密码由远程用户设置。 该程序将用户名和密码保存到 xml 文件中的加密字符串中,否则该文件应该是人类可读的。 现在,这工作正常,我使用带有密钥的 C# DES 加密,并且它得到加密和解密。 现在的问题是任何人都可以使用反射器看到钥匙。 即使存在混淆,关键也应该显而易见。 那么,如何处理这个问题呢? 现在,我不需要 NSA 保护它,但我真的想防止任何人偷看。 谢谢。

编辑:感谢到目前为止的所有建议,有关此类事情的信息还不是很广泛,我真的很感谢一般提示和具体答案。

I have a program, where the password to a database is set by a remote user. The program saves the username and password to an encrypted string in an xml file that otherwise should be human readable. Now, this works fine, I use the C# DES encryption with a key, and it get encrypted and decrypted. Now, the problem is that anyone can use reflector to see the key. Even with obfuscation, the key should be readily apparent. So, how does one deal with this? Now, I don't need this to be NSA secure, but I really would like to prevent anyone from peeking. Thanks.

EDIT: Thanks for all of the advice so far, information on this sort of thing is not very widespread, and I really appreciate general tips as well as specific answers.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

银河中√捞星星 2024-08-04 22:17:26

尝试使用 DPAPI(System.Security.ProtectedData 类)。 这可以使用用户或计算机凭据保护您的加密数据。 因此,只有访问数据的用户帐户(用户凭据)或可以登录计算机的用户(计算机凭据)才能解密您的数据。

Try using DPAPI (System.Security.ProtectedData class). This protects your encrypted data using the user or machine credentials. So only the user account that's accessing the data (user credentials) or a user that can log in to the machine (machine credentials) will be able to decrypt your data.

何以心动 2024-08-04 22:17:26

这其实并不是relector与否的问题。 这是关于密钥管理的。 DES 和任何其他加密方案都依赖于定期更改密钥。 对代码中的密钥进行硬编码显然违反了这一点。 为了解决这个问题,您应该研究密钥管理。

编辑:详细说明一下:根据您的设置,您可以将散列密码存储在文件系统中并依赖于文件系统/用户安全性或存储在数据库中并依赖于数据库权限。

This is not really a problem about relector or not. It is about key management. DES and any other encryption scheme relies on keys being changed on a regular basis. Hard coding the key in code obviously violates this. To get around this, you should look into key management.

EDIT: To elaborate a bit: Depending on you setup, you could store the hashed passwords in the file system and rely on file system/user security or in a database an rely on the database rights.

终难遇 2024-08-04 22:17:26

您不应该使用应用程序中嵌入的秘密来加密您的密码,这是您麻烦的根源。 无论您的加密有多强,密钥都清楚地暴露在您的代码中。

您应该向用户询问凭据,将数据库用户/名称和密码存储在 app.config 的普通配置部分中,并依赖 DPAPI 支持 DpapiProtectedConfigurationProvider 类,使用计算机密钥或用户特定密钥为您加密和解密该部分。 请参阅我提供的链接,了解如何执行此操作的完整示例。

You shouldn't encrypt your password using a secret embedded in your application, that is the root of your troubles. No matter how strong your encryption is, the key is clearly exposed in your code.

You should ask your user for the credentials, store the db user/name and password in an ordinary configuration section in your app.config and rely on the DPAPI backed DpapiProtectedConfigurationProvider class to encrypt and decrypt the section for you, using either the machine keys or a user specific key. See the link I provided for a full example how to do this.

情场扛把子 2024-08-04 22:17:26

不幸的是,从来没有 100% 安全的方法来做到这一点。 您可以混淆代码,对秘密区域使用非托管代码,但由于您的应用程序能够再次读取密码,因此任何付出足够努力的攻击者也可以。

Unfortunately, there's never a 100% secure way of doing this. You can obfuscate the code, use unmanaged code for secret areas, but since your application is able to read the password again, so can any attacker who puts enough effort into it.

如梦亦如幻 2024-08-04 22:17:26

您根本不应该加密存储密码。 您应该使用单向哈希函数来存储它散列。 请参阅:

http://www.codinghorror.com/blog/archives/000953.html< /a>

You shouldn't be storing the password encrypted at all. You should be storing it hashed instead, with a one way hash function. See:

http://www.codinghorror.com/blog/archives/000953.html

后知后觉 2024-08-04 22:17:26

我们也有类似的情况。 我们最终将密钥放入文件中,并让用户输入某种密码(或使用散列的密钥)才能读取该文件。 让用户输入更多信息是很痛苦的,但它从程序中删除了密钥。

We had a similar situation. We ended up putting the key in a file and having the user enter some sort of password (or key using hashing) to be able to read the file. It was the pain of making the user enter more information, but it removes the key from the program.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文