I was asked to convert String password to character password in my org
because of security issues and same immutable property of string was the
reason for it.


On Tue, Jul 9, 2013 at 11:09 PM, Roger L. Whitcomb <
[email protected]> wrote:

> Yes, 2.1 was what I meant...
>
> ~Roger Whitcomb
>
> -----Original Message-----
> From: Gary Gregory [mailto:[email protected]]
> Sent: Monday, July 08, 2013 5:52 PM
> To: Commons Developers List
> Subject: Re: [VFS] Passing around password as byte[] instead
>
> On Mon, Jul 8, 2013 at 7:05 PM, Roger L. Whitcomb <
> [email protected]
> > wrote:
>
> > 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.
> >
>
> 2.0 has been out for a long time. 2.1 is ready for a release IMO.
>
> Gary
>
>
> >
> > 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:[email protected]]
> > 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" <[email protected]> wrote:
> >
> > >On 8 July 2013 23:05, Roger L. Whitcomb <[email protected]>
> > 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: [email protected]
> > >For additional commands, e-mail: [email protected]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
>
> --
> E-Mail: [email protected] | [email protected] Java Persistence
> with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>



-- 
Anshul Zunke

Reply via email to