Well, that's what .Net did with SecureString, and OpenSSL did as well. There is a longer discussion here: http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-st ring-for-passwords that talks more about the pros and cons.
The main reason I bring it up is that, even though it doesn't provide *that much* extra security, providing some help at the API levels seems better than doing nothing ... It seems that, even though it provides only minimal security, it is *still* considered best practice to zero out password fields as soon as possible to minimize the potential security risks. So, seeing that VFS 2.0 is not quite released yet, it seemed like a good time to at least raise the question before the API is cast in stone. I'd be willing to take a crack at a patch to implement this change if there was enough interest. Thanks, ~Roger -----Original Message----- From: Honton, Charles [mailto:charles_hon...@intuit.com] Sent: Monday, July 08, 2013 3:53 PM To: Commons Developers List Subject: Re: [VFS] Passing around password as byte[] instead Or maybe a Password class that's tailor designed to obsfucate and zero contents... On 7/8/13 3:23 PM, "sebb" <seb...@gmail.com> wrote: >On 8 July 2013 23:05, Roger L. Whitcomb <roger.whitc...@actian.com> wrote: >> I had a thought that it would be more secure to pass password data >> around in VFS as byte arrays instead of String objects so they could >> less easily be found by memory dumpers/scanners. This would apply >> (for >> instance) to GenericFileName constructor and access methods, etc. >> Obviously, at some point, you have to convert to String (like in >> "GenericFileName.appendCredentials"), but it seems like at least some >> level of obfuscation, as in storing the data as bytes might be useful >> to increase security. > >Another reason for using bytes is that the array can be zeroed out - or >replaced with fake password to fool hackers ;-) - once it has been >used. >This is not possible with immutable strings. > >> >> >> Thoughts? Thanks. >> >> >> >> ~Roger Whitcomb >> >> Apache Pivot PMC Chair >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org