BotDetect CAPTCHA Classic ASP FAQ (BotDetect ASP v4.x; discontinued)

Yes, you need full admin rights on the server to install and use the BotDetect Classic ASP Captcha component, since the base Captcha functionality is implemented in a COM component which needs to be registered on the server. You will have to ask your web presence provider to install BotDetect on the server for you. Please also note that .NET 2.0 is required for the registration to succeed.

Running the BotDetect setup package on the server is the simplest way to deploy it, but you can also deploy it manually if you want.

Either the Captcha COM component is not registered on your server, or you're missing .NET framework version 2.0. .NET 2.0, 3.0 or 3.5 (any version based on the 2.0 core framework) is required for BotDetect 4 since most of its functionality is implemented in a .NET 2.0 based assembly exposing a COM interface.

When using load-balanced servers, you will have to enable sticky connections in your load-balancer settings. This will ensure that clients return to the server containing their existing ASP Session state data on all Http requests after the first one.

This step is necessary since the ASP Session state is always kept in IIS worker process memory. Since the state information only exists on the server where each individual IIS instance is running, ASP Sessions can't be shared between multiple servers.

Keeping the BotDetect Captcha library files in the same folder as your .asp forms is the simplest solution. It is possible to keep a single copy of the BotDetect Captcha library files and use them on multiple ASP forms, as long as those forms are all within the same ASP application.

Every IIS virtual folder that is configured as an ASP application has its own Global.asa file and its own separate Application and Session state. Problems with Captcha validation and sounds occur because they rely on Captcha codes stored in Session state, which they can't access from a global include location.

Please check is IIS scripting enabled on the machine where you ran the setup package. You can do this in Control Panel, looking at the Programs and Features → Turn Windows features on or off → Internet Information Services → Web Management Tools → IIS Management Scripts and Tools option. It must be enabled before the BotDetect installation can deploy packaged examples to local IIS.

The BotDetect Classic ASP Captcha library uses the built-in ASP Session state for simplicity, but you can persist the Captcha data in any server-side container that suits your needs (e.g. database persistence shared between multiple load-balanced servers).

You need to wrap the persistence functionality in a dictionary-like object (like Session state does), and use the BotDetect.Persistence setting in the CaptchaConfig.asp file to configure BotDetect to use it.

That's exactly how BotDetect v1.0 used to work, and we abandoned that approach because it was a major security flaw.

Captchas with any kind of client-side persistence can be bypassed easily. For example, if a hashed token of the Captcha code is kept on the client, a simple replay attack can reuse a single correct Captcha code thousands of times. Implementation details vary, but all forms of client-side persistence can be tampered with and attacked by malicious clients.

BotDetect must use server side persistence by design - and we chose that approach because we believe it to be the right way to implement a secure Captcha.

Considering the nature of Captcha data that is persisted, the storage medium should be: per-visitor, server-side, automatically cleared - and Session state is the simplest option that fits those requirements.

You can use BotDetect protection on a plain Html / FrontPage form as long as you use ASP to process form submissions. Simple FrontPage forms that use FrontPage Server Extensions are NOT supported.

To get the Html markup required to add BotDetect Captcha protection to the form, you should first consider the same factors as when adding it to an ASP form: what will be the Captcha identifier, and which Captcha settings will you use.

The simplest way to proceed is then to add the Captcha object instance to a temporary .asp form, and then use View Source in a browser to find the generated Html markup and paste it to your form.

You have most likely forgotten to include Captcha validation code in the ASP script that processes your form's submitted data. You can see an example code snippet for Captcha validation in the How To add BotDetect Captcha protection to Classic ASP forms guide.

Also, you might want to take a look at the BotDetect Classic ASP integration samples that come with BotDetect installations, starting with the BotDetect basic ASP integration code example.

You are right, and this behavior of the Captcha component is by design. Only one validation attempt is allowed per Captcha code for security purposes.

If we allowed multiple retries on solving the same Captcha, it would significantly lower the Captcha security, since bots could just brute-force different code values until they eventually got it right. Also, it would be much easier to write a bot which used OCR techniques to bypass the Captcha: if, for example, it could recognize two out of the five digits in the image, it would just have to brute-force the remaining three.

So a failed validation attempt (whether on the client- or server-side) always invalidates the current Captcha code. Successful server-side validations also remove the code (so we prevent cases where somebody solves just one Captcha and then keeps reusing it for multiple submissions).

Successful client-side validations are the only ones that don't invalidate the current code, so you can also validate the same submitted values on the server-side once all form fields have been filled-out.

So basically, if the Captcha validation attempt wasn't successful, the Captcha image also needs to be reloaded and the previous user input cleared, since the old Captcha code has been invalidated.

If you want to avoid full page submissions, you could take a look at the Asp jQuery Validation Captcha integration and BotDetect Asp Built-In Ajax Captcha validation samples coming with the BotDetect installation, which use Ajax requests to only submit Captcha validation data to the server and update the client display based on the Captcha validation result.

Pure client-side CAPTCHA validation drawbacks

Pure client-side Captcha validation (without any communication with the server) is not supported by BotDetect, since such a Captcha is trivial to bypass, and doesn't provide any serious protection from bots. For example:

• You want users to post comments only if they have successfully solved the Captcha.
• If the Captcha validation is purely client-side, this means JavaScript code must send the user's comment to the server when the Captcha code is entered correctly.
• So the spammer only needs to solve the Captcha once, and note how you handle the result: e.g. sending a specific POST parameter, or redirecting to a specific page.
• After that, they can simulate the same behavior in their bot and bypass the Captcha completely – by simply faking the POST parameter, or accessing the redirection landing page directly.
• You can back the client-side Captcha validation by also validating the same user input on the server once the page is posted and before recording the user comment.
• But since you are keeping the correct Captcha solution on the client for validation, bots can have easy access to that code and then always solve the Captcha correctly.

The exact details would of course depend on your specific use-case and Captcha integration scenario. But essentially, all client-side code is insecure and can be faked or modified by malicious parties. As a consequence, Captcha codes must only be kept on the server, and all Captcha validation must be performed on the server as well.

Client-side Captcha validation - the solution

You can avoid full page submissions by using Ajax to make asynchronous Captcha validation requests to the server, and processing the result on the client:

• When the Ajax Captcha validation fails, you can show the user a new Captcha image without affecting the rest of the page, thus improving the user experience and overall usability of the page.
• You should always change the Captcha code in such cases, since allowing multiple attempts at solving the same Captcha makes OCR guessing much easier.
• When the Ajax Captcha validation succeeds, you should then submit the page to the server and validate the user Captcha input again.
• Only after successful server-side Captcha validation should you execute the "protected" operation (e.g. record the user comment) on the server.

Users definitely shouldn't have to solve another Captcha if they enter the correct Captcha code, but (for example) username validation fails. The purpose of Captcha is to ensure the user is human, and once they solve it this purpose is fulfilled.

If you have to return them to the form because another field value needs to be corrected, it's best not to show them the Captcha at all.

BotDetect remembers that the user has passed the Captcha test successfully in the IsSolved instance field, and you can only display and validate the Captcha if it hasn't already been solved. For example:

<% ' Display the Captcha test on the Default.asp page
  Dim FormCaptcha : Set FormCaptcha = (New Captcha)("FormCaptcha")
  FormCaptcha.UserInputID = "CaptchaCode"
  
  If Not FormCaptcha.IsSolved Then %>
    <label for="CaptchaCode">Retype the characters from the 
      picture:</label>
    <%=FormCaptcha.Html %>
    <input type="text" name="CaptchaCode" id="CaptchaCode" /><%
    ' CAPTCHA validation failed, show error message
    If Request("captchaValid") = "False" Then %>
      <span class="incorrect">*</span><%
    End If
  End If

<% ' Captcha validation, in the form processing action
  Dim FormCaptcha : Set FormCaptcha = (New Captcha)("FormCaptcha")
  FormCaptcha.UserInputID = "CaptchaCode"
  
  If Not FormCaptcha.IsSolved Then
    Dim isHuman : isHuman = FormCaptcha.Validate()
    If Not isHuman Then
      Response.Redirect "Default.asp&captchaValid=False"
    End If
  End If

For security reasons, it is not possible to get the same BotDetect Captcha image on two page loads, nor to use the same code for more than one Captcha image.