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
