commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <>
Subject AW: [FTP and FTPS] using char[] password instead of String
Date Wed, 05 Nov 2014 18:49:04 GMT

i am hated at work to introduce char[] parameters for passwords, and after having a few years
of experience with it I can say they are hardly worth it: Most often the caller has strings
to work with anyway and need to copy them to char Array or the called Code Works with strings,
or it is hard for the caller and callee to agree when to zero the Content. And if You Look
closely with all generational collectors a string object typically survives not even the first
eden copy (typically seconds).

having Said that, it might be good to consider CharSequence in future APIs.



----- Ursprüngliche Nachricht -----
Von: "Nicholas Castorina" <>
Gesendet: ‎05.‎11.‎2014 19:01
An: "" <>
Betreff: [FTP and FTPS] using char[] password instead of String

Is there a way to use the FTPSClient.login(username, password) where password is a char[]
instead of a String?  Strings are immutable and don't get removed from memory until garbage
collection.  That means that the password can possibly be recovered from a memory dump.  However,
if password was a char[], I could do Arrays.fill(password, ' ') and there would be no traces
of the password in memory once I was done with using it.

For a more detailed explanation of this, you can go to

I didn't see an option for a char[] instead of String for password, but I could have missed
one.  If there is not currently a way to use a char[], you could also probably get away with
changing the password from type String to CharSequence (the interface that String implements).
 That way FTPSClient is backwards compatible and you can clear passwords after use by using
a CharBuffer (also implements CharSequence) instead of a String.

Nicholas Castorina

This message and the information contained herein is proprietary and confidential and subject
to the Amdocs policy statement,
you may review at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message