我构建了一个 CMS 系统，允许用户在客户的 Intranet 应用程序上创建和管理在线表单。
当然，表单处理的某些数据可能需要加密，例如如果系统用于构建处理薪资细节或其他内容的表单。所以我正在使用AESManaged类在此类数据进入我们的应用程序数据库之前对其进行对称加密。
一切都很好，但现在，在发布之前，我可以就以下问题进行指导shared secret and salt.
我最初的想法是制作一个（动态的）shared secret通过组合（基于 GUID）IDForm包含带有（同样基于 GUID）id 的加密字段Question该字段是以下问题的答案：
FormId:QuestionId
My Salt目前以相同的方式生成，只是 Guid 的顺序相反，即。
QuestionID:FormID.
我对这些东西很陌生，所以不确定这是否是一个明智的策略，或者我是否应该以其他方式来做？
盐应该是随机生成的值。其目的是使字典/暴力攻击更难以执行。维基百科有一篇关于加密盐的好文章：http://en.wikipedia.org/wiki/Salt_（密码学 http://en.wikipedia.org/wiki/Salt_(cryptography)
对于共享密钥，理想情况下它不会是与它所加密的数据（例如您的 ID）一起未加密存储的值。通常，最佳实践是由最终用户或管理员以某种方式选择密钥，以便他们可以定期轮换密钥，或者在发生某种安全漏洞时进行轮换。该密码密钥可以由 CMS 的每个用户或管理员帐户拥有。如果您有非常严格的安全要求，您可以寻求第三方密钥管理服务器。
如果这里的主要目标更多的是混淆，并且 CMS 不会受到某种形式的安全审核，那么按照您最初的想法进行一些操作就可以了。它将防止随意访问数据，但可能无法通过正式标准的审核，正式标准需要随机盐、轮换密钥的方法以及系统“所有者”更改密码的方法，以便您自己无法访问该数据。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
