[security-dev] PicketLink IDM API - Should PasswordCredential use char[] instead of String

[Darran Lofthouse]

It is difficult to ensure that there are no other places that it is held 
in a String - HTTP headers, DB queries etc..

But from the perspective of the PasswordCredential I would think it 
should be 100% char[] based.

Regards,
Darran Lofthouse.

On 12/02/2012 11:34 PM, Shane Bryzak wrote:
> On 12/02/2012 01:23 AM, Darran Lofthouse wrote:
>> It is a fairly common recommended practice that passwords are stored
>> using character arrays instead of String - this means that as soon as it
>> is finished with the array can be cleared instead of relying on the
>> garbage collector to remote the String from the heap.
>>
>> Just thinking should PasswordCredential also do the same?
>
> Probably a smart idea - would you leave the constructor and
> getPassword() methods as is and just convert between the String and char
> array, like so:
>
> public class PasswordCredential implements Credential {
>       private char[] password;
>
>       public PasswordCredential(String password) {
>           this.password = password.toCharArray();
>       }
>
>       public String getPassword() {
>           return new String(password);
>       }
> }
>
> Or would that still be considered as a vulnerability?  I'm just thinking
> of the use cases where it's easier to bind a UI component directly to a
> String value.  We probably also need a Credential.clear() method also.
>
>
>
>>
>> Regards,
>> Darran Lofthouse.
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Darran Lofthouse - Principal Software Engineer

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)