Hi Iadalang,

Implementing a custom authentication system that is fully secure, in my opinion, is a task of greater difficulty than adding a new DNN authentication mode.  So if you're having great difficulty with the latter, then the former might not be a good idea.  If you decide to press ahead anyway, you'll need to copy the files in the directory I mentioned in my previous post, add the new mode (I believe under Host/Authentication, although I've always just made the entry directly in the database), and modify the files (login.ascx and login.ascx.vb mostly) to deal with the technical requirements (hashing, challenge tokens, etc).  As always, the devil is in the details.

SSL is not mandatory for ANY authentication setup.  It is merely a broadly accepted and robust solution to transport-level secure communications.  Roll-your-own password transmission will always be less than or equally secure to it, and will virtually always be the former.  Lots of very smart people have looked very hard at TLS/SSL, and chances are that it will stand up well to any ad-hoc pasted-script custom scheme.  For example, a challenge-token setup might prevent evesdropping, but does not address server identify verification.  For this, you might implement some form of PKI and a trust authority of some sort.  By the time you've dealt with all of these issues, you will have essentially implemented SSL all over again.

A custom authentication setup is, however, a great way to learn about internet security!

Not all DNN sites authenticate using SSL.  Those that do not are vulnerable to eavesdropping attacks.

Have you considered using the LiveID provider?  Or Active Directory?

Brandon

Hi Iadalang,

Although you're free to try and get any new feature implemented into the core, I suspect that it is exceedingly unlikely that such a feature would be incorporated.  To my knowledge, you are the only one who has ever desired such an option.  However, I in no way speak for the core team, do don't let me dissuade you!

Although I have developed custom authentication modules for DNN, I have not attempted to replicate SSL/TLS in the framework.  Those are the details to which I referred -- and the challenge in implementing them rest with you!

It is up to each webmaster to evaluate the risk of an eavesdropping attack against the cost of penetration.  I'd tend to agree with you that DNN should come with a warning against plaintext transmission of passwords.

Based upon your other thread where you indicate that there will only be two accounts on the system (1 admin and 1 host), you will almost certainly want to self-SSL (assuming you're running on your own server).  You could have generated, installed, and added root-trust to the certificate in less time than it took us to have this conversation.  If you do not control your own server, stick with LiveId (or see if your hosting company provides a shared certificate).

Although I have little direct development experience with the LiveId provider, I'll respond to your concerns in that thread.

Brandon

Hi Iadalang,

I have successfully used SelfSSL (with MS Commerce Server) on an XP dev machine with IIS5.1, so I know it will work there.  No hosting company will be running under XP, and I would be surprised to find one still using w2k (although I'm sure they exist).  Regardless, SelfSSL just generates a certificate, and this certificate should be usable in pretty much any version of IIS.  You'll have to deal with root trust issues on client computers (on a per-computer basis), but since you will only be having two accounts, this may or may not be a problem. 

Many hosting providers offer free shared SSL.  Have you considered this option?  You can read more from Alec here: http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/1501/Default.aspx

My custom authentication experience with DNN is mostly related to authentication coordination between DNN and a legacy system not running under .NET forms authentication.  Although I cannot release much in the way of details, if you look through some of my previous posts I do discuss it peripherally in the context of implementing a custom membership provider. 

Brandon