How to avoid using String for passwords or secrets with 3rd party libraries that require a String?

I'm working on a Java service that had a security bug logged against it, concerning a secret stored in a Java String object.

The concern is that once a password is stored in a String, it stays in the string pool until it's garbage collected, and could show up in a dump as clear text.

I understand that Java's String class is immutable, and it is preferred that secrets or passwords be stored in a mutable class, so it can be removed from memory as soon as possible after use.

References

• Why is char[] preferred over String for passwords?
• Java equivalent of SecureString
• In Java, is there still a point in using char[] instead of String to store passwords?
• Answer by StephenC to similar question

However, I find this impractical when working with 3rd party libraries, as many of them want the password or secret passed in the request as a String object, which no matter how safe I am, in my code, ultimately converts the char[] array into a String, which takes us back to the original problem, doesn't it?

So, is there anyway to convert a char[], or StringBuffer to a String, without getting back to the original problem?

EDIT: As pointed out by the comments in this question and other similar questions, many believe this is not a real concern, as there's no easy way to avoid the issue if you don't own ALL the code in your application (ie don't pass secrets to any 3rd party libraries). So given this, maybe the question becomes

How can I refute the bug? is there a good solid reference from Oracle/Owasp or whoever that says "unsolvable problem" ?

You can't avoid creating a String if you need to call an API that requires a String. As long as you avoid string literals or explicitly interned strings, strings don't end up in the string pool.

This is also an impossible problem to solve. For example, if this is a password for a database connection pool, the password needs to be available for the lifetime of the program to be able to create new connections. And even if you could provide the password in some clearable way like a char[], CharBuffer, StringBuilder, etc., there is no guarantee that the API you're calling doesn't transform it to a string, or makes a copy, etc., etc.

Even using a char[] does not guarantee that you're able to correctly purge it from memory: Java garbage collectors can and will move objects around, so it is entirely possible that your password is still in memory at a previous location, even if you explicitly zeroed that char[].

If a threat actor has sufficient access to your system to inspect memory, make heapdumps, etc., you have bigger problems, and worrying about using a String vs char[] is just a waste of time, because that threat actor will have other means of finding your password, like finding configuration sources, modifying your program to record the password on a next run, etc.

To be clear, being able to quickly clear certain sensitive information can reduce the window of attack, but unless you're working in high-security environments, it is unlikely to be the right thing to focus on given all the caveats.