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****
>
>

Reply via email to