I see things considerably different, IIS came before DNN; DNN was built out of ASP.NET and intended to run on IIS; DNN *could* be designed in such a way that it could use multiple websites but the decision was made not to do so.  It would seem like if the application shared components of DotNetNuke.DLL were put into a different DLL that exposed its functions as shared (static) capabilities; that the issue of having multiple instances of the DotNetNuke.dll per website would not matter, because multiple running compies of the code in that dll would call the same in-memory functions and not cause a performance hit.

I am hoping that this thread will draw the attention of the Core team to begin a discussion about what can be done to overcome this weakness.  As is, the architecture and design of DotNetNuke actually encourages sites to put up insecured ecommerce systems that are sending credit card and other confidential information over the internet in clear text.  Many unknowning end users may not understand that - assuming that any platform released in this day in age would automatically be securing such information.

If there is a discussion about this elsewhere; or if I could communicate with a core team member about how I might be able to contribute to getting on the right path regaurding this issue; I would like to be made aware of the discussion or contacted by somebody about what I can do to help.  As is, it seems I will need to come up with some kind of solution for myself; and this seems critical enough that it should be a concern of many.  The idea that host passwords are being submitted as unsecured postbacks would worry everyone out there.  Consider that many DotNetNuke sites are hosted on shared servers - and rouge code executed on another site in that server could easily gain access to the unencrypted data coming in and out of that server.

Again, perhaps my understanding of the system just falls short; if this is the case, please somebody shed some light on this subject for me.

Thanks for the posts that have been already made.

No, I'm saying that the problem is that all DotNetNuke installation articles and best practices discussed around the community are that a single installation and IIS website can provide the capability to support multiple portals, and that using this style if implementation is missleading in that it is not possible to provide SSL Security for more than one portal using this architecture.

It has been Identified in this thread that the only possible way to provide SSL Security for multiple portals in the same DNN application is actually to create multiple IIS websites that point to the same root DNN folder; but that this approach is not well tested (I had never even heard or thought of the approach before this thread) and that performance implications come along with it - in that now it's not really one application that is executing, but multiple - just to support SSL on more than one portal.

If we could overcome the performance issues by changing the architecture around a bit, this may remove the performance implication and then I feel that this way of hosting (one IIS configured website PER portal) is what should be used as a best practice because it is in fact the only way to provide ecrypted capabilities to more than one portal in a single DNN application; and that the general populous may overlook this if it is not address better in installation articles and how-tos.

If this is the case then you must only have SSL on your login for a single portal, is this correct?  I'm just making sure we're in the same page.

Using encrypted passwords and not hashed passwords still means that clear text passwords are not passed between the db server and the app.  DNN currently successfully does not send clear text passwords between the web server and the db server.  I would agree with you that perhaps the DEFAULT implementation should use hashed passwords instead of encrypted passwords, as hashed passwords are stronger in that they are not reversible;  One of the first things I do on all of my installations is to change the authorization provider settings to HASHED instead of ENCRYPTED.