Take a look at this thread:

http://www.dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/postid/42369/Default.aspx

/tpo

>This would allow for the unfortunately not uncommon scenario when the person with the host and/or admin >account password leaves (is fired or otherwise leaves on bad terms) and such knowledge transfer didn't occur. 

actually this is a problem in relation to auditing the DNN package for Company use. In its true form super user should be able to actually do any thing with the user/passwords etc. The super user would not be a commonly used login (as it is now) but an audit type login that would be highly secured by the Company. Thus there should be a Host login that has all the current powers except change its own password - or if it is allowed then super user would be allowed to reset passwords for admin and host. Thus you have three levels of security - super user that is purely an audit login, Host for the site administration and admin for the content administration. This would leave only one weak spot - the database userid and password in the web.config. In an inhouse programming team situation Host and Admin user ids would be required for testing etc but super user would not be.

In most cases discussions re security and hacks are related to attacks from the web not from inhouse - however in the case of a Company site bering hacked by staff especially if it has ecommerce there is very little security built into DNN.

The connect string in the web.config can or should be encrypted and in a number of Company installations it is but it is still quite breakable by any inhouse programmer working on the code.