On Aug 23, 2013, at 1:30 PM, Gary Gregory wrote: > 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>
Of course. > 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. Exactly. It's the consumer's responsibility to ensure their config files consist only of valid markup. > 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 >> 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
