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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev(a)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)