我正在构建一个应用程序，该应用程序将使用AES/CBC/PKCS5PADDING方法在其设备上加密用户的数据，并且安全性非常重要。我想防止蛮力攻击，以防有人掌握数据库。
表中的每一行都有关联的标题。我不确定什么用作种子。我可以做以下一个：
-
硬代码在来源中我自己的种子，但我相信如果有人对我的应用程序进行了反复编译
可以阅读。 使用用户输入的标题作为种子
使用我自己的种子的串联以及输入的标题
除非有其他方式，在上述所有情况下，我都可以看到一个弄清楚种子的人。这对他们能够暴力强制加密数据对他们有用吗？当然，在上述所有情况下，我还将用户的密码作为密钥的一部分。
我如何使潜在黑客更加困难？
编辑(重新编辑(
基于以下答复以及我的研究和思考过程。我想我可以做以下操作。
- 让用户输入密码，但不将其存储在数据库中
- 在存储敏感数据之前，他们必须输入标签以识别它。我将其作为清晰的文本存储在数据库中，并将其用作盐
- 我将使用用户的密码并使用PBKDF2标签来生成键，但不会存储它
- 我将使用＃3的生成密钥来加密敏感数据
- 要解密，我将再次基于用户的密码和行标签生成密钥，并将其使用它来解密敏感数据
这听起来对吗？如果黑客使用两列掌握数据库 - 标签清晰文本和加密数据，是否可以推断出任何内容？
？编辑2
我正计划构建一个特定的Android应用程序，并且以下链接在我需要的内容上发表。
https://nelenkov.blogspot.in/2012/04/using-password lase-lase-encryption-on.html？m = 1
https://android-developers.googleblog.com/2013/02/using-cryptography-to-store-store-credentials.html?m=1
这里的问题是，每当某人对您的应用程序进行反复编译时，生成密钥的方法都是琐碎的。因此，如果已知该密钥生成的所有输入数据，则生成密钥是微不足道的。
因此，您可能需要为用户提供输入将与AES加密一起使用的密码。确保您使用诸如PBKDF2之类的系统以使其难以强迫密码。
如果您的数据库未存储在用户的设备上，而是在外部设备上，那么您可能会在设备上生成和存储一个安全的随机键，并在数据实际存储在中央数据库中之前对其进行加密。<<<<<<<<<<<<<<<<<<<<<<<<<<<</p>
根据我的评论和您的编辑，可能的解决方案可以归结为此(我并不是Java程序员，但是以下伪代码应该很清楚(：
aesKey <- PBKDF2-SHA512(userPassword)[:32]
hmacKey <- PBKDF2-SHA512(userPassword)[32:] // PBKDF2-SHA512 has a natural 64 byte output
iv <- CSPRNG(16) // 16 byte IV for AES from a CSPRNG
ciphertext <- AES256CBC(plainText, aesKey, iv) // Use PKCS5Padding
result <- iv + ciphertext // Prepend the IV.
result <- HMAC-SHA256(result, hmacKey) + result
// Prepend the HMAC of the IV and ciphertext using the hmacKey. Always encrypt THEN mac.
有几个重要说明：
您应该始终将IV包括在HMAC中，例如不要仅仅是ciphertext。
SHA512和SHA256的选择很重要。由于SHA512的自然输出为64个字节，因此非常适合使用PBKDF2得出两个32个字节键。如果调整此算法，那么您将不仅要使用最终的PBKDF2迭代来生成下一个字节，这不是有益的。
您用于PBKDF2的盐实际上并不重要。您可以随机生成它并将其与密文一起存储，但是，在这种情况下，PBKDF2的静态盐是可以的。