logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Williams <nicho...@nicholaswilliams.net>
Subject Re: Track passwords internally as char[] instead of String
Date Thu, 22 Aug 2013 18:24:12 GMT
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?

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
>>>>>>> JUnit in Action, Second Edition
>>>>>>> Spring Batch in Action
>>>>>>> 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
>>>>>> JUnit in Action, Second Edition
>>>>>> Spring Batch in Action
>>>>>> 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
>>>>>> JUnit in Action, Second Edition
>>>>>> Spring Batch in Action
>>>>>> 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
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> 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
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> 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
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> 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
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> 
> 


Mime
View raw message