使用 AES 加密加密和解密密码与将密码存储在 JBOSS 保管库中相比的优势
Advantages of using AES Encryption to encrypt and decrypt password vs storing password in JBOSS vault
我们的安全部门不希望我们拥有 JOSS Web 配置文件 (oracle-db.properties)，其中包含我们正在连接的数据库的纯文本密码。我被告知我应该从 JBOSS 密码保险库中检索密码，但我很难弄清楚如何做到这一点，并发布了一个问题来尝试找出答案。 （参见 Java/Spring: How to retrieve password from JBOSS vault ）
我正在考虑是否将密码加密后的密码存储在 oracle-db.properties 中并使用这里显示的 AES 加密算法，https://howtodoinjava.com/java/java-security/aes-256-encryption-decryption/, to decrypt it (I use the encrypt procedure to determine the encrypted password to put in the oracle-db.properties file). I was thinking that, because the Secret key and salt are stored in the code, it is possible that the code can be reverse compiled to get these values. I was wondering what the pros and cons of this method vs retrieving the password from the JBOSS Vault (https://access.redhat.com/documentation/en-us/red_hat_jboss_web_server/5.3/html/installation_guide/vault_for_jws_)。对于大多数公司来说，将 AES 256 添加到我们的应用程序中通常就足够了吗？
I was thinking that, because the Secret key and salt are stored in the code, it is possible that the code can be reverse compiled to get these values.
正确。 AES 对该密码进行加密几乎什么也做不了，而且实际上让事情变得更糟：它 看起来 加密（因为它是），并且人们会认为进行加密的人不会如此密集至于将密钥留在密码文件旁边。
除了它 是 有效地在那里（他们必须反编译 class 文件，但这并不困难，也不会变得困难），所以你'造成了错误的印象。
您的安全团队需要为您提供威胁模型，他们不能只说“不要从文件中读取密码”，因为那是不可能的。 为什么你不能那样做？他们想要缓解什么攻击途径？
示例：
- 我不希望 syadmin 随意
cat-ing 该文件，从而将密码弄脏了他们的屏幕和他们的终端应用程序的历史缓冲区，让任何人都可以浏览。
答案：只需 base64 即可。是的，它根本不是加密货币，但至少它毫不掩饰：人们会看到它的 base64 并假设他们不是白痴知道这意味着密码就在那里。但它可以防止 shouldersurfing 和 'accidental' 回忆（有人亲眼看到它，因此即使他们不打算记住它也可能只是记住它）。必须有人竭尽全力对它进行 unbase64，如果规则说你不能那样做，至少你现在已经强迫员工彻底违反规则并可能犯罪。
- 恐怕有人会破解服务器，使其勉强读取文件并将它们回显给黑客。
然后 base64 什么都不做，AES 计划也不做（因为它们还可以使您的网络服务器 cat 成为自己的 jars 和 class 文件，可能）。一种解决方案是启动服务器的脚本读取文件（并且是 root 操作的，运行 在 webserver 帐户下连接服务器） - 该脚本读取密码（因此允许您使该文件由 root 拥有并且 webserver 帐户无法读取），将其作为参数或环境变量传递。当然，这要求您考虑泄漏环境变量的风险远低于文本文件。这当然是可能的。或者，脚本可以将密码写入 webserver 用户可读的纯文本文件，网络服务器将读取它，然后删除该文件。这并不常见，但它显示了威胁模型的要点：一旦你知道你在战斗什么，你就可以想出一个计划并相应地执行。
- 我想使用 JBoss 密码库
那不是明智的安全策略：那不是威胁模型。 JPV 不能解决任何这些问题，引导。
- 我想要一个黑客获得对盒子的完全访问权限，包括 root and/or write-access
webserver 用户不能将其用作跳板来破解数据库
这是不可能的，如果安全团队告诉你这是他们需要你缓解的威胁，你可以告诉他们去拿哈利波特的魔杖，因为没有它，你不能送货。例如，黑客可以简单地重写您自己的 classes/jars 以将密码发送到黑客的服务器。这强烈表明您的安全团队不知道如何完成他们的工作：他们会考虑风险，无论它多么不可能并要求它 'protected against'（不是真的；您可以减少和减轻，安全性不是黑白）而不考虑威胁模型或权衡。
让他们接受教育，或者决定对他们撒谎。如果他们不这样做，你就赢不了。也许越过他们的头脑，让老板参与进来。
- 我希望设法获得整个磁盘克隆的黑客无法访问数据库。
可行，但很棘手。一种简单的方法是服务器也不会知道密码，并且将以 admin-only-mode 模式启动，管理员将数据库密码键入一个表单，然后将服务器正确解锁为 运行。然后服务器可以仅将此密码保留在内存中，从而阻止任何磁盘副本。除了，你最好关闭交换或将其存储在不同的磁盘上！
如果您不想手动操作，可以使用 TPM 芯片（windows/linux 通常是系统）或 T2（苹果）。我不知道有任何 java-accessible 工具可以做到这一点，也不知道有什么数据库可以做到这一点。这些类型的算法需要一个 challenge/response 模型，您不能仅以有意义的方式 'store a password' 在其中。
向安全团队索要80k左右的预算。如果他们犹豫不决，那么，他们已经学到了一些东西。安全是一种权衡游戏。
我们的安全部门不希望我们拥有 JOSS Web 配置文件 (oracle-db.properties)，其中包含我们正在连接的数据库的纯文本密码。我被告知我应该从 JBOSS 密码保险库中检索密码，但我很难弄清楚如何做到这一点，并发布了一个问题来尝试找出答案。 （参见 Java/Spring: How to retrieve password from JBOSS vault ）
我正在考虑是否将密码加密后的密码存储在 oracle-db.properties 中并使用这里显示的 AES 加密算法，https://howtodoinjava.com/java/java-security/aes-256-encryption-decryption/, to decrypt it (I use the encrypt procedure to determine the encrypted password to put in the oracle-db.properties file). I was thinking that, because the Secret key and salt are stored in the code, it is possible that the code can be reverse compiled to get these values. I was wondering what the pros and cons of this method vs retrieving the password from the JBOSS Vault (https://access.redhat.com/documentation/en-us/red_hat_jboss_web_server/5.3/html/installation_guide/vault_for_jws_)。对于大多数公司来说，将 AES 256 添加到我们的应用程序中通常就足够了吗？
I was thinking that, because the Secret key and salt are stored in the code, it is possible that the code can be reverse compiled to get these values.
正确。 AES 对该密码进行加密几乎什么也做不了，而且实际上让事情变得更糟：它 看起来 加密（因为它是），并且人们会认为进行加密的人不会如此密集至于将密钥留在密码文件旁边。
除了它 是 有效地在那里（他们必须反编译 class 文件，但这并不困难，也不会变得困难），所以你'造成了错误的印象。
您的安全团队需要为您提供威胁模型，他们不能只说“不要从文件中读取密码”，因为那是不可能的。 为什么你不能那样做？他们想要缓解什么攻击途径？
示例：
- 我不希望 syadmin 随意
cat-ing 该文件，从而将密码弄脏了他们的屏幕和他们的终端应用程序的历史缓冲区，让任何人都可以浏览。
答案：只需 base64 即可。是的，它根本不是加密货币，但至少它毫不掩饰：人们会看到它的 base64 并假设他们不是白痴知道这意味着密码就在那里。但它可以防止 shouldersurfing 和 'accidental' 回忆（有人亲眼看到它，因此即使他们不打算记住它也可能只是记住它）。必须有人竭尽全力对它进行 unbase64，如果规则说你不能那样做，至少你现在已经强迫员工彻底违反规则并可能犯罪。
- 恐怕有人会破解服务器，使其勉强读取文件并将它们回显给黑客。
然后 base64 什么都不做，AES 计划也不做（因为它们还可以使您的网络服务器 cat 成为自己的 jars 和 class 文件，可能）。一种解决方案是启动服务器的脚本读取文件（并且是 root 操作的，运行 在 webserver 帐户下连接服务器） - 该脚本读取密码（因此允许您使该文件由 root 拥有并且 webserver 帐户无法读取），将其作为参数或环境变量传递。当然，这要求您考虑泄漏环境变量的风险远低于文本文件。这当然是可能的。或者，脚本可以将密码写入 webserver 用户可读的纯文本文件，网络服务器将读取它，然后删除该文件。这并不常见，但它显示了威胁模型的要点：一旦你知道你在战斗什么，你就可以想出一个计划并相应地执行。
- 我想使用 JBoss 密码库
那不是明智的安全策略：那不是威胁模型。 JPV 不能解决任何这些问题，引导。
- 我想要一个黑客获得对盒子的完全访问权限，包括 root and/or write-access
webserver用户不能将其用作跳板来破解数据库
这是不可能的，如果安全团队告诉你这是他们需要你缓解的威胁，你可以告诉他们去拿哈利波特的魔杖，因为没有它，你不能送货。例如，黑客可以简单地重写您自己的 classes/jars 以将密码发送到黑客的服务器。这强烈表明您的安全团队不知道如何完成他们的工作：他们会考虑风险，无论它多么不可能并要求它 'protected against'（不是真的；您可以减少和减轻，安全性不是黑白）而不考虑威胁模型或权衡。
让他们接受教育，或者决定对他们撒谎。如果他们不这样做，你就赢不了。也许越过他们的头脑，让老板参与进来。
- 我希望设法获得整个磁盘克隆的黑客无法访问数据库。
可行，但很棘手。一种简单的方法是服务器也不会知道密码，并且将以 admin-only-mode 模式启动，管理员将数据库密码键入一个表单，然后将服务器正确解锁为 运行。然后服务器可以仅将此密码保留在内存中，从而阻止任何磁盘副本。除了，你最好关闭交换或将其存储在不同的磁盘上！
如果您不想手动操作，可以使用 TPM 芯片（windows/linux 通常是系统）或 T2（苹果）。我不知道有任何 java-accessible 工具可以做到这一点，也不知道有什么数据库可以做到这一点。这些类型的算法需要一个 challenge/response 模型，您不能仅以有意义的方式 'store a password' 在其中。
向安全团队索要80k左右的预算。如果他们犹豫不决，那么，他们已经学到了一些东西。安全是一种权衡游戏。