This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Testing for Captcha (OWASP-AT-012)

Revision as of 00:48, 18 November 2013 by Wilder (talk | contribs) (Description of the Issue)

Jump to: navigation, search
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: Back to the OWASP Testing Guide Project:

WARNING: CAPTCHA protection is an ineffective security mechanism and should be perceived as a "rate limiting" protection only!

Most current used CAPTCHA images can be easily cracked in a fully automated way using many commercial or opensource services. Commercial services are usually very cheap and provide a simple API for most programming languages.
It is not recommended to use CAPTCHA protection for security-critical applications, in this case it is more suitable to use SMS text messages or OTP tokens instead.

Example of Google reCAPTCHA cracked in 7 seconds by commercial automated cracking service:
Price: US¢1.390
Uploaded: Sun Nov 17 20:03:13 2013
Solved: Sun Nov 17 20:03:23 2013
Text: 270 35524452

Most CAPTCHA images can be cracked in 1-15 seconds, therefore CAPTCHA should be perceived as a rate limiting protection only which stops the attacker for a limited amount of time.

Brief Summary

CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer.

Description of the Issue

Despite the above-described CAPTCHA weakness, it can be still used against:

  • automated sending of many GET/POST requests in a short time where it is undesirable (e.g., SMS/MMS/email flooding), CAPTCHA provides a rate limiting function
  • enumeration attacks (login, registration or password reset forms are often vulnerable to enumeration attacks - without CAPTCHA the attacker can gain valid usernames, phone numbers or any other sensitive information in a short time)
  • automated creation/using of the account that should be used only by humans (e.g., creating webmail accounts, stop spamming)
  • automated posting to blogs, forums and wikis, whether as a result of commercial promotion, or harassment and vandalism
  • any automated attacks that massively gain or misuse sensitive information from the application
  • simple enumeration attacks, simple spambots/adbots and less sophisticated attackers

In security critical applications it is more suitable to use alternative verification channels (SMS text messaging, OTP etc).

Black Box testing and example

Testing for Topic X vulnerabilities:
Result Expected: