使用 AES 加密来加密和解密密码与在 JBOSS 保管库中存储密码相比的优势
我们的安全部门不希望我们拥有包含我们要连接的数据库的纯文本密码的 JOSS Web 配置文件 (oracle-db.properties)。有人告诉我应该从 JBOSS 密码库检索密码，但我很难弄清楚如何执行此操作，并发布了一个问题来尝试找出答案。 （请参阅Java/Spring：如何从JBOSS保管库检索密码< /a> ）
我正在考虑是否将密码加密后的密码存储在 oracle-db.properties 中并使用此处显示的 AES 加密算法，https://howtodoinjava.com/java/java-security/aes-256 -encryption-decryption/，对其进行解密（我使用加密过程来确定要放入 oracle-db.properties 文件中的加密密码）。我在想，因为Secret key和salt都存储在代码中，所以有可能可以通过反向编译代码来获取这些值。我想知道这种方法与从 JBOSS Vault 检索密码相比有何优缺点（https://access.redhat.com/documentation/en-us/red_hat_jboss_web_server/5.3/html/installation_guide/vault_for_jws_）。对于大多数公司来说，将 AES 256 添加到我们的应用程序中通常就足够了吗？
Our Security Department doesn’t want us to have JOSS web configuration file (oracle-db.properties) that contain the plain text password of the database that we are connecting to. I was told that I should retrieve the password from a JBOSS Password vault but am having difficulty trying to figure out how to do this and have posted a question to try and find out. (see Java/Spring: How to retrieve password from JBOSS vault )
I am considering whether storing the password encrypted password in the oracle-db.properties and using this AES-Encryption Algorithm shown here, 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_) . Would adding the AES 256 to our application generally be sufficient for most companies?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正确的。 AES 加密该密码几乎没有任何作用，事实上，事情变得更糟：它看起来是加密的（因为它确实是加密的），人们会认为进行加密的人不会如此密集以至于离开密码文件旁边的密钥。
除了它实际上就在那里（他们必须反编译类文件，但这并不困难，也不能变得困难），所以你创造了错误的印象。
您的安全团队需要为您提供可使用的威胁模型，他们不能只是说“不要从文件中读取密码”，因为这是不可能的。 为什么你不能这样做？他们想要减轻哪些攻击途径？
示例：
cat-ing 该文件，从而将密码涂抹在他们的屏幕上和终端应用程序的历史缓冲区中，供任何人随意浏览。答案：只需对其进行 base64 处理即可。是的，它根本不是加密货币，但至少它毫不掩饰：人们会看到它的 base64 并假设他们不是白痴知道这意味着密码就在那里。但它可以防止肩窥和“意外”回忆（有人亲眼看到过它，因此即使他们不打算记住它，也可能会记住它）。必须有人不遗余力地对其进行 unbase64，如果规则规定你不能这样做，那么至少你现在已经迫使员工彻底违反规则并可能犯下犯罪行为。
然后，base64 什么事都不做，AES 计划也不会做（因为它们可能还可以使您的网络服务器
cat拥有自己的 jar 和类文件）。一种解决方案是启动服务器的脚本读取文件（并且由root操作，在webserver帐户下运行服务器） - 该脚本读取密码（从而允许您使该文件由 root 拥有并且无法被webserver帐户读取），将其作为参数或环境变量传递。当然，这要求您考虑泄漏环境变量的风险远低于文本文件。这当然是可能的。或者，脚本可以将密码写入 Web 服务器用户可读的纯文本文件中，Web 服务器将读取它，然后删除该文件。这并不常见，但它显示了威胁模型的要点：一旦您知道自己在对抗什么，您就可以制定计划并相应执行。这不是明智的安全策略：这不是威胁模型。 JPV 并没有解决任何这些问题。
webserver用户的 root 和/或写入访问权限，从而无法将其用作攻击数据库的跳板。这是不可能的，如果安全团队告诉你这是他们需要你缓解的威胁，你可以告诉他们去拿哈利波特的魔杖，因为没有它，你就无法交付。例如，黑客可以简单地重写您自己的类/jar，以将密码发送到黑客的服务器。这强烈表明您的安全团队不知道如何做好他们的工作：他们会考虑风险，无论风险多么不可能，并要求“防范”风险（实际上不是一件事；您可以减少和缓解，安全不是黑色的）和白色）而不考虑威胁模型或权衡。
让他们接受教育，或者决定对他们撒谎。否则，当他们这样做时，你就赢不了。也许超越他们的头脑并让老板参与进来。
可行，但很棘手。一种简单的方法是服务器也不知道密码，并且将以仅管理员模式启动，其中管理员将数据库密码键入表单，然后解锁服务器以正常运行。然后，服务器可以仅将该密码保留在内存中，从而阻止任何磁盘副本。除此之外，您最好关闭交换或将其存储在不同的磁盘上！
如果您不想手动操作，可以使用 TPM 芯片（通常是 Windows/Linux 系统）或 T2（苹果）。我不知道有任何java可访问的工具可以做到这一点，或者数据库可以做到这一点。此类算法需要质询/响应模型，您不能仅以有意义的方式在其中“存储密码”。
向安全团队询问8万左右的预算。如果他们犹豫不决，那么，他们已经学到了一些东西。安全是一场权衡游戏。
Correct. AES encrypting that password accomplishes almost nothing, and in fact makes things worse: It looks encrypted (because it is), and one would assume the persons doing the encryption wouldn't be so incredibly dense as to leave the key right there next to the password file.
Except that it is effectively right there (they'd have to decompile the class files but that's not difficult and cannot be made difficult), so you've created the wrong impression.
Your security team needs to give you threat models to work with, they can't just say "do not read password from file", because that is impossible. Why can you not do that? What avenue of attack do they want to mitigate?
Examples:
cat-ing that file and thus smearing the password all over their screen and in their terminal app's history buffers for anybody to just shouldersurf.ANSWER: Just base64 it. Yes, it's not crypto at all, but at least it makes no bones about it: Folks will see its base64 and assuming they aren't idiots know that means the password is right there. But it's protected against shouldersurfing and 'accidental' recollection (where someone has seen it with their eyes and may therefore just remember it even if they don't intend to). Someone has to go out of their way to unbase64 it, and if the rules say you can't do that, at least you've now forced an employee to outright break rules and potentially be committing a crime.
Then the base64 thing does nothing, nor does the AES plan (as they can also make your webserver
catits own jars and class files, probably). One solution can be that the script that starts the server reads the file (and isroot-operated, running the server under awebserveraccount) - that script reads the password (thus allowing you to make that file owned by root and unreadable by thewebserveraccount), passes it as argument or environment var. Of course, this requires that you consider the risk of leaking an env var as considerably lower than a text file. Which is certainly possible. Alternatively, the script can write the password in a plain text file readable by thewebserveruser, and the webserver will read it, then delete the file. This isn't common, but it shows the point of threat models: Once you know what you're fighting, you can come up with a plan and execute accordingly.That is not sensible security policy: That is not a threat model. JPV doesn't solve any of these problems, to boot.
webserveruser to not be able to use that as a springboard to hack the DB.This is impossible, if the security team tells you this is the threat they need you to mitigate, you can tell them to go fetch Harry Potter's magic wand, because without it, you can't deliver. The hacker can simply rewrite your own classes/jars into sending the password to the hacker's servers, for example. This is strongly indicative your security team doesn't know how to do their job: They think of risks no matter how unlikely and demand it is 'protected against' (not really a thing; you can reduce and mitigate, security isn't black and white) without considering threat models or tradeoffs.
Get them educated, or decide to lie to them. You can't win when they act like this otherwise. Go over their heads maybe and get the boss involved.
Doable, but tricky. One easy way is that the server won't know the password either and will boot in an admin-only-mode, where the admin types the db password into a form which then unlocks the server to run properly. The server can then retain this password in memory only, thus foiling any disk copies. Except, you better turn of swap or store that on a different disk!
If you don't want that manual action, there's TPM chips (windows/linux systems generally) or T2 (apple). I don't know of any java-accessible tools that can do this, or DBs that can. These kinds of algorithms require a challenge/response model, you can't just 'store a password' in these in a meaningful way.
Ask the security team for a budget of 80k or so. If they balk, well, they've learned something. Security is a game of tradeoffs.