How can I ensure the destruction of a String object in Java?

An empoyee at my company needs to modify data from a SQL Server database through a program I made. The program used Windows authentication at first, and I asked the DBAs to give this specific user write access to said database.

They were not willing to do this, and instead gave write access to my Windows user account.

Since I trust the guy but not enough to let him work 90 minutes with my session open, I'll just add a login prompt to my program, asking for a username and password combination, and log in to SQL Server with it. I'll log in, and trust my application to let him do only what he needs to.

This, however, raises a small security risk. The password fields tutorial over SunOracle's site states that passwords should be kept the minimum amount of time required in memory, and to this end, the getPassword method returns a char[] array that you can zero once you're done with it.

However, Java's DriverManager class only accepts String objects as passwords, so I won't be able to dispose of the password as soon as I'm done with it. And since my application is incidentally pretty low on allocations and memory requirements, who knows how long it'll survive in memory? The program will run for a rather long time, as stated above.

Of course, I can't control whatever the SQL Server JDBC classes do with my password, but I hoped I could control what I do with my password.

Is there a surefire way to destroy/zero out a String object with Java? I know both are kind of against the language (object destruction is non-deterministic, and String objects are immutable), and System.gc() is kind of unpredictable too, but still; any idea?

Solution 1:

So, here's the bad news. i'm surprised no one has mentioned it yet. with modern garbage collectors, even the whole char[] concept is broken. regardless of whether you use a String or a char[], the data can end up living in memory for who-knows-how-long. why is that? because modern jvms use generational garbage collectors which, in short, copy objects all over the place. so, even if you use a char[], the actual memory it uses could get copied to various locations in the heap, leaving copies of the password everywhere it goes (and no performant gc is going to zero out old memory). so, when you zero out the instance you have at the end, you are only zeroing out the latest version in memory.

long story, short, there's no bulletproof way to handle it. you pretty much have to trust the person.

Solution 2:

I can only think of a solution using reflection. You can use reflection to invoke the private constructor that uses a shared character array:

  char[] chars = {'a', 'b', 'c'};
  Constructor<String> con = String.class.getDeclaredConstructor(int.class, int.class, char[].class);
  con.setAccessible(true);
  String password = con.newInstance(0, chars.length, chars);
  System.out.println(password);

  //erase it
  Arrays.fill(chars, '\0');
  System.out.println(password);

Edit

For anyone thinking this is a failproof or even useful precaution, I encourage you to read jtahlborn's answer for at least one caveat.

Solution 3:

if you absolutely must, keep a WeakReference to the string, and keep gobbling memory until you force garbage collection of the string which you can detect by testing if the weakreference has become null. this may still leave the bytes in the process address space. may be a couple more churns of the garbage collector would give you comfort? so after your original string weakreference got nulled, create another weakreference and churn until it is zeroed which would imply a full garbage collection cycle was done.

somehow, i have to add LOL to this even though my answer above is entirely serious :)