On 05/03/2016 18:36, Mark Thomas wrote:
> On 05/03/2016 17:08, Christopher Schultz wrote:
> 
>>> First of all we could add the remote address valve and limit access to
>>> localhost by default. That will limit some remote attacks but possibly
>>> not all depending on reverse proxy configurations
>>
>> I was thinking about this as well. It would definitely make a stock
>> Tomcat more secure.
>>
>>> I'd also be in favour of hard-coding a check into the MemoryRealm and
>>> the MemoryUserDatabase that rejects [1] any of those three users if they
>>> have the default password and anything other than the roles defined in
>>> the comments.
>>
>> Why not ignore the roles and just refuse to use "tomcat" as passwords?
>> Then, of course, we'll have millions of servers running with "tomcat1"
>> as the password. :(
> 
> Indeed. Having thought about this some more, I'm going off this idea.
> 
> I still quite like my original idea which was:
> "Fire the idiot that did this."
> 
>> If we completely remove the "password" attribute, I believe the code
>> will currently reject all logins. That would force admins to make-up
>> their own, since there would be no default.
> 
> That is my reading of the code as well but we should double check that
> is what actually happens.

I started to work on this. If we remove the password attribute entirely
we'll need to add something to the file that explains how to add it
back. That probably needs an example which brings us right back to the
copy/paste problem.

I think I have a better idea. If we change it to something that will
break if simply uncommented then that solves the problem without making
it too much harder for inexperienced users. Something like:

password="<change-this-to-something-secure>"

Now they could just edit this to remove '<' and '>' but at that point
they really do deserve to be fired.

The comments above could also make clear that the passwords need to be
set if that block is uncommented.

WDYT?

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to