4

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?

trincot
  • 317,000
  • 35
  • 244
  • 286
andrewJames
  • 19,570
  • 8
  • 19
  • 51
  • In the case that you show, you still need the secret available--you may need to open more connections for capacity, if they time out, you have a server failover, etc. – chrylis -cautiouslyoptimistic- Dec 31 '19 at 23:09
  • 1
    When you have a line like `ds.setPassword("51mp50n");`, you don’t need to worry about what the `HikariDataSource` object does, you already have a string instance representing the string literal permanently linked to this code location. It will persist as long as the code (resp. its class loader) exists, in case of the application class loader, the entire lifetime of the JVM. Even if you managed to wipe out that string instance somehow, the character data of this password is stored in the class file and hence, loaded into the process’ memory, independently of the heap memory. – Holger Jan 06 '20 at 16:59
  • @Holger - yes - indeed - a String literal password in the source code! I have changed the Hikari example to be (hopefully) more relevant to my question. – andrewJames Jan 06 '20 at 21:24
  • 3
    Well, someone who can read your heap memory surely can read the property file as well (or the buffer memory used when reading the file). It all boils down to the need to protect the machine your code is running on, rather than spending lots of efforts in trying to make finding the data marginally harder. – Holger Jan 07 '20 at 08:14

1 Answers1

2

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

mjuarez
  • 16,372
  • 11
  • 56
  • 73
  • Thank you for the reference. As you, Holger, and several others have said in answers, elsewhere, on this broader topic, we need to prioritize what matters. There is little (or maybe even _negative_) value in adding one more lock to your front door, if the back door is hanging off its hinges. – andrewJames Jan 09 '20 at 16:05