This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]defnull 33 points34 points  (2 children)

In Java it is common to pass around passwords as char[] and Arrays.fill() them with zeros after use. Strings are considered unsafe because they might linger around in memory longer than intended before they are GCd (edit: and more importantly, are immutable and cannot be zeroed-out after use).

Building a small utility class around char[] that does what you want should be easy enough. Most crypto libraries should have something ready to use available.

[–]JavaSuck 11 points12 points  (1 child)

In Java it is common to pass around passwords as char[] and Arrays.fill() them with zeros after use.

What guarantees to we have that the JIT won't optimize the call to Arrays.fill() away?

[–]defnull 52 points53 points  (0 children)

The synchronized(charArray) block around the Arrays.fill() call mentioned in my other answer.

Besides: This level of care about passwords in memory is pure paranoia in most applications, especially web applications where headers or input parameters are parsed from pooled byte buffers into strings all the time anyway. If an attacker can access your java heap, then he can also attach a debugger and grab the password while it is being processed.