我们在哪里存储密钥/密码/盐用于加密？

Question

我的应用需要加密一些数据(用户会话令牌).我看到的大多数示例都有一个使用密码和盐生成密钥的方法,如:

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

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

1. 让用户每次启动应用程序时都输入它(让用户烦恼).
2. 将密码硬编码到应用程序本身.对用户来说更方便,但有人可以找出你的应用二进制文件的密码.
3. 随机生成密码,但我们必须将生成的密钥存储在磁盘上.现在我们刚刚将问题转移到必须将密钥安全地存储在磁盘上,这似乎也是不可能的.如果攻击者发现生成的密钥,那么大问题.

选项#1对我不起作用.选项#2和#3似乎存在固有的缺陷,除非我非常误解如何解决这个问题(希望我是这样).如果我们不能使用#1,建议的方法是什么？我们是否为攻击者提出了一堆混淆的箍,希望能够获得最佳效果？

谢谢

Answer 1

“我们是否会放置一堆混乱的圆圈，让攻击者跳过并希望得到最好的结果？” 基本上是的。圈的大小和数量决定了你想要制作的难度。

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

1. 将标头的前 1024 字节（它是 MP4）替换为从应用程序图像资源之一的中间获取的 1024 字节。我尝试了几个修复程序，所有这些修复程序都无法自动恢复文件 - 尽管可以手动完成。然后...

2. 使用从另一个图像资产获取的 256 字节私钥对文件进行加密。

3. 当密钥被提取时，它会通过一种算法进行哈希处理，该算法会执行各种其他无意义的数学运算来破坏密钥。

4. 使用预编译混淆器。

我尝试过对它进行逆向工程，即使知道它是如何完成的，但它是如此困难，以致于使努力不值得结果。

关于 SO 有很多讨论，总结如下：如果你只是想停止复制，那就让它变得困难（成本与回报），但否则就高枕无忧，因为最终你无能为力。如果数据具有商业敏感性，则需要具有系统级安全性（例如，全设备加密且无需root）的服务器。