[
https://issues.apache.org/jira/browse/LOG4J2-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131541#comment-16131541
]
Remko Popma commented on LOG4J2-1896:
-------------------------------------
So, essentially, the reconnect use case prevents us from zeroing out the char[]
array immediately after use...
What if we never take in a {{char[]}} in the first place? Instead we have some
object (an {{IPasswordProvider}} or something) that is responsible for giving
us the char[] on demand when we need it. Instead of storing the password we
keep a reference to this password provider. That way we can zero out the char[]
array immediately after login: there is no need to store the password char[] in
a field because we can alway ask the password provider again later.
Users currently need to specify a password in the configuration. If users could
specify a password provider instead that would also be better.
That does not completely solve the problem (still need a provider
implementation :-) ) but it centralizes it into one single place.
> Update classes in org.apache.logging.log4j.core.net.ssl in APIs from String
> to char[] for passwords
> ---------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-1896
> URL: https://issues.apache.org/jira/browse/LOG4J2-1896
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators
> Reporter: Gary Gregory
> Assignee: Gary Gregory
> Fix For: 2.9
>
>
> Update {{org.apache.logging.log4j.core.net.ssl.StoreConfiguration}} from a
> {{String}} to {{char[]}} to represent its password.
> The goal is to reduce the security risk of using a String for a password. See
> https://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
