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

Bill Burke bburke at redhat.com
Mon Dec 3 10:02:11 EST 2012


Dumbest reasoning I ever heard.  Swap file can be created at any time.

On 12/3/2012 9:53 AM, Anil Saldhana wrote:
> The best explanation that I have always found for the use of char[]
> instead of strings in password handling is at:
> http://www.h2database.com/html/advanced.html#passwords
>
> On 12/03/2012 03:33 AM, Darran Lofthouse wrote:
>> 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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the security-dev mailing list