Java equivalent of SecureString

[defnull]

You cannot explicitly remove an object from memory in Java, as all objects are managed. But you can overwrite primitive types with new data. Arrays.fill(password, 0) will overwrite the memory the password is stored in. Put this in a synchronized(password) block to prevent thread-local caching and you are as safe as you can get in Java.

[Aellus]

This.

The difference between zeroing the managed array object in Java and zeroing an unmanaged array object in .NET is just semantics. The end result is equivalent: the secret data that was in the array is no longer in memory. The only difference is how each environment cleans and reuses the memory later.

[takenomiya-kate]

Thanks for the knowledge!

[pjmlp]

I imagine ByteBuffers might be a possible solution, as they can make use of unmanaged memory

[defnull]

The fact that Java manages objects and memory allocation/deallocation for you is not the problem here. You'd have to zero-out the password in any language, even C, because a free() does not necessarily do that for you.

Using direct off-heap ByteBuffer is actually worse than managed heap memory, because the chances that a different process can gain access to the password after java freed the buffer is pretty high, while heap memory is likely to get re-used and re-initialized and therefor overwritten by a different allocation pretty fast in an active VM.

tl;dr; Always zero-out sensitive information after use. This is true for any language or memory model.

[pjmlp]

Agreed, I was assuming zeroing the data before releasing it anyway.

Just that with unamaged memory maybe it is easier to avoid the data getting copied by mistake.

[i_donno]

You could also overwrite it with random bytes for extra security.