Santronics Software, Inc.,
Web Authentication Summary

Introduction:

Wildcat! offers four methods for Web Login Authentication: 

To help customers quickly implement the new features, this sections will summarize the Web Login Authentication Methods, which to use and how to start using cookies:

Traditional Methods:

Traditionally, Wildcat! was designed as an intranet focusing on user authentication (login) requirements in order to use the secured features in Wildcat!  To log into the Wildcat! Web Server (wcWEB), it offered two methods:

These two methods is still supported and is enabled by default. 

HTTP BASIC Authentication:

The user can login directly into the web server using the internet HTTP standard method called "HTTP BASIC Authentication" where the user's browser, such as IE or FireFox, will pop up a login dialog box prompting for the user's login name and password. 

The browser must support HTTP BASIC (Today, practically all do) in order for the browser to display the box..  

On your public home page, you may offer one or more "/LOGIN" URLs:

/LOGIN?MODE=HTML User wants to use HTML clients
/LOGIN?MODE=CLIENT Users wants to use wcNavigator Clients.

In both cases, the browser will popup a login box and use HTTP BASIC authentication to login the user.

The difference is that MODE=HTML tells the web server to start the internal client WCX applications to display HTML pages for the different web clients (FILE, MESSAGE, PERSONAL, CHAT etc).

With MODE=CLIENT, this mode tells the web server to start the Wildcat! Navigator clients installed on the user's machine.  In this case, the user is basically using the web server as a "HTML Menu" to start the GUI Wildcat! Navigator clients.

It is important to note the browser will use BASIC authentication to login the user which is a Browser POPUP Login box.

WcNavigator Login auto start browser (Wildcat! Challenge)

With Wildcat! Challenge (a cookie based system), the user first logs into Wildcat! (not the web server) using the GUI Wildcat! Navigator application installed on his machine.  Wildcat! Navigator (wcNAV) is an optional free GUI frontend utility sysops can distribute to users.

After the wcNAV user logs into Wildcat!, he has the option to auto start the browser or click on the wcNAV "Browser" button to go directly to the private side default home page.   

This wcNAV does this by starting the browser and passing it a special /LOGIN URL with the current user's Wildcat! Challenge creditentials.  

/LOGIN?WCLOGON=<Wildcat! challenge>

The web server looked up this unique Wildcat! user challenge to automatically RE-LOGIN the user again under the web server context.  

The Wildcat! challenge is the user's unique encryption string for the current session, which in this case, begins with the WcNAV GUI session.  So this special URL will only work if the user is currently logged in under a different context.

It is important to note, this URL is for the wcNavigator to automatically start the browser under an authenticated session using a special cookie.  It does not use BASIC authentication.  The ability for wildcat! to already offer a cookie based login method using wcNavigator opened the door for a full browser based cookie based system which is now one of the new methods.

New Methods:

Two new Web Login Authentication methods were added in version 6.1.451.4 providing a total of four methods your users to log into the Wildcat! Web Server. The two new methods are:

Before describing these new methods, lets quickly explain why we might want to use these new methods.

HTTP BASIC Authentication has two problems:

    - Insecure Method passing ID/Password,
    - Can not logoff unless the browser is closed completely.

Using BASIC authentication is considered insecure since it uses a plain text encoding method called MD5 which can be decoded if a hacker was able to sniff the connection.  However, Wildcat! does offers SSL so if someone wanted to secured his web session, he would use SSL (if the sysop installed SSL).  Even with the new methods,  SSL remains the highest form of securing web sessions.

Using HTTP Digest Authentication offers a much greater secured form of HTTP BASIC Authentication.  DIGEST uses a secured encryption method called SHA1.  However, like BASIC, it is also a  browser login popup method to obtain the user's id and password.

The biggest issue with BASIC or DIGEST is that it does not offer an official method to log off the web server without closing the browser.  Although, the web server might time out the user, the browser remembers the login credentials and will automatically login the user the next time a page is displayed.  The only way to completely log off (discard the browser login credentials) is to close the browser.  

To solve the problem with logging off the web server, a cookie based method is now provided.   Using this method,  the Wildcat! Web Server uses a HTML login form along with JavaScripting to obtain the user's login id and password.  Using JavaScripting, the user's id and password are hashed and saved in a cookie and the browser issues one of the following special /LOGIN Urls:

/LOGIN?JS=1&MODE=HTML User wants to use HTML clients
/LOGIN?JS=1&MODE=CLIENT Users wants to use wcNavigator Clients.

These are the same as for BASIC or DIGEST authentication.  The difference is JS=1 which informs the web server, JavaScripting is involved.  However, as we will learn in the deciding which of the total four methods to use, the JS=1 is not 100% necessary.

Once logged in, the Web Server tells the browser to save a new cookie with encrypted session information.  Using the session cookie, the web server can now provide a "Logoff Button" offering the user the ability to completely log off the web server.  Once logged off, the user needs to log in again to begin a new web server session.

Deciding which Method to use:

In total, there are four total Web Login Authentication methods:

Choosing the method to use is primarily a decision based on the following:

The Web Server is prepared to operate in either Browser BASIC/DIGEST (Popup Window) mode or Cookie mode.  If you enabled all methods, the following order will be used:

wcNavigator users start the browser login with its special user so the only you option you have is to allow it or not.

But for the others, it really depends on the browser and which you offer to the user to login with.

As far as security is concern, from highest to lowest:

  1. Wildcat! Challenge Authentication
  2. Digest Authentication
  3. Cookie-Based Authentication
  4. Basic Authentication.

The Wildcat! Challenge is the most secured because it uses a proprietary hashing algorithm and trade secret, and it is a based on the existence of an already logged in Wildcat! Navigator user.  The hacker would need to be sniffing the Wildcat! Navigator GUI session.  While this is theoretically possible, using the WCLOGON=challenge string by it self would be insufficient to log into the web server.  There must be an existing user session present and there is no way a hacker can obtain the user's session credentials from the Wildcat! Server.

DIGEST uses a complex challenge key with SHA1 hashing concept that is considered highly secured.  Although, theoretically possible to hack, it would highly improbable within a given user session.  The hacker would have to  already exploited the user's machine (SpyWare) in which case, all bets are off anyway.    If you another BASIC authentication, you should also enabled DIGEST.

Cookie-Based Authentication is less secured than DIGEST but much better than BASIC which is the least secured method.

Although BASIC is considered the least secured, the malicious hacker would have to do a lot of work to sniff packets on the internet between your web server and the user.

In all cases, if security is a major concern, you should enforce SSL operations on your web site.

How to start using Cookies:

The biggest change in the Web Server is allowing cookie-based authentication which requires JavaScripting and cookie support.

Unzip the following files from WCWEBAUTH.ZIP as described in Requirements and Setup.   The WCWEBAUTH.ZIP file is distributed via the AUP.  CD installations will automatically make it available.

Technically, you do not need to modify your current HTML pages in order to immediately begin using cookie authentication.  To use cookies without modifying your HTML pages, simply turn off BASIC and DIGEST authentication and turn on Cookie authenication.  See Web Server Authentication Configuration.

If you want to include a Login ID and Password form on your public home page, do the following:

  1. Rename public\default.htm to public\default.wct
  2. Add the following to public\default.wct

        @ExistInclude wc:\http\public\login.wct@

You should remove the /login?mode=???? URLs in the page and replace it with the above line.

This is all that needs to be done to get started.  Of course, you may customize your login.wct and/or the UserNotLoggedIn.wct html templates.  If you do customize login.wct, it is recommended that you use a different file name so that future login.wct do not overwrite your customized version.

Finally, you may offer cookie and BASIC/DIGEST support on your system. In this case, keep in mind the browser will use BASIC/DIGEST if the user bypasses your login home page using a direct URL to a secured page.