Eliminating Passwords from the JVM Heap

Question

There are various questions and answers about how to manage passwords in Java code - for example, here and here.

Discussions tend to focus on the merits of using char[] over String.

But are there any ways to avoid passwords being stored in the JVM's heap, if it's a 3rd party library that is storing the password in a String?

For example, in the following three cases I think passwords will remain in the heap for the lifetime of the JVM:

Hikari Connection Pool 3.4

EDIT - example updated to be more relevant to my question:

// some values read in from a properties file, or similar:
String url = ...;
String user = ...;
String pw = ... ;
...
HikariDataSource ds = new HikariDataSource();
ds.setJdbcUrl(url);
ds.setUsername(user);
ds.setPassword(pw);
...

In the above example, my com.zaxxer.hikari.HikariDataSource object contains the password in a String. I can't see a way to null the data source without losing the connection pool.

Jetty 9.4 Database Adaptor

For example, if I create a JDBCSessionDataStoreFactory, then the org.eclipse.jetty.server.session.DatabaseAdaptor holds on to the connection credentials, including the password in a String.

JNDI Connection in Tomcat 9

In this case the password can be found in org.apache.tomcat.util.descriptor.web.ContextResource and maybe also in org.apache.tomcat.dbcp.dbcp2.BasicDataSource, if I also choose to use that connection pool.

In other words, sensitive connection information can be found in various locations in my JVM's heap, regardless of how diligent I am about using char arrays in my code and overwriting/nulling sensitive data when it's no longer needed. I am not suggesting my efforts are wasted - I still want to protect what I can (for example a user's login credentials). But other credentials such as the database connection seem to be out of my control.

Are there any solutions or best practices for these cases?

Answer 1

Like @Holger said in the comments, anything that can read your heap memory and/or a heap dump in the filesystem, already has control of the server, so attempting to hide a password is useless at that point. Better to work on securing the actual server and services that live in it.

Thomas Porning gives a great answer in the link below, but this is the key paragraph (highlights mine):

None of this applies to a server application, or to client code that handles secrets with an actual non-negligible value. If a malicious attacker is in position to scan the RAM for sensitive data, and that data is worth 1 or 2 minutes of explicit attention from the human attacker, then no amount of overwriting will save you. Thus, in many contexts where security matters, overwriting of passwords and keys is just wasted effort, that gives a feeling of security, but does not actually improves things (though it may be convenient to awe auditors).

https://security.stackexchange.com/a/75891/4667