我应该如何导出 AES 加密数据库条目的密钥和初始化向量？
我构建了一个 CMS 系统，允许用户在客户的 Intranet 应用程序上创建和管理在线表单。
当然，表格处理的一些数据可能需要加密，例如，如果系统用于构建处理工资细节或其他内容的表格。因此，我使用 AESManaged 类在此类数据进入我们的应用程序数据库之前对其进行对称加密。
一切都很好，但现在，在发布之前，我可以对共享秘密和salt进行指导。
我最初的想法是通过将包含加密字段的Form的（基于GUID的）ID与（同样，基于GUID的）相结合来创建（动态）共享秘密 ) Question 字段的 id 是以下问题的答案：
FormId:QuestionId
我的 Salt 当前以相同的方式生成，只是 Guid 的顺序相反，即。
QuestionID:FormID.
我对这些东西很陌生，所以不确定这是否是一个明智的策略，或者我是否应该以其他方式来做？
I've built a CMS system to allow users to create and manage online forms on my client's intranet app.
Of course some of the data handled by the forms may need to be encrypted e.g. if the system is used to build a form that handles salary specifics or whatever. So I'm using the AESManaged class to symmetrically encrypt this sort of data prior to it going into our application db.
All is fine, but now, prior to release, I could do with a steer regarding the shared secret and salt.
My original idea was to make a (dynamic) shared secret by combining the (GUID-based) ID of the Form containing the encrypted field with the (again, GUID-based) id of the Question the field is the answer to:
FormId:QuestionId
My Salt is currently generated the same way, only with the order of Guids reversed ie.
QuestionID:FormID.
I'm new to this stuff so not sure if this a sensible strategy or if I should be doing it some other way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
盐应该是随机生成的值。其目的是使字典/暴力攻击更难以执行。维基百科有一篇关于加密盐的好文章：
http://en.wikipedia.org/wiki/Salt_(cryptography)
对于共享理想情况下，它不会是与它所加密的数据（例如您的 ID）一起未加密存储的值。通常，最佳实践是由最终用户或管理员以某种方式选择密钥，以便他们可以轮换它。定期或发生某种安全漏洞时，该密码密钥可能由 CMS 的每个用户或管理员帐户拥有，如果您有非常严格的安全要求，则可以寻求第三方密钥管理服务器
。这里的目标更多的是混淆，并且 CMS 不会受到某种形式的安全审核，然后按照您最初的想法进行一些操作，它会阻止随意访问数据，但可能不会通过针对正式标准的审核。这将需要随机盐、轮换密钥的方法以及系统“所有者”更改密码的方法，以便您自己无法访问数据。
The salt should be a randomly generated value. Its purpose is to make dictionary/brute force attacks more difficult to execute. Wikipedia has a nice article on cryptographic salts:
http://en.wikipedia.org/wiki/Salt_(cryptography)
For the shared secret ideally it would not be a value that was stored unencrypted with the data that it was encrypting (such as your ids). It's generally a best practice that the key be chosen somehow by the end-user or admin so that they could rotate it periodically or if some sort of security breach occurred. This password key could be owned by each user of the CMS or perhaps by an admin account. If you have very serious security requirements you could pursue a third-party Key Management Server.
If the main goal here is more of obfuscation and the CMS will not be subject to some form of security audit then something along the lines of your initial idea would do. It would prevent the casual access of the data but would probably not pass an audit against formal standards that would require a random salt, a way to rotate the keys, and a way for the "owner" of the system to change the password such that you yourself could not access the data.