I know it may be picky, but even if the check is only for authenticated users it is a wasted check if we are not running with defaults and some of us may feel that our passwords are strong enough to even keep usernames like "admin" and "host". 

This may not be a huge impact, but all these little ones add up and it is very easy to remove for people who have had the warning and no longer need the code checking for this on every single request.

I think a security measure like this is much better served without resorting to code.  Creating a blog post and linking to it from the next newsletter should be sufficient.  But it is a subjective topic, so I can offer some other ways to do it in code that would be less impact.

First, the declaration of the message string is done outside of the check where it is used, so that string allocation is always performed even if it is not needed.

Second,  there is already a place in the code that checks if the user is authenticated on every request - OnAuthenticateRequest of the membership module.

Third, and the best I can think of right now if it has to be done in code is to move it to the control panel, which already has logic to only show for the people that are being targeted with the message.

Ok, it looks like we are now in the Chat About It forum, so we can discuss this a little further.

I see where the querystring variable does not get added unless there is a username/password combination on the defaults so you can use admin or host as a  username as long as you don't use the default password.

My problem with this approach is that even after the message has been delivered and the problem rectified, the code still has to keep checking on every login for the username/password combination and then on every request to see if it should display the message.

Here is a better way, that will even help deliver these kinds of messages in the future. 

Create a simple message module.  Then on upgrades do the check for whatever the administrator needs to be notified of, and if they need the message delivered inject a message module instance into their home page and make it only visible to who needs to see it.  If the check can not be done during the upgrade, the process could also take place on application start using the EventQueue.

This way, once the problem is rectified they will be able to easily remove the message module, and not suffer a performance hit.

I also think these types of messages should still have a security bulletin created and advertised to people who may not be doing the upgrade.  Afterall, if it is worthy of adding code, it certainly must be worthy of notifying other people that may not ever see that code executed.
In the case of the hoster that requested this check, they should also be notifying their customers through e-mail, etc.

The only way the message can be turned off right now is by removing the lines in the first post of this thread.