Okay. I suppose I can cede your point.
So let's see if I understand our plans correctly here:
1) Create a Password type with the following interface:
public class Password {
private final char[] value;
public Password(char[] value);
public char[] getValue(); <-- this should clone the value
@Override public String toString();
}
@PluginAttributes of type Password will be written to any logs as ten asterisks
(**********) instead of their values.
2) Create an interface (say, PluggableDecryptionProvider or similar) with NO
implementations:
public interface PluggableDecryptionProvider {
public char[] decrypt(char[]);
}
3) Create a new configuration element <Decrypter
implementation="foo.bar.PluggableDecryptionProviderImpl" />
4) All @PluginAttributes starting with "enc:" (case-sensitive) get run through
the decrypter, if one is specified. Do we want to only support decryption of
Password @PluginAttributes?
Thoughts?
Nick
On Aug 23, 2013, at 10:33 AM, Ralph Goers wrote:
> And it isn't as easy as you make it sound. We won't be providing the code to
> do the encoding/decoding, just the interface. That would mean whoever is
> trying to gain access would have to find the class object and decompile it to
> get the information they would need. While that isn't hard it isn't trivial
> either.
>
> Whether we all agree it isn't necessarily as good I since I am quite sure it
> is a requirement in many organizations I am not in favor of simply telling
> them we won't do it. All that will do is encourage them to fork the code.
>
> Ralph
>
> On Aug 23, 2013, at 8:25 AM, Remko Popma wrote:
>
>> You're preaching to the choir... :-)
>> I'm not saying it's a smart rule, just that it is a rule. Bureaucracy,
>> sigh...
>>
>> From a security point of view it is not complete nonsense either. No system
>> is impenetrable, it is just a matter of how much time and effort the bad
>> guys are willing to spend... You could see this as an example of "layered
>> security" that (while not sufficient by itself) aims to increase the
>> cost/effort of penetration for the bad guys...
>>
>>
>> On Friday, August 23, 2013, Nick Williams wrote:
>> So y'all were forbidden to use Tomcat then? It's the most popular web
>> application server, and plaintext is your only option for passwords in
>> config files. For all the reasons I outlined, but mainly because putting
>> passwords that aren't plaintext in config files is merely a false sense of
>> security. Log4j is open source. Any mechanism we provide to encrypt/decrypt
>> passwords is easily found and manually applied to passwords that a hacker
>> retrieves from a config file.
>>
>> I'll repeat again: the problem is unauthorized access to the config file.
>> The symptom is access to the passwords. You have to treat the problem, not
>> the symptoms.
>>
>> Nick
>>
>> On Aug 22, 2013, at 11:23 PM, Remko Popma wrote:
>>
>>> My company doesn't allow plaintext passwords in config files either.
>>>
>>> On Friday, August 23, 2013, Ralph Goers wrote:
>>> I worked in an environment like Kurt's. passwords simply were not allowed
>>> in clear text in config files. I still think a plugin is the right way to
>>> handle that.
>>>
>>> Ralph
>>>
>>> On Aug 22, 2013, at 11:55 AM, Nick Williams <[email protected]>
>>> wrote:
>>>
>>>> This is what file permissions are for. The file should be protected so
>>>> that only those who are authorized may view it. For example, on a Linux
>>>> machine it may be 0400 where the user is the account that the application
>>>> runs under. Then only the application and root can view the file.
>>>>
>>>> N
>>>>
>>>> On Aug 22, 2013, at 1:32 PM, Kurt Lehrke wrote:
>>>>
>>>>> I believe there’s a small oversight in the idea that if someone has
>>>>> access to your box, that it’s game over.
>>>>>
>>>>> Think about a situation where a company may have a box with
>>>>> administrators and users. They may still want levels of security. For
>>>>> example, say you have a JDBCAppender that has a user name and password in
>>>>> their log4j2 configuration. The administrator may have access to their
>>>>> application and the database, but a user may only need access to the box.
>>>>> Therefore, having the user name and password hashed in the configuration
>>>>> file would ensure that a user (non admin) on the system can’t get to the
>>>>> database. This is an interesting challenge since the password hash
>>>>> would have to be a symmetric algorithm. It’s still merely only a light
>>>>> level of security since anyone with bad intent could still figure out the
>>>>> decryption by looking at the encryption algorithm.
>>>>>
>>>>> In my experience (supply chain development), some companies are pretty
>>>>> strict on having any password left in plain text, even if it is just for
>>>>> logging.
>>>>>
>>>>> Just a thought.
>>>>>
>>>>> Thanks,
>>>>> Kurt
>
