Advanced Password Services (APS) Guide › Administration and Operations › Special Case: Three Strikes, You're Out

Special Case: Three Strikes, You're Out

SiteMinder, with APS installed, supports two different "Three Strikes, You're Out" options. These options are basically unrelated and can be used together, if care is taken with the configuration. It is fairly typical for a site to confuse users (or themselves) by improperly configuring the two options.

APS keeps a failure count on a per user basis. This failure count is kept in memory and written to disk (for LDAP users). The information is kept both on disk and in memory for LDAP users, so that the feature will still work even if the Primary LDAP server is unavailable. APS will use the setting in memory or the setting on disk, whichever has a later date/time. Each failure count is maintained with a timer (controlled by the Failure Count Timeout setting). If no attempts are made for this amount of time, the failure count is discarded. The count includes all attempts, regardless of which browser supplied the authentication credentials, but only those that apply to the specific user.

Most implementations of HTML form-based login keep a retry count. In the form login mechanisms supplied with SiteMinder, this count is kept in a transient cookie called RETRYNO, SMRETRYNO, TRYNO or SMTRYNO. This count is kept for the duration of the browser session. It includes all failures, regardless of the user id entered. Usually, when this value hits a threshold, further attempts are prevented and an error message (or page) is displayed.

Please note that Basic Authentication (where the browser presents a dialog box for authentication) works the same way, but the count is not configurable; it is always three. In this case, it is consecutive retries, but, like above, it is independent of the user id entered.

The counters kept at the browser level should only be considered "speed bumps". A savvy user knows that he need only stop, and then restart the browser and further attempts can be made.

The APS tracking will, eventually, lock down (disable) the user. Regardless of what the user does, the account is no longer available.

Some sites will use one capability or the other. For the most security, with the minimum user distress, both should be used with care, as described below:

The "speed bump" (browser-side) options should be set to a value of three (note that Basic Authentication is not configurable). The APS Max Failures setting should be set to 5.

At the end of three attempts, send the user to an error page that reads something like "You've apparently forgotten your user id or password. Please call our Help Desk for assistance." or refer the user to your Forgotten Password Support page.

A normal user will typically do exactly what is asked; they will call the help desk for assistance. The account is not disabled, since the APS count will only be 3.

If, however, the user is intent on breaking into the site, they will stop the browser, then restart it and continue to attempt a break-in. After two more attempts, APS will intercede and the account will be disabled. Further attempts will be denied. This will only happen in two cases:

• The user shut down the browser and explicitly continued to make attempts.
• The user is accessing through multiple browsers.

In either case, it is a real attempt at intrusion, not just a mistaken user.

APS should not be configured to redirect the user in this case (nor in the disabled case). Instead, an email should be sent to an internal security administrator, possibly through a pager gateway, telling the administrator that an intrusion attempt is in progress. If possible, email should be sent to the owner of the user id as well, describing that the account is disabled and why.

The "speed bump" will continue to operate, so the hacker will never know that the account has been disabled.