java - 我们在哪里存储用于加密的 key /密码/盐？

Question

我的应用需要加密一些数据(用户 session token )。我看到的大多数示例都有一种使用密码和盐生成 key 的方法，例如:

public static Key generateKey(char[] passphrase, byte[] salt) {
    ...
}

我的理解是我们有三种生成密码的选项:

1. 让用户在每次应用启动时输入它(对用户来说很烦人)。
2. 将密码短语硬编码到应用程序本身。对用户来说更方便，但有人可以通过您的应用程序二进制文件找到您的密码。
3. 随机生成一个密码，但我们必须将生成的 key 存储在磁盘上。现在我们只是将问题转移到必须将 key 安全地存储在磁盘上，这似乎也是不可能的。如果攻击者找到了生成的 key ，那就是大问题了。

选项 #1 对我不起作用。选项 #2 和 #3 似乎存在固有缺陷，除非我严重误解了如何解决这个问题(希望我是)。如果我们不能使用#1，推荐的方法是什么？我们是否设置了一堆混淆的环，让攻击者跳过并希望获得最好的结果？

谢谢

Answer 1

“我们是否放入了一堆混淆的环，让攻击者跳过并希望获得最好的结果？”基本上是的。圈的大小和数量取决于您想要制作的难度。

如果您不使用服务器，那么您对数据进行混淆和加密的任何操作都是可逆的。但是，您可以让它变得非常困难。例如，我用来保护一些视频 Assets 的技术。

1. 将 header 的前 1024 个字节(它是 MP4)替换为取自某个应用图像 Assets 中间的 1024 个字节。我尝试了几个修复程序，但都无法自动恢复文件——尽管可以手动完成。然后……

2. 使用从另一个图像 Assets 中获取的 256 字节私钥加密文件。

3. 提取 key 后，它会通过一种算法进行散列处理，该算法会执行各种其他无意义的数学运算来破坏 key 。

4. 使用预编译混淆器。

我自己尝试过对其进行逆向工程，即使知道它是如何完成的，但它是如此困难，以至于付出的努力得不偿失。

关于 SO 的讨论有很多，总结为；如果你只是想停止复制，那就让它变得困难(成本与返回)，但否则就睡个好觉，因为最终你无能为力。如果数据具有商业敏感性，则需要具有系统级安全性(例如整个设备加密和无根)的服务器。