0

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?

Chris
  • 165
  • 3
  • 12
  • "*Now, keeping passwords in Strings is not safe... So we started changing our code to use char[] and byte[]*" How do you think Strings store their characters? Pre-java 9, `char[]` and now `byte[]`. This exercise is pointless. You are just making your own life significantly harder, to - at best - mildly inconvenience an attacker. https://en.wikipedia.org/wiki/Security_through_obscurity – Michael Feb 08 '23 at 12:42
  • 4
    "*it can be extracted, until garbage collector comes and clears it*" If an attacker has physical access to your server's memory, you have bigger problems than them reading passwords. – Michael Feb 08 '23 at 12:42
  • 2
    Perhaps the "tool" should be ignored? Don't do everything a computer tells you to do. – undefined symbol Feb 08 '23 at 12:49
  • So from your comments my understanding is that this is pointless and using encrypted strings is fine. Correct? – Chris Feb 08 '23 at 12:55
  • Are you talking about a client or a server? – g00se Feb 08 '23 at 12:57
  • Everything is server side. Spring-Boot – Chris Feb 08 '23 at 12:59
  • OK, then that's alright – g00se Feb 08 '23 at 13:00
  • @Michael the idea with char[] was that you can clear it after usage by making the array empty. – Chris Feb 08 '23 at 13:02
  • Hash passwords and validate hash with hash. – DevilsHnd - 退職した Feb 08 '23 at 14:02
  • 1
    Related: [Eliminating Passwords from the JVM Heap](https://stackoverflow.com/q/59548500/12567365). Similar conclusion to other comments and answers here: spend your security effort where it will have the most impact. – andrewJames Feb 08 '23 at 14:03
  • This is tagged HikariCP, but that is basically irrelevant. All JDBC APIs that expect passwords (including `DriverManager` or `DataSource`) expect them as strings. If you don't want to use strings, then you should look if your JDBC driver supports alternative authentication mechanisms which don't involve passwords. – Mark Rotteveel Feb 13 '23 at 16:00

1 Answers1

2

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.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216