I would be okay with this solution.

N

On Aug 22, 2013, at 1:32 PM, Gary Gregory wrote:

> On Thu, Aug 22, 2013 at 2:24 PM, Nick Williams 
> <[email protected]> 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 
>>>> <[email protected]> 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 
>>>>> <[email protected]> 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 <[email protected]> 
>>>>>> wrote:
>>>>>> On Mon, Aug 19, 2013 at 10:34 AM, Ralph Goers <[email protected]> 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 <[email protected]> wrote:
>>>>>> 
>>>>>>> On Mon, Aug 19, 2013 at 10:25 AM, Paul Benedict <[email protected]> 
>>>>>>> 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 <[email protected]> 
>>>>>>> wrote:
>>>>>>> On Mon, Aug 19, 2013 at 7:27 AM, Ralph Goers <[email protected]> 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 <[email protected]> 
>>>>>>> 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: [email protected] | [email protected] 
>>>>>>>> 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: [email protected] | [email protected] 
>>>>>>> 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: [email protected] | [email protected] 
>>>>>>> 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: [email protected] | [email protected] 
>>>>>> 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: [email protected] | [email protected] 
>>>>>> 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: [email protected] | [email protected] 
>>>>> 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: [email protected] | [email protected] 
>>>> 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: [email protected] | [email protected] 
> 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

Reply via email to