AuthFilter and DDoS Attacks

A distributed denial-of-service (DDoS) attack is an attempt to disrupt access to a server. There is a known vulnerability with AuthFilter, which could cause a registered user to be forced to re-authenticate on each Web page. This is caused by a malicious user repeatedly logging on to your site with a known valid user ID and incorrect password.

When a user logs on to the site, the password, entered by the user into the login page, is placed into the AuthFilter password cache. By default, AuthFilter associates the password, in the AuthFilter password cache, with the user ID of the user that supplied the login credentials.

However, AuthFilter does not associate each password, in the AuthFilter password cache, with one, and only one, client session. When a user logs on with a valid user ID, the password cache is updated with the submitted password, even if the password is invalid. This DDoS technique disrupts service, because the authenticated user must re-authenticate when redirected to a new Web page.

The malicious user does not gain entry to the site, but forces a registered user who is using an active session, to log in again. This is because the password in the AuthFilter password cache is no longer valid for the registered user.

To avoid the attack, you can store a custom property in the AuthFilter password cache, in addition to the user ID and password. This custom property is generally a globally unique identifier (GUID) and is used to distinguish between different client sessions using the same user ID and possibly different passwords.

Filled Password Cache

In situations in which where the AuthFilter password cache is filled with the passwords of legitimate user IDs, any new incoming authentication will be redirected to the login page.

If the password cache reaches its maximum size, a message is written to the Event Log that you must increase the size of the cache.

If you do not increase the size of the cache immediately, users will not be able to login.

Note

• For information about implementing a GUID in your Login.asp page, see Configuring Login.asp to use a GUID.

To view a sample Login.asp page, that has been updated to avoid this (DDoS) attack scenario, see Login.asp Code for the Supplier Solution Site.

See Also

Login.asp Code for the Supplier Solution Site

BDSecurity Object

AuthManager Object

Code to Set a Custom Property on a Ticket

Using Proxy Accounts in a Web Farm

Adding a New Property to a Profile Definition

Copyright © 2005 Microsoft Corporation.
All rights reserved.