On Fri, Aug 23, 2013 at 2:16 PM, Nick Williams < [email protected]> wrote:
> > On Aug 23, 2013, at 11:22 AM, Gary Gregory wrote: > > 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. > > > Let's not go down the rabbit hole. I've seen no use case for encrypted > files so far, nor any example where a non-string parameter would be > encrypted. Of course, I'm okay with steering clear of the word "Password" > with something more generic like EncryptedString or SecretString with the > same signature as the Password I proposed above. I don't like > abbreviations, so I'd steer away from Chars. And Characters is getting in > the long arena. > > The value could be a UTF-8 byte[] to make it easier to stuff file data in > there later if we want to… > > > Again, rabbit hole. If you used byte[], code needing a String would need > just one conversion (new String(bytes)). But code needing a char[] (like > MongoDB) would need TWO conversions (new String(bytes).toCharArray()). I > would stick with char[] for now, and add a different class to support > byte[] in the future IF we decide we need it. > > >> @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! > > > Well, duh! :-P > > >> 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? > > > Yes, I meant in the config file. From what I've seen, the only time an > element has a value is when it's actually a @PluginAttribute. For example, > the JDBCAppender connection provider could be: > > <DriverManager user="user" password="password" /> > > or > > <DriverManager> > <User>user</User> > <Password>password</Password> > </DriverManager. > You must mean: <DriverManager user="enc:encrypted" password="enc:encrypted" /> or <DriverManager> <User>enc:encrypted</User> <Password>enc:encrypted</Password> </DriverManager. Rabbit hole: What if the encrypted has XML markup or illegal XML chars, then the value must be in an XML PCDATA. That'll be up to the author of the config file to fiddle with. Gary > > > 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 > > > -- 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
