我们的谷歌应用引擎应用程序存储了大量的个人识别信息（电子邮件，ssn等）来识别用户。我正在寻找有关如何保护这些数据的建议。
以两种形式存储敏感数据：
当我们需要查看时：
如果我们需要重新哈希数据或以原始格式处理数据：
保持哈希盐的秘密
如果攻击者获得数据存储区中的数据，以及我们的哈希盐，我担心他们可能会强行攻击敏感数据。其中一些（如SSN，一个9位数字）没有很大的密钥空间，所以即使使用现代哈希算法，我相信如果攻击者知道盐就可以做到。
我目前的想法是将盐保留在源代码控制之外，并保存在自己的文件中。该文件在部署期间加载到GAE，应用程序在需要散列传入数据时读取该文件。
在部署之间，salt文件位于受愤怒的熊（或保险箱）保护的USB密钥上。
盐只生活在两个地方
并且代码下载永久禁用，我想不出有人在没有窃取USB密钥的情况下获得盐的方法。我错过了什么吗？
保密我们的私人RSA密钥
不那么担心这个。我们很少需要解密加密版本（仅当我们更改哈希算法或数据格式时）。
私钥永远不必触及GAE服务器，我们可以下载加密数据，在本地解密，处理它，并重新上传加密/散列版本。
我们可以将我们的RSA私钥保存在由熊和老虎守卫的USB记忆棒上，并且只在我们需要它时将其拿出来。
我意识到这个问题并不完全是谷歌应用程序，但我认为GAE使情况有点独特。
如果我有完全控制权，我会做一些事情，例如锁定部署访问权限和使用双因素身份验证访问数据存储区查看器，但这些选项目前不可用（具有GAE特定密码是好的，但我喜欢参与RSA令牌。
我既不是GAE专家，也不是安全专家，所以如果我有一个漏洞，或者我想不出具体的平台，我很乐意听到。
答案 0 :(得分：11)
在决定安全架构时，首先要考虑的是威胁模型。谁是你的潜在攻击者，他们的能力是什么，你如何防御他们？如果不清楚您的威胁模型，您就无法评估您提出的安全措施是否足够，或者即使它们是必要的。
从你的文字中，我猜你正在寻求保护以防止以下某些部分：
对于前者，加密或散列数据存储数据可能就足够了（但请参阅本答案后面的注意事项）。保护后者更加困难，但只要您的管理员用户无法部署新的应用程序版本就无法执行任意代码，将密钥存储在未检入源代码管理的模块中，如您所示，应该可以正常工作因为即使使用管理员访问权限，他们也无法恢复密钥，也无法部署显示密钥的新版本。确保显然禁用了源代码的下载。
你正确地注意到有关使用有限数量的熵对数据进行哈希处理的一些担忧 - 你是对的。在某种程度上，盐可以通过防止预计算攻击来帮助解决这个问题，而关键拉伸，例如PBKDF2，scrypt和bcrypt中使用的，可以通过增加他们必须做的工作量来使攻击者的生活更加艰难。但是，对于像SSN这样的东西，你的密钥空间非常小，以至于没有任何密钥扩展会有所帮助 - 如果你对数据进行散列，并且攻击者获得了哈希值，他们将能够确定原始的SSN。
在这种情况下，您唯一可行的方法是使用密钥加密数据。现在，你的攻击者被迫暴力破解密钥以获取数据，这是一个难以达到数量级的挑战。
简而言之，我的建议是使用标准（私钥）密码加密您的数据，密钥存储在不受源代码控制的模块中。使用散列代替只会削弱您的数据，而使用公钥加密并不能提供明显的安全性来防止您使用标准密码时尚未拥有的任何合理的威胁模型。
当然，如果可以的话，保护用户数据的首要方法是不首先将其存储起来。 ：）
答案 1 :(得分：3)
你可以通过使用HMAC，一个秘密密钥和每个条目的独特盐来增加你的哈希算法安全性（我知道人们在这方面会不同意我，但我的研究认为它有助于避免某些攻击）。您还可以使用bcrypt或scrypt进行哈希处理，这会使哈希反转成为一个非常耗时的过程（但您也必须考虑到这一点，因为您的应用程序需要计算哈希值）。
通过禁用代码下载并保护您的密钥，我无法想象某人如何能够抓住它。只需确保您的代码在类似的安全防护下受到保护，或者在开发过程中从代码中删除密钥，并将其拉出来进行部署。我假设你会在你的代码中保留你的秘密密钥（我听说很多人都说要将它保存在内存中以保证超级安全，但考虑到AppEngine和实例的性质，这是不可行的。）
更新： 请务必为拥有应用管理员权限的所有Google帐户启用双因素身份验证。 Google提供此功能，因此不确定您是否对外部强制实施此限制。
答案 2 :(得分：1)
加密数据存储上数据的有趣方法。经过这个，我想到的一个问题是你如何在哈希上查询数据？你使用两个哈希或更细粒度哈希的比较？同样，如何在散列和加密表格中的数据后完成大于值，小于值的操作？
Fine grained hashing意思是，您是否对数据流的连续字节进行散列以获取累积的散列值。即hash（abcd）= hash（a，b）+ hash（b，c）+等。这种类型的散列会告诉底层数据有多相似而不是匹配。