logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Track passwords internally as char[] instead of String
Date Thu, 22 Aug 2013 18:32:58 GMT
On Thu, Aug 22, 2013 at 2:24 PM, Nick Williams <
nicholas@nicholaswilliams.net> wrote:

> Ahhh. Okay, I see where the disconnect was, now.
>
> I think our best bet is a "boolean password() default false;" attribute on
> the @PluginAttribute annotation. This idea was mentioned earlier by someone
> else (I've lost track of who). The configuration processor should then log
> ten asterisks (**********) in place of the value for that attribute if it's
> given a value, or null/blank as it usually would if it's not given a value.
>
> I think this is going to be more effective than using char[] instead of
> String, IMO.
>
> Thoughts?
>

If we are going to do that, we might as well create a Password class that
wraps a char[] (or a UTF-8 byte[]) and toString()s itself as "**********".

Then you call a getValue() on the Password when it is time to use it.

Gary



>
> On Aug 22, 2013, at 12:26 PM, Ralph Goers wrote:
>
> A password that is in the xml configuration will be logged to the status
> logger. It formats the arguments to the methods.  You would need to
> annotate the attribute with something to get it to mask the value.
>
> Ralph
>
> On Aug 22, 2013, at 9:58 AM, Nick Williams wrote:
>
> I think a more accurate statement is "regardless of how passwords are
> stored (char[], String, etc.), it's a Log4j design issue to ensure that
> they are never logged under any circumstances." I think it's more important
> to be cognizant of what you're doing with passwords and make sure they
> aren't exposed, no matter how they're represented.
>
> Nick
>
> On Aug 22, 2013, at 11:49 AM, Gary Gregory wrote:
>
> On Thu, Aug 22, 2013 at 12:17 PM, Nick Williams <
> nicholas@nicholaswilliams.net> wrote:
>
>> I believe it's sufficient to simply *make sure* our code doesn't let
>> these passwords from the configuration get into logs. I don't see it as
>> necessary to add special password support, IMO. But I could be missing
>> something.
>>
>
> It's something that is easy enough to do (String <-> char[]) so I want to
> make sure that if we leave it as is, we're all OK saying "passwords are in
> plain Strings and it's not a Log4j design issue"
>
> Gary
>
>
>> N
>>
>> On Aug 22, 2013, at 6:28 AM, Gary Gregory wrote:
>>
>> On Mon, Aug 19, 2013 at 12:38 PM, Nick Williams <
>> nicholas@nicholaswilliams.net> wrote:
>>
>>> This discussion comes up on the Tomcat mailing list at least every few
>>> months, and it always ends the same way.
>>>
>>> The passwords are in a configuration file. That configuration file lives
>>> with the application. So, for example, if the application is a web app the
>>> configuration file lives on the web app server or a server it has access
>>> to. Either way, if a hacker gets a hold of that configuration file, it's
>>> because they've breached your firewall/server protection systems and it's
>>> game over anyway.
>>>
>>> There's really no use in making efforts to protect passwords in these
>>> configuration files. Any effort to do so just adds a _false_ sense of
>>> security, which is more dangerous than no security at all.
>>>
>>
>> My concern is more in the other direction. When secrets are in String
>> objects, they end up as plain text in log files or any kind of dump (if
>> Strings are dumped with toString()). At work, we get different kinds of
>> logs from users where the user has painstakingly blanked out certain data.
>> Using char[] avoids saying giving in plain text your secrets when they are
>> in Strings. In the case of Log4j2, this may never happen as the code stands
>> now (do we have passwords in toString()s?)...
>>
>> Gary
>>
>>
>>> Nick
>>>
>>> On Aug 19, 2013, at 9:54 AM, Gary Gregory wrote:
>>>
>>> On Mon, Aug 19, 2013 at 10:52 AM, Gary Gregory <garydgregory@gmail.com>wrote:
>>>
>>>> On Mon, Aug 19, 2013 at 10:34 AM, Ralph Goers <rgoers@apache.org>wrote:
>>>>
>>>>> I'm not sure how this applies to what you are suggesting, but we
>>>>> should avoid passwords being in clear text in the configuration.  I would
>>>>> suggest using a standard plugin interface similar to what I did with
the
>>>>> secret key provider in the Flume Appender.
>>>>>
>>>>
>>>> We should at the last offer something like
>>>> http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords
>>>>
>>>
>>> So perhaps we need a boolean password attribute on PluginElement and
>>> PluginAttribute
>>>
>>> Gary
>>>
>>>
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Aug 19, 2013, at 7:29 AM, Gary Gregory <garydgregory@gmail.com>
>>>>> wrote:
>>>>>
>>>>> On Mon, Aug 19, 2013 at 10:25 AM, Paul Benedict <pbenedict@apache.org>wrote:
>>>>>
>>>>>> Do you need the password ever after authentication?
>>>>>>
>>>>>
>>>>> I guess it depends on whether the code handles re-auth in case of a
>>>>> disconnect.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>>
>>>>>> On Mon, Aug 19, 2013 at 8:55 AM, Gary Gregory <garydgregory@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> On Mon, Aug 19, 2013 at 7:27 AM, Ralph Goers <rgoers@apache.org>wrote:
>>>>>>>
>>>>>>>> What passwords?
>>>>>>>>
>>>>>>>
>>>>>>> For example:
>>>>>>>
>>>>>>> - org.apache.logging.log4j.core.net.SMTPManager.FactoryData.password
>>>>>>> - org.apache.logging.log4j.core.net.JMSTopicManager.password
>>>>>>> -
>>>>>>> org.apache.logging.log4j.core.net.JMSQueueManager.FactoryData.password
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Aug 19, 2013, at 4:22 AM, Gary Gregory <garydgregory@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I've seen it done many places: Should we track passwords
internally
>>>>>>>> as char[] instead of String for ivars.
>>>>>>>>
>>>>>>>> This prevents Log4j spilling your secrets by accident in
a toString
>>>>>>>> to internal log call.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Paul
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> 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
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
>
>
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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

Mime
View raw message