在Java中,与数据库连接相关的密码字符串

huangapple go评论79阅读模式
英文:

String passwords in java on database connections

问题

最近,我们添加了一个工具来查找我们组织中的安全漏洞。其中一个发现的问题是,在连接到数据库时(例如使用Hikari),我们必须提供一个包含密码的字符串(当然是加密的,使用时会解密)。

现在,将密码保留在字符串中是不安全的,因为它可以被提取,直到垃圾收集器来清除它。

因此,我们开始更改我们的代码,使用char[]和byte[](不确定是否是最佳选择,但想法是在使用后清除数组,而不是等待垃圾收集器来清除它)来设置我们在Hikari上的密码。但流程的最后一部分是将一个未加密的密码字符串设置到Hikari中。所以所有这些麻烦都是为了发现Hikari将密码保存在一个字符串中。

那么,我应该更改Hikari代码并重新编译它,作为我们自己组织的Hikari实现,使用char[]中的密码吗?或者还有其他方法可以避免这个问题吗?

英文:

Recently we have added a tool to find security holes in our organization. One of the issues that was found is that when connecting to a database (ex. using Hikari), we have to provide a String containing the password (encrypted, of course, which will be decrypted when used).

Now, keeping passwords in Strings is not safe, because it can be extracted, until garbage collector comes and clears it.

So we started changing our code to use char[] and byte[] (not sure it's the best, but the idea is that we can clear the array after usage, and not wait for garbage collector to clear it for us) to set our passwords on Hikari, but the last part of the flow is setting an unencrypted password String to Hikari. So all this fuss to find out that Hikari is keeping the password inside a String..

So am I supposed to change Hikari code and recompile it as our own organization implementation of Hikari which use passwords from a char[]? or what?

How can we avoid this?

答案1

得分: 2

Now, keeping passwords in Strings is not safe, because it can be extracted, until garbage collector comes and clears it.

现在,将密码保存在字符串中是不安全的,因为它可以被提取,直到垃圾收集器来清除它。

So am I supposed to change Hikari code and recompile it as our own organization implementation of Hikari which use passwords from a char[]? or what?

那么,我应该更改Hikari的代码并重新编译它,作为我们自己组织的Hikari实现,以使用char[]中的密码吗?或者怎么办?

That is what you would need to do if you wanted to address this attack vector. Don't ever hold passwords in String objects, and make sure that you clear the char[] or byte[] or whatever that you use to hold them as soon as possible.

如果您想解决这个攻击向量,那就是您需要做的。绝对不要将密码保存在String对象中,并确保尽快清除用于保存它们的char[]byte[]或其他数据。

Are you "supposed" to do that? Shrug.

您是否“应该”这样做?耸耸肩。

My advice would be to do a full security risk assessment, look at all of the issues and decide whether or not addressing this one will make a significant difference to overall security. Balance that against the costs of creating and maintaining the Hikari patches. On the flip-side, quantify the costs to your organization if (these) passwords were stolen.

我的建议是进行一次全面的安全风险评估,审查所有问题,并决定是否解决这个问题会对整体安全性产生重大影响。将其与创建和维护Hikari补丁的成本相权衡。另一方面,量化一下如果(这些)密码被盗的话对您的组织造成的成本。

But it is not up to us to decide what you should. And it is not even possible to give you an objective recommendation, because we don't understand the full context.

但我们不能决定您应该做什么。而且,甚至不可能为您提供客观的建议,因为我们不了解完整的背景。

英文:

> Now, keeping passwords in Strings is not safe, because it can be extracted, until garbage collector comes and clears it.

Only if someone has sufficient access to capture what is in memory (or swap space on disk). If someone can do that, they can probably also do one or more of the following:

  • modify your application at the bytecode level to inject code to capture the secret
  • attach a debugger and use it to set a breakpoint at the point where the secret is used
  • read the secret from the file system, database, whatever
  • find the private key for your server's SSL certs and use it to snoop on the HTTPS traffic to your server,
  • walk out of your machine room with your hard drives, etc and then attack them at their leisure
  • and so on.

Spending a lot of effort to use char[] for handling passwords won't address any of those other ways of stealing the secrets.

And it won't address various other security blunders ... like porous firewalls, unencrypted backups saved to the cloud, keys on a stolen devops laptop, successful spear phishing, etc.

> So am I supposed to change Hikari code and recompile it as our own organization implementation of Hikari which use passwords from a char[]? or what?

That is what you would need to do if you wanted to address this attack vector. Don't ever hold passwords in String objects, and make sure that you clear the char[] or byte[] or whatever that you use to hold them as soon as possible.

Are you "supposed" to do that? Shrug.

My advice would be to do a full security risk assessment, look at all of the issues and decide whether or not addressing this one will make a significant difference to overall security. Balance that against the costs of creating and maintaining the Hikari patches. On the flip-side, quantify the costs to your organization if (these) passwords were stolen.

But it is not up to us to decide what you should. And it is not even possible to give you an objective recommendation, because we don't understand the full context.

huangapple
  • 本文由 发表于 2023年2月8日 20:39:08
  • 转载请务必保留本文链接:https://go.coder-hub.com/75385913.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定