On Fri, Aug 23, 2013 at 11:52 AM, Nick Williams <
[email protected]> wrote:
> 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();
> }
>
If we are going to eventually use it for other values (or files?), then we
can call it EncryptedChars or SecretChars.
The value could be a UTF-8 byte[] to make it easier to stuff file data in
there later if we want to...
>
> @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:
>
There will be at least ONE implementation for unit tests I hope!
>
> public interface PluggableDecryptionProvider {
> public char[] decrypt(char[]);
> }
>
> 3) Create a new configuration element <Decrypter
> implementation="foo.bar.PluggableDecryptionProviderImpl" />
>
3a) All elements could support a decryptionProvider attribute or just the
root Configuration element. A Decrypter element would be needed only if we
see more than one attribute needed, which might be safer for future
proofing... hm... OK, an element it is.
>
> 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?
>
You must mean all attribute values IN the config file. What about element
values?
Gary
> 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****
>>
>>
>
>
--
E-Mail: [email protected] | [email protected]
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
