WanderWare Product Summary
The rapid adoption by organisations of WWW services as a channel to reach wider audiences and as a tool to conduct business has led to security challenges which were not anticipated in the original research orientation of such services. In particular, it was not foreseen that it would necessary to restrict access from the public at large.
At the point that a business begins to use a WWW service to publish materials that are to be restricted from general public access it needs to implement security measures to ensure that the material is accessible only to those sanctioned by the organisation as authorised users. These users may include the specific segments of the public in general, such as subscription membership sites, or may be restricted to internal groups such as employee portals for workforces deployed in the field.
In these situations, WanderWare offers sites the benefits of content protection and bandwidth protection from the effects of hot-linking, autobots, robots, searchbots, password sharing, autodownloaders, password crackers and password hurlers
The standard means of access is the client browser. All current browsers support a security mechanism based upon prompting for the user for an account name and password. It is also common to see custom login pages that implement the same account name and password challenges.
It is important to note that this account name and password combination accomplishes not one, but two tasks when properly implemented. The first is user authentication, the user is presumed by having knowledge of the password that he is the claimed account holder. The second, user authorization, is a side effect of the first. With knowledge of the identity of the user, it can also be established what privileges are available to the user in a one to one mapping.
However, the HTTP(hypertext transfer protocol) used for WWW services is stateless. This means that each page viewed by a user is independent from any other. The server has no knowledge of a sequence of actions from a user as being part of a whole. It is left up to site designers to implement any session state association on top of the WWW service and it's HTTP protocol.
WanderWare directly addresses the user authentication and user authorization requirements of membership based sites. Authentication identifies the user to the system and authorization defines the privileges granted to that particular user on the system.
The system design is efficient, high performance, highly scalable and non-intrusive to developers and users. This permits site owners to successfully deploy strong defensive regimes which are still highly acceptable to users without requiring the use of advanced programming techniques.
More particularly, the only effect visible to users is that they are prompted for a username and password. For developers, their only responsibility is to place protected materials within defined protected zones. Should they need to access the user name or user rights information, it is simply accessed as information that is passed to them by the filter. Other than this, developers can treat the unprotected and protected areas identically.
The advantage of a component based security architecture is that it insulates the user and developer communities from the complexities of implementing a strong security system. This does not mean that the system compromises security for usability. On the contrary, it means that a great deal of effort and testing has been invested to create a reliable solution that others can use without the same expenditure in time and money.
For sites which are subject to rigorous third party audit, the designers have been especially careful to respect and employ standards and practices which have been thoroughly examined by the security community.
By definition, a web site that is successful in attracting traffic offers content that is attractive and thus, of some value to the targeted user. If the site is freely accessible to the public at large, there are usually no problems.
However, if site access is restricted, there will always be those who try to gain access to the protected materials without proper authorization. A prime example is paid subscription sites. While value and cost can both be denominated in currency, there are always those who will want the value without the cost. What this really says is that the more successful a membership site is, the greater the attraction to those who want the content without paying. This is the domain of hotlinkers, password hackers and password traders.
Password hackers will use automated systems that try multiple combinations of usernames and passwords in search of a valid pair that will give them access. Password traders simply share accounts amongst a wide group.
To date efforts have been concentrated primarily on repelling the efforts of password hackers. A common response is to deactivate the account permanently and immediately. Another response is to deny access from entire portions of the global network once it is discovered that unauthorised access attempts have originated from that portion. This often leads to inadvertent denial of service to the legitimate user, who will usually need to be dealt with by customer service.
Security practitioners have argued that the next step is to consider defense as a process. A defensive regime, if you will. When viewed as a process, the appropriate defensive mechanisms and responses are most properly business decisions as differentiated from purely technical decisions. The needs of the business as a whole supercede any single technical parameter.
The business policies of the site determine the appropriate response to both correct and incorrect usage of user accounts in the context of the impact to the business. The policies also extend to such related matters as usability features that may be imposed by any particular tool. For example, it may be decided that certain tools are not suitable for a particular site because they are too intrusive. The guiding principle is simply that security policies and mechanisms should be selected to protect and enhance the value of the business both in the near term and beyond.
By embracing the concept of defense as a process, the site opens itself to not only how it is to be defended but also to how the defensive regime can enhance the success of the site.
The feature set of the isapi authentication filter based system described below goes well beyond current offerings. Its design has been guided by the best features of offerings on both private and public networks. A number of features have not yet been available on web servers, but have been well tested and understood concepts on private corporate networks.
The completeness of the feature set and the scalability of the architecture creates an opportunity for site owners to implement defensive regimes that fully support their business goals.
Isapi Authentication Filter
The basis of WanderWare is an isapi authentication filter targeted to the creation of secure member areas on iis web servers. It meets the needs of sites that require the protection of pages, image files, and other files through user password protected mechanisms. Membership or paid subscription based sites running iis needing to prevent hot-linking of images and content will find this highly secure authentication isapi filter of special interest. Sites concerned about content protection and bandwidth protection from the effects of hot-linking, autobots, robots, searchbots, password sharing, autodownloaders, password crackers and password hurlers will find this to be an effective prevention mechanism.
At this time, this is the only available isapi authentication filter for IIS that combines basic authentication, digest authentication, an extensible data store, in memory caching enhancements and anti-abuse defense capabilities in a single isapi authentication filter.
Active Directory Independence
The native digest authentication mechanism as shipped with IIS requires that the IIS server be a member server in an active directory domain to have digest authentication enabled as an option. Implementing and maintaining active directory is a complex undertaking. Additionally, it can be a security risk if proper precautions are not observed. This is in addition to the requirement to store the passwords using reversible encryption. Finally, accessing the active directory data store from a web application can be problematic.
The secure isapi authentication filter described here is an alternative means of achieving digest authentication in a manner which is totally independent of active directory. It also adds defensive capabilities which are not offered in the native implementation.
Its permanent user data store is based on standard sql databases which are easily accessed and modified by web applications. The permanent data store is easily accessed, modified and extended by using standard sql programming techniques.
It has been noted by industry analysts that the use of third party authentication software relieves a licensee from the obligation to purchase additional client access licenses for use by authenticated clients on IIS servers. For some sites, this translates to major cost savings while remaining fully compliant with licensing obligations.
Basic and Digest Authentication Interoperability
Since the isapi authentication filter accepts both basic and digest authentication methods it satisfies the needs of users with older browsers and users who want the security of advanced encryption based authentication methods.
Irrespective of the authentication method employed, user information is stored in a common user information store implemented on a standard sql database. Additionally, performance is optimised and database load minimised by using an intermediate caching in memory resident database. Between reboots, the in memory database is populated from the permanent user database on demand as users login.
Enterprise versions of the Wanderware isapi authentication filter are architected to be highly scalable. These versions allow client requests to be spread amongst clusters or arrays of web servers independently.
Session independence is guaranteed at the level of the isapi authentication filter. It is not necessary to force returning user sessions back to a specific server or connection.
If a custom application also uses the user identification features of the isapi authentication filter, it can also be written to be completely server independent.
Protection of Builtin Accounts
Independent of the account lockout capabilities built into the isapi authentication filter, the split between the operating system sam user database and the client user database prevents the brute forcing of builtin account passwords.
This is important because by default, the builtin administrator account cannot be disabled. If any of the native iis authentication schemes are used it is possible to mount a brute force attack against a server running IIS for an unlimited duration as long as the server remains operational. During this time the server cannot be prevented from answering with a success/failure status for each password attempted.
In addition to the risk of compromising such a powerful account, the cost of the bandwidth consumed in such an attack on a publicly reachable server can be staggering. Responsiveness of the system to legitimate users is also significantly degraded during such an automated attack. Attacks have been observed sending over 10,000 login requests per hour. One site logged 780,000 requests in a 72 hour period of one such recent attack.
ISA Server Reverse Cache Support
The WanderWare isapi authentication filter may be installed as a module on ISA Servers configured as reverse cache site accelerators. When used in this configuration authentication management is performed on the ISA server and not the web servers. The protected servers are fully shielded from malicious requests as such requests are dropped without further processing.
The protected ISA server becomes the authentication gateway protecting access to all web servers that are connected behind it. This extends the application of authentication services to all of the protected web servers without being limited to a specific operating system or server.
The services are also extended without needing to do any configuration or installation of software to the servers comprising the web farm. This allows a site operator to both scale out with additional servers and to service web servers running multiple operating systems and other http daemons.
Cross Site Partitioned Access Option
Master sites offering tiered access to syndicated content through geographically diverse third party owner affiliate feeder sites can implement partitioned control and management of users by using the isapi authentication filter. This applies to entities such as research library networks, online entertainment networks and AVS networks. This capability is available as a hosted custom implementation under vendor supervision.
An additional option for e-publishers is the creation and management of one-time throwaway access tickets used for access to purchased access to downloadable publications.
Proxy Server Detection Support
In the past, defending servers from password attacks originating through or from proxy servers has been problematic.
For proxy servers using single addresses the problem is incorrect identification of that address as uniquely connected with an attack. Such an interpretation leads to incorrectly locking out legitimate users who happen to be attempting to connect through the same proxy server.
The opposite side of this problem are proxy servers that use blocks of addresses. The best known example of this type is AOL. All subscribers to AOL services automatically use these proxy servers as their gateway to the internet. A concerted attack from such a server appears to be many unique connections from individual machines but are actually connection attempts from a single source. Another major block of users arriving through proxy servers are subscribers to broadband dsl and cable internet services.
As a response to this problem, the isapi authentication filter reverses previous practice and treats all class c subnets as potential proxy servers. By responding this way all of the internal mechanisms have been unified into a single direction. It is no longer necessary to treat proxy servers as a special case calling for unique handling. The result of this integration is efficient and accurate handling of all requests by the isapi authentication filter without regard to the request source.
HTTP/1.0 and HTTP/1.1 with and without SSL/TLS are supported transparently. Thus, both http and https protocol prefixes can be used successfully throughout a site without limitation.
Browser Cookie Independence
The system does not require or interfere with client browser cookies. Domain limited session cookies are sent by the isapi authentication filter as an additional identification mechanism, however, they are not required. Session cookies expire at the end of a browser session and are not stored on a users hard disk. The domain specific session cookie used by the isapi authentication filter consists of a single 128 bit cryptographic MD5 hash and a session identifier. The username and password are not stored in the session cookie. As a domain limited session cookie, it is returned by the browser only to the issuing domain.
WanderWare offers client browsers the choice of either Basic Authentication(RFC 2617) or Digest Authentication with MD5 hashes(RFC 2617) as a login mechanism. Digest authentication is recommended as being more secure than Basic authentication.
Basic Authentication passes the user name and password encoded in a BASE64(RFC 2045) encoded string. Since the encoding scheme is well known and involves no secrets it is considered trivial to decode.
Digest Authentication passes the result of a 128 bit MD5 cryptographic hash on a computed secret result as the authentication information. Reversing the MD5 hash to obtain the secret is considered to be infeasible. Under this method, confirmation of the information is done by computing the hash at the server and comparing it with the result from the browser. At no time is the password transmitted over the network.
Secure Password Storage
Passwords are never stored in their original clear text form, nor are they stored in a final usable form at any time.
Instead, the 128 bit cryptographic MD5 hash of term A1 described in the RFC is calculated and stored in the database when the user is first added to the database. This MD5 hash is later used as a seed for further calculations of the final user authentication credentials during subsequent authentication confirmation processes.
Passwords cannot be recovered because of the impossibility of reversing the stored cryptographic MD5 hash.
If a user forgets his password, he will have to be assigned a random password which he can then change to one of his own choosing. During this generation process, the secure 128 bit cryptographic MD5 hash of term A1 is again calculated and stored as the basis for future authentication requests.
Account and Password Lockout
Account lockout policy is modeled on policies with a history of great success on internal corporate server systems. If a user enters 5 consecutive incorrect passwords in a row the account will be disabled for a period of time.
Further the lockout period is calculated as 5/t * 3 hours, where t is the time in minutes between the first error and the fifth error. Thus, if the account is under automated attack the lockout duration is increased proportionately to the speed of attack.
The minimum lockout is 3 hours. As compared to account deletion, this approach minimises system admin intervention because the account will come alive again without further action through the passage of time.
This is an effective defense against automated password crackers or password hurlers because each username can only have 5 tries before locking out. Subsequent requests are refused without further analysis or acknowledgement.
A password cracker or password hurler can actually try the correct password on the sixth try but gets no positive feedback. The correct password is then assumed to be incorrect and is dropped from the list. Additionally, the attacker will suffer significant delays while waiting for acknowledgments which never arrive.
The isapi authentication filter implements several mechanisms to ensure the proper use of passwords. Both the speed and network source of password attempts is monitored. High speed multiple attempts are interpreted as being sourced from automated password cracking and password hurler programs. Multiple attempts from multiple network sources are interpreted as sourced by password cracking, password hurling or password sharing. Correct attempts by multiple network sources are interpreted as being sourced by password sharing by multiple unauthorised users.
In each of these cases, the isapi authentication filter takes defensive measures and alerts the system administrator. These defensive measures include disabling accounts and locking out specific network sources. Persistent abusers are blacklisted.
All files in a protected area are defined as protected. The file type does not matter. This means that both pages and images are protected from abuse. For each request to a file or page the user must be in an authenticated session and satisfy the http-referer check.
A virtual gateway page is implemented as a means of preventing automated abuse of the system through hot-linking, robots, spiders and other means. All sessions must be initiated at the gateway page. If a file is requested by an unauthenticated user who has not been granted a secure session by authenticating through the gateway page, the user is redirected to the home page. It is also the only page that is not subject to http-referer checks and restrictions.
As the security features of the isapi authentication filter are separated into an installed component, web developers are able to develop sites using the same techniques and procedures for both public and private areas of the site.
Authentication processes are compartmentalised at the protocol and component levels. This ensures that security considerations are transparent to web developers.
This transparency translates into faster project completion times accompanied by lowered skills requirements.
Session Bandwidth, Connection and Time Limits
Bandwidth and time limits are enforced for every session. When these limits are reached, further requests are refused.
Connections are monitored for frequency and network address origin. If a suspicious pattern is detected then the account is disabled for a set period of 30 minutes.
Tarpits as a Defense
Tarpitting describes a defensive technique used to defend servers under attack.
WanderWare implements a form of tarpitting to conserve resources if it recognises a series of connections as being incorrect. In these circumstances, suspect connections are simply dropped without reply. This serves to dramatically reduce the speed and effectiveness of the attack because the attacker(s) must wait for network replies which will never arrive. This serves to conserve both bandwidth and system resources for legitimate connections. It is especially suited to defending the server from denial of service attacks.
Having such a defense at the ready could make the difference between keeping a www service available and apologising for service outages. Additionally, expensive bandwidth spikes that could cripple the financial stability of a service are prevented from occurring.
Self Tuning Memory Management
The WanderWare system incorporates self tuning memory management. These memory management mechanisms ensure that the memory usage of the system does not negatively impact the performance of other critical server processes. This feature is especially important during high stress situations likely to be encountered during automated attacks.
A system lacking in such automated memory management is subject to denial of service attacks based upon causing memory consumption. Attacker(s) simply send enough requests to cause the system to consume huge amounts of memory.
At some point, the server's physical memory will be exhausted and it will be forced to start paging memory to disk. When a system is paging rapidly, it is known as disk thrashing. This causes system response times to degrade by several orders of magnitude.
Finally, when all physical memory and virtual memory limits are reached, the system will likely crash.
By monitoring and tuning it's memory usage dynamically, WanderWare is immune to attacks based on memory exhaustion. As with the tarpit defense, this advanced feature can be the difference between surviving and succumbing to an attack.
Administrative alerts are sent via email to the defined system administrator on detection of suspicious events. The email address can be that of a pager service, or the email account can be one that forwards an additional notification to a pager service email account.
Standard SQL Storage
The authentication system employs industry standard SQL databases for data persistence of user information used in authentication and authorization. Sites may elect to use Microsoft SQL Server, IBM DB2, or Oracle without affecting the functionality of the system.
Developers integrate the sites membership management using tools, mechanisms and interfaces they are already familiar with. The authentication system interfaces with the resulting information using stored procedures with a specification that is common to all vendor implementations.
Integrated SQL-MMDB Caching
An enhanced MMDB(main memory database) is integrated into the authentication control engine of the product which interfaces with the isapi authentication filter and the SQL storage server selected by the site. The MMDB is based upon extensions to current published research papers relating to future lookup techniques for high speed internet backbone routers.
The MMDB reduces the workload of the SQL server while greatly accelerating the speed of authentication processes. A typical benchmark result for internal timing with large populations on modest hardware is:
The scaling characteristics are essentially linear for increases in cpu speed.
This level of performance exceeds by several orders of magnitude the capabilities of both conventional SQL servers and any available web server. It ensures that the authentication processes will never be a performance bottleneck even in server farm load balanced configurations.
Browser Update Isolation
Sites are insulated from the effects of browser upgrades and patches because the authentication and authorization are standards compliant and the results are not dependent on browser interaction. Unlike custom scripted methods, the server processes are not sensitive to changes in browser settings and defaults introduced by changes in the browser. This is of special importance to public sites which cannot control the deployment of a specific browser.
During login the sequence is:
a - browser requests virtual gateway page with the final destination specified as a query string, for example:
b - server replies with authentication request
c - user is prompted for user name and password by a browser dialogue
d - browser resubmits request with user name and password
e - server authenticates user credentials and initiates session state
f - server redirects browser to real target page http://www.example.com/welcome.asp
g - subsequent requests by the same browser for other files during the same session will be permitted as long as the proper authentication credentials are presented
Custom Login Forms
You can use a login form by embedding the user name and password into the submitted link. This can be done using the onsubmit action of the submit button to modify the link when the user clicks on it. The disadvantage is that the once the page is returned the username and password will appear in the user's typein location bar. This means it can be bookmarked. The workaround is to use an intermediate page meta-refresh with a delay of zero to the actual user viewable page. This will move the page fast enough that the user will not book mark it. A side effect of this technique is that the back button will not work because the user will be going back one page which then goes forward again. An additional consideration is that the user visible page cannot be in a protected area because the browser does not send referrer information on the meta-refresh request. A request to a protected area will fail on such a request because of the referrer check mechanism.
An example of the required final link when using a form is:
Please note that user names and passwords containing the '@' or ':' characters will have to be escaped if a custom login form is to be used. This is necessary because some browsers interpret the first '@' symbol found in a link as the transition to the host part of the url and the first ':' symbol as the separator between the username and password . We actually do encourage the use of email addresses as user names because real email addresses are guaranteed to be unique by definition. They are also easy to remember. Of course, using symbols in passwords has always been a key recommendation for secure passwords.
The substitutions are:
'@' = chr(254) ':' = chr(255)
Thus the username/password combination:
'firstname.lastname@example.org:pass:word' is changed to: 'someone.important^example.com:pass|word'
'^' = chr(254) '|' = chr(255)
These are believed to be safe because they are not normally available directly from a keyboard and thus are not likely to be used by anyone for a user name or password. These transformations are handled properly in the example login page code that is provided to you.
*Example reference link goes here.
Many browsers do not send referring page data on a meta-refresh. They treat the refresh as a typed in url. Because of this, the request will fail on the http-referer test. You can successfully meta-refresh into a non-protected area as long as none of the files making up the page is in a protected area.
Site Naming Conventions
It is important to be careful of site naming conventions within protected areas to make the user experience as smooth as possible. In particular, even if you have set both www.example.com and example.com to refer to the same server, it important that links within protected areas be consistently named with one server name, or identified without the server name by path only. This arises because of the way browsers interpret the application of cached credentials as they encounter requests. www.example.com and example.com will not be considered to be the same server by the browser, and it will ask for credentials a second time. This is harmless, however, it is disconcerting to users who know they are already logged in and do not expect further login prompts.
Access to User Names and Session State
The isapi authentication filter includes a feature that greatly simplifies tracking an authenticated user through multiple pages of a web site.
On every request for a file in the protected area a custom header is inserted into the request. The request is accessible from dynamic pages as the cgi variable 'HTTP_USER'. This eliminates the usual need for developers to track users via url variables, hidden forms variables or cookies.
An additional development benefit of having the user name available at all times is the ability to efficiently maintain all session state on the server side using database or object storage.
Some browsers do not send user credentials for a request until challenged. For these browsers, the sequence of events on every request for a protected file is:
send request receive authorization required response resend request with authorization information receive file
This happens for protected every file. Therefore, for best performance, only place files in protected areas that need the protection of an authenticated user session. This way extra trips to the server and authentication processing is minimised.
Browser Support for HTTP/1.1 Digest Authentication
As digest authentication is defined as a feature of the HTTP/1.1 protocol only those browsers will respond with MD5 digest user credentials. HTTP/1.0 browsers will respond with Base64 encoded user credentials.
Additionally, the browser must have HTTP/1.1 enabled in the user settings. Finally, if the user is passing through a proxy that is only capable of HTTP/1.0 then MD5 digest user credentials will not be used.
WanderWare will accept either form of authentication as requested by the client browser.
Browser versions known to support HTTP/1.1 are:
Internet Explorer 5.0+
Note: While there have been mentions of problems in compliance with RFC 2069 in the implementation of digest authentication in Internet Explorer, this has not been our experience. In implementing the server side code for digest authentication in the isapi authentication filter, by referencing RFC 2069, it has been observed in instrumented testing that the authentication responses sent by Internet Explorer have been exactly those that would be expected from a compliant browser. Furthermore, despite following many leads, and contacting the author of the original article directly, we have not been able to find any published details documenting any failure with respect to compliance with RFC 2069 in Internet Explorer.
Intel x86 hardware platforms
Microsoft Windows NT Server / IIS 4.0
all iis site permissions set to anonymous access only
for enterprise distributed servers a backend intercommunications network private ip address is recommended
References On The Internet:
TABLE OF CONTENTS
all rights reserved
design - eggworx.com